Re: [TLS] padding bug

[Adam Langley <[e-mail]>]

On Mon, Sep 9, 2013 at 9:31 AM, Ben Laurie <[e-mail]> wrote:
> 1. Nothing in this I-D prevents the adoption of other approaches.
>
> 2. If fixes the problem for all versions of TLS and SSLv3.

The cost of making any change to TLS is mostly equal to any other,
since the bulk of the cost is in deployment. Using an extension to
negotiate encrypt-then-MAC is a simple change, but it still leaves us
with CBC mode. On the other hand, AES-GCM left the station some years
ago and has a clear head start.

AES-GCM does, currently, depend on TLS 1.2, which is proving to be a
pain to deploy on the public Internet as a client, but we'll get there
soon.

I don't believe that this change solves the problem for SSLv3 as SSLv3
doesn't have extensions and so cannot negotiate it. Once AES-GCM is
running I'm hoping to simply define those ciphersuites all the way
down the versions in order to solve version downgrade issues.

Having an alternative to AES-GCM is certainly valuable, but I don't
want it to be AES-CBC. I think the prior discussion around
Salsa20/Chacha20 and a polynomial MAC is the most promising direction
for that.

I've no objection to this ID, but nor am I esp excited by it.


Cheers

AGL