Opened 15 years ago

Closed 14 years ago

#26 closed clarification (fixed)

Add Implementation pitfalls appendix

Reported by: pasi.eronen@… Owned by:
Priority: minor Milestone: DISCUSS
Component: draft-ietf-tls-rfc4346-bis Version: 02
Severity: Keywords:
Cc:

Description (last modified by pasi.eronen@…)

http://www1.ietf.org/mail-archive/web/tls/current/msg01098.html

I did some more thinking about how we could handle
this... .One idea I came up with would be to add a "Top
Implementation Pitfalls" section (probably as non-normative
appendix) that would draw special attention to the most
important things that have caused problems for implementers
in the past and/or are expected to cause confusion
(e.g. because something was changed in TLS 1.2).

E.g. something along these lines:

o  Do you correctly handle handshake messages that are fragmented
   to multiple TLS records? Also 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 Section X.Y.Z)?

o  When using Diffie-Hellman key exchange, do you correctly strip
   leading zero bytes from the negotiated key (see Section 
   8.1.2)? If you don't, roughly once out of 256 connection 
   attempts will fail.

o  When encountering an error in RSA-encrypted Premaster Secret,  
   do you continue the handshake to avoid the Bleichenbacher 
   attack (see Section 7.4.7.1)?

o  What countermeasures do you use against timing attacks against
   RSA private key operations (decryption and signing)?

o  When verifying RSA signatures, do you accept both NULL and 
   missing parameters (see Section X.Y.Z)? Do you verify that 
   there is no additional data after the hash value?

o  Do you use a strong and, most importantly, properly seeded 
   random number generator for generating the premaster secret, 
   Diffie-Hellman private values, the DSA "k" parameter, and 
   other security-critical  values?

http://www1.ietf.org/mail-archive/web/tls/current/msg01957.html

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.

One more (between first and second bullet):

- Do you correctly implement TLS version negotiation, 
  including the case where the client proposes a newer version 
  than the server supports?

And maybe rephase the "when verifying RSA as:

- When verifying RSA signatures, do you accept both NULL and
  missing parameters (see Section 4.7)? Do you verify that the
  RSA padding is correct; e.g., does not have additional data after
  the hash value or in the parameters field? [FI06]

Change History (4)

comment:1 Changed 15 years ago by ekr@…

  • Milestone set to Maybe never

I think this would be best as a separate draft.... TLS has gotten pretty long already.

comment:2 Changed 15 years ago by pasi.eronen@…

I was thinking ~1 page in length

comment:3 Changed 14 years ago by pasi.eronen@…

  • Description modified (diff)

comment:4 Changed 14 years ago by ekr@…

  • Resolution set to fixed
  • Status changed from new to closed
Note: See TracTickets for help on using tickets.