Subject: RE: [TLS] Record layer corner cases

From: <[email-masked]>
Date: Wed, 13 Dec 2006 16:52:46 +0200

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
[email-masked]
https://www1.ietf.org/mailman/listinfo/tls

---

From: Bodo Moeller <[email-masked]>
Date: Wed, 13 Dec 2006 16:00:22 +0100

>    records before ServerHello (see Section X.Y.Z)?
[...]

> Do you think something like this would be an effective way of 

Yes, this looks very good!

Bodo

---

From: Mike <[email-masked]>
Date: Wed, 13 Dec 2006 20:23:36 -0800

>    If you don't, roughly once out of 256 connection attempts will fail.

On a related note, my large integer code prepends a leading zero byte
if the most significant bit is a one to prevent it from appearing to
be negative.  So when transferring the Diffie-Hellman p, g, Ys, and
Yc, they might have a leading zero byte.  I haven't noticed any
problems with this, but wondered if this should be clarified to
either always do it, never do it, or leave it up to the implementer.

Mike

---

From: Bodo Moeller <[email-masked]>
Date: Thu, 14 Dec 2006 09:01:18 +0100

> either always do it, never do it, or leave it up to the implementer.

You probably won't encounter problems when including leading zero
bytes in encodings of integer values "on the wire", although there
isn't really a point in doing so since implementations also have to be
able to handle values with the most significant bit set, which are not
meant to denote negative values.  So the specification shouldn't
recommend including leading zero bytes.  Some implementations might
always be using a 1024-bit integer for dh_Ys when Diffie-Hellman is
used with a 1024-bit modulus, say, so there's no reason for the
<<pecification to strictly forbid leading zeros.

For the Diffie-Hellman result, of course, stripping all leading
00-valued bytes is mandatory so that both parties are guaranteed to
obtain an identical Premaster Secret provided that they have computed
the same numerical Diffie-Hellman result.

Bodo

---

From: <[email-masked]>
Date: Thu, 14 Dec 2006 12:51:37 +0200

> either always do it, never do it, or leave it up to the implementer.

Good catch! Perhaps we should add something like this to Section 7.4.3?

   "The modulus (and other Diffie-Hellman parameters) are
   sent as unsigned integers (i.e., leading zero octets are
   not required even if the most significant bit is set)."

Best regards,
Pasi