RE: [TLS] Record layer corner cases

Pasi Eronen wrote:
> Bodo Moeller wrote:
> > Now that I come to think of it, if we want to change the words of
> > the specification for TLS 1.2, we might just as well simply take the
> > current description of fragmentation and add "And we mean 
> > it" ... :-)
> > 
> > Seriously, if we rule out some odd cases of fragmentation, I don't
> > think it is unreasonable to require all implementations to 
> > be able to properly process fragmented handshake messages.
> 
> My worry is that just adding "And we mean it" wouldn't change the
> current situation: since receiving-side processing is so poorly
> implemented, the sending side can't really rely on it.

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?

Do you think something like this would be an effective way of 
saying "And we mean it"?

Best regards,
Pasi

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