Re: [TLS] padding bug

["Brian Smith" <[e-mail]>]

Adam Langley wrote:
> 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.

All of the above matches my position as well. I don't see a lot of long-term
future in CBC-based cipher suites within browsers except as a legacy
mechanism. For example, we (Mozilla) have already decided not to offer any
SHA2- or SHA3- HMAC CBC cipher suites in Firefox, even when we enable TLS
1.2 and even though our TLS implementation already implements SHA256-HMAC
cipher suites. Adam's recent changes to NSS and OpenSSL have demonstrated
how to implement the existing encrypt-then-MAC construction in a way that
addresses the most acute known issues with the current CBC construct in TLS.
AES-GCM and soon new side-channel-free AEAD cipher suites (probably based on
Salsa/ChaCha) provide alternatives for implementations to avoid the CBC
construct altogether.

The downgrade issue only affects incorrect implementations of TLS like ours
(Firefox and other browsers); I think that the implementers of these
problematic products are best off working on a more general solution to the
downgrade issue, instead of encouraging more one-off workarounds for it. We
should focus our effort in this area to standardizing the side-channel-free
AEAD cipher suites and on verifying interoperability of AEAD cipher suites
(AES-GCM and new constant-time ones) even when the protocol version
negotiated on the wire is less than TLS 1.2. If we can't make that work then
we can re-consider our options.

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

Though I don't have any intentions to deploy it in Firefox at the current
time, I also have no objections to this ID, and in particular I encourage
the assignment of an extension ID for it if work is going to continue on it.
More generally, I think we should lower the bar for getting an extension ID
to "somebody has written a document describing what it means that isn't
completely crazy." I am not even sure that the "that isn't completely crazy"
qualifier is necessary. WHATWG asks that people register link relations
(e.g. "foo" in "<a rel=foo>") by simply editing a wiki, and that hasn't
caused any problems in practice.

I know there exist TLS implementations that aren't browsers and I am biased
towards considering browsers' needs over others. But, I think it is worth
considering how likely it is that this will be adopted by browsers when
considering if/how to move forward with it.

Regarding the particulars of the ID:

Section 3.1. (Rehandshake Issues) seems overly complex. I think this
extension should be connection-level, not session-level. Imagine a browser
that contains a preference that controls whether we support the extension.
It would be best if we could create a session with that preference set to
one value and then resume that session with the preference set to the
opposite value. Also, the Chromium team experienced interop issues due to
the negotiated compression algorithm being part of the session state. Based
on that experience, I would expect interop similar issues if this were made
part of the session state.

Section 4 (Security Considerations) would be better if it listed specific
ways that the encrypt-then-MAC construct is currently known to be better
than state-of-the-art (i.e. Adam's constant time) implementations of the
MAC-then-encrypt construct, in the context of TLS's CBC cipher suites. The
draft cites Krawczyk's paper for motivation but Krawczyk's paper says that
there is nothing to worry about as long as the encryption mode is CBC,
right?

Cheers,
Brian
-- 
Mozilla Networking/Crypto/Security (Necko/NSS/PSM)