Re: [TLS] padding bug

[Dr Stephen Henson <[e-mail]>]

On 09/09/2013 14:31, Ben Laurie wrote:
> 
> 2. If fixes the problem for all versions of TLS and SSLv3.
> 

That to me is a very strong point in its favour. There have been weaknesses
affecting just about every ciphersuite with the exception of GCM mode, which
needs TLS 1.2. I'd love it if everyone moved to TLS 1.2 in the near future but
realistically that isn't going to happen. All manner of interop headaches
arrived with broken implementations when TLS 1.2 support was added to OpenSSL
and we still get frequent reports. Even with TLS 1.2 I'm uneasy about there
being only one symmetric cipher mode left.

I can add a few additional points in favour of this draft.

The signalling approach taken is similar to the one adopted with the secure
renegotiation (RFC5746), with the exception that extension intolerant servers
will choke. If we really care about those another signalling ciphersuite could
always be added.

I particularly liked the ease with which this could be implemented in OpenSSL
(Peter had similar experiences with Cryptlib). It took me just a few hours and
would've been less if some unfamiliar code hadn't been added recently:
ironically to address the "Lucky 13" attack.

It required no new APIs and it should work seamlessly with existing
applications. That's very important for a library if you have a large existing
code base.

One negative point relates to cryptographic hardware or software optimisations
(where you have an efficient or atomic way to handle record decryption) but I
think this will apply to other solutions too. Anything that needs to address
"Lucky 13" may have already hit this anyway.

On the particular point of addressing "Lucky 13" that attack was a real headache
for FIPS 140 compliance. Reimplementing algorithms at a low level to be constant
time will typically require revalidation with considerable expense and delays. A
partial (but far from perfect) mitigation was chosen as a compromise. If this
draft was adopted that would not be a problem any more as the existing validated
algorithm implementations could be used.

Steve.
-- 
Dr Stephen N. Henson.
Core developer of the   OpenSSL project: http://www.openssl.org/
Freelance consultant see: http://www.drh-consultancy.co.uk/
Email: [e-mail], PGP key: via homepage.