Subject: Re: [TLS] Comments/Questions on draft-gutmann-tls-encrypt-then-mac-00.txt
From: Adam Langley <[email-masked]>
To: Bodo Moeller <[email-masked]>
Cc: "<[email-masked]>" <[email-masked]>
Date: Wed, 25 Sep 2013 09:11:38 -0400
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>

On Wed, Sep 25, 2013 at 7:03 AM, Bodo Moeller <[email-masked]> wrote:
> So maybe the right fix to this kind of problem is to adapt an idea from
> draft-rescorla-tls-version-cs-00 and create a signalling ciphersuite value
> that would *only* be used in SSL 3.0 connections by clients that have
> downgraded, and tells the server "If you can read this, tear down the
> connection because we shouldn't actually be using SSL 3.0 for this
> connection"?

(I think I would want such an SCSV to indicate TLS 1.2 support rather
than TLS 1.0 support, but that's just a detail.)

A possible problem with this approach is that there are both broken
servers and broken networks and I don't have good information about
the latter. (It's obviously much more difficult to detect.)

Broken networks can stop the transit of TLS based on version and that
has been observed, very rarely, in the wild. However, just because we
haven't observed it much doesn't mean that it's not happening, it just
means that we rarely get to observe it.

If it turns out that broken networks are insignificant then we can use
an SCSV to prevent version downgrade. (Using the renegotiation
extension for this would have been nice, but I think we've already
lost that battle.)

However, if they are not then we may need to run modern ciphersuites
in older versions.

The first step to figuring this out is that Chrome will stop
downgrading to SSLv3 when talking to Google servers soon. If that
works, and we're able to get to the point where we can remove fallback
completely without breaking networks, then that will answer the
question.

Cheers

AGL

-- 
Adam Langley [email-masked] http://www.imperialviolet.org