[TLS] Issue 26: implementation pitfalls

<Pasi.Eronen@nokia.com> Wed, 25 July 2007 17:50 UTC

Return-path: <tls-bounces@lists.ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDl0E-00031X-RQ; Wed, 25 Jul 2007 13:50:26 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDl0D-00031S-Uq for tls@ietf.org; Wed, 25 Jul 2007 13:50:25 -0400
Received: from smtp.nokia.com ([131.228.20.170] helo=mgw-ext11.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IDl0C-0007qW-4N for tls@ietf.org; Wed, 25 Jul 2007 13:50:25 -0400
Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext11.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l6PHoHVi011056 for <tls@ietf.org>; Wed, 25 Jul 2007 20:50:22 +0300
Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 25 Jul 2007 20:50:21 +0300
Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 25 Jul 2007 20:50:20 +0300
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Wed, 25 Jul 2007 20:50:17 +0300
Message-ID: <B356D8F434D20B40A8CEDAEC305A1F2404600CF4@esebe105.NOE.Nokia.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: Issue 26: implementation pitfalls
Thread-Index: AcfO5EK6dzw7KcZ0TXSwPp72IrYQVg==
From: Pasi.Eronen@nokia.com
To: tls@ietf.org
X-OriginalArrivalTime: 25 Jul 2007 17:50:20.0911 (UTC) FILETIME=[450417F0:01C7CEE4]
X-Nokia-AV: Clean
X-Spam-Score: 0.0 (/)
X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88
Cc:
Subject: [TLS] Issue 26: implementation pitfalls
X-BeenThere: tls@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/tls>
List-Post: <mailto:tls@lists.ietf.org>
List-Help: <mailto:tls-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@lists.ietf.org?subject=subscribe>
Errors-To: tls-bounces@lists.ietf.org

I promised to write a first draft for a "implementation pitfalls"
appendix; comments are welcome.

Best regards,
Pasi

D.4 Implementation Pitfalls

Implementation experience has shown that certain parts of earlier
TLS specifications are not easy to understand, and have been a
source of interoperability and security problems. Many of these
areas have been clarified in this document, but this appendix
contains a short list of the most important things that require
special attention from implementors.

TLS protocol issues:

o  Do you correctly handle handshake messages that are fragmented
   to multiple TLS records (see Section 6.2.1)? Including corner
   cases like a ClientHello that is split to several small
   fragments?

o  Do you ignore the TLS record layer version number in all TLS
   records before ServerHello (see Appendix E.1)?

o  Do you handle TLS extensions in ClientHello correctly,
   including omitting the extensions field completely?

o  Do you support renegotiation, both client and server initiated?
   While While renegotiation this is an optional feature,
   supporting renegotit is highly recommended.

Cryptographic details:

o  In RSA-encrypted Premaster Secret,  do you correctly send and 
   verify the version number? When an error is encountered, do 
   you continue the handshake to avoid the Bleichenbacher 
   attack (see Section 7.4.7.1)?

o  What countermeasures do you use to prevent timing attacks against
   RSA decryption and signing operations (see Section 7.4.7.1)?

o  When verifying RSA signatures, do you accept both NULL and
   missing parameters (see Section 4.7)? Do you verify that the
   RSA padding doesn't have additional data after the hash value?
   [FI06]

o  When using Diffie-Hellman key exchange, do you correctly strip
   leading zero bytes from the negotiated key (see Section 8.1.2)? 

o  Does your TLS client check that the Diffie-Hellman parameters 
   sent by the server are acceptable (see Section F.1.1.3)?

o  How do you generate unpredictable IVs for CBC mode ciphers
   (see Section 6.2.3.2)? 

o  How do you address CBC mode timing attacks (Section 6.2.3.2)?

o  Do you use a strong and, most importantly, properly seeded
   random number generator (see Appendix D.1) for generating the
   premaster secret (for RSA key exchange), Diffie-Hellman private
   values, the DSA "k" parameter, and other security-critical
   values?

(and add to references)

[FI06] Hal Finney, "Bleichenbacher's RSA signature forgery based
on implementation error", ietf-openpgp@imc.org mailing list, 27
August 2006,
http://www.imc.org/ietf-openpgp/mail-archive/msg14307.html.

(end)

_______________________________________________
TLS mailing list
TLS@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/tls