[TLS] Issue 26: implementation pitfalls
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[TLS] Issue 26: implementation pitfalls



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 at imc.org mailing list, 27
August 2006,
http://www.imc.org/ietf-openpgp/mail-archive/msg14307.html.

(end)

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




Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.