Subject: [TLS] Interoperability failure caused by CBC block cipher padding

From: Simon Josefsson <[email-masked]>
Date: Fri, 16 Nov 2007 17:09:42 +0100

Section 6.2.3.2 of RFC 4364 says:

       block-ciphered struct {
           opaque IV[CipherSpec.block_length];
           opaque content[TLSCompressed.length];
           opaque MAC[CipherSpec.hash_size];
           uint8 padding[GenericBlockCipher.padding_length];
           uint8 padding_length;
       } GenericBlockCipher;
...
   padding
      Padding that is added to force the length of the plaintext to be
      an integral multiple of the block cipher's block length.  The
      padding MAY be any length up to 255 bytes, as long as it results
      in the TLSCiphertext.length being an integral multiple of the
      block length.  Lengths longer than necessary might be desirable to
      frustrate attacks on a protocol that are based on analysis of the
      lengths of exchanged messages.

GnuTLS takes advantage of the wording, and uses longer padding than
necessary.  The pad length is determined randomly.  The reason is to
avoid statistical length-based analysis of short packets.  Other common
implementations (including OpenSSL) doesn't seem to implement similar
precautions.

GnuTLS' behavior appear to generate interop failures with some TLS
client libraries, notably those in Nokia/Ericsson phones.  For
reference, see bug reports:

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=390712
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=402861
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=438137

I believe this part of the specification has changed since the SSL days,
which did not permit unnecessarily long pads.  Still, it seems clear
that this is a problem in those TLS libraries rather than in GnuTLS.  I
also believe the feature is important.

Have others run into this problem?

Is there anything the specification can say to make implementers more
aware of this problem?

Would this be relevant for draft-ietf-tls-interoperability?
(Btw, what's up with that document?  It has expired.)

If someone responsible for these implementation happens to read this,
also consider fixing the bug. ;)

/Simon

_______________________________________________
TLS mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tls

---

From: [email-masked]
Date: Fri, 16 Nov 2007 17:32:39 +0100

Simon,
> Have others run into this problem?

I had similar toughts about this issue. My conclusion 
was that its best to accept any valid padding but never
use to for sending data - except if the peer uses it 
first, becaue then we can assume peer supports this. 

Maybe adding a phrase like "implementations MUST support
this" will calify one for all, that this is really 
mandatory for implementations when reading data.

Axel

---

From: Simon Josefsson <[email-masked]>
Date: Sat, 17 Nov 2007 10:23:34 +0100

> first, becaue then we can assume peer supports this. 

If all implementations make that decision, the feature would never be
used in practice.  That leads to a normally unused code-path, which is
often a poor idea security-wise.  I do sympathize with your desire to
maximize interoperability though.

> mandatory for implementations when reading data.

I would support that.

/Simon

---

From: <[email-masked]>
Date: Mon, 19 Nov 2007 10:33:56 +0200

A while ago, I did some testing on how implementations
handled this, and presented the results in IETF67. See:

http://www3.ietf.org/proceedings/06nov/slides/tls-3/sld8.htm 
http://www3.ietf.org/proceedings/06nov/slides/tls-3/sld9.htm

Basically, most implementations seemed to handle this OK.
Perhaps we could add this to the "implementation pitfalls"
section, though.

(I will also try to report this bug to the people responsible
for fixing this.)

Best regards,
Pasi

> -----Original Message-----
> From: ext Simon Josefsson [mailto:[email-masked]] 
> Sent: 16 November, 2007 18:10
> To: [email-masked]
> Subject: [TLS] Interoperability failure caused by CBC block 
> cipher padding
>