I like this approach.
On 09/08/2016 06:04 PM, David Benjamin wrote:
Hi folks,
I’d like to revisit the question of version negotiation.
EKR wrote up some text for moving version negotiation to an extension:
https://github.com/tlswg/tls13-spec/pull/632
I would like us to adopt this proposal.
In Berlin, this really got framed as a pragmatic question: the current
version negotiation has a lot of intolerance and so let’s work around
that. So, understandably, this seemed like a “let’s adopt a hack
forever” proposal. I think that framing is wrong. The intolerance
situation is serious, but I think there’s also a strong argument that
the current scheme isn’t very good.
The current scheme is very simple. The client advertises a maximum
version and the server selects based on that. This is the only piece of
TLS negotiation which works this way. Elsewhere (extensions, cipher
suites, signature algorithms), one side offers a list and the other side
picks out of it. I think it’s clear now that strategy is more robust:
every time we’ve bumped version numbers, we’ve had intolerance problems
and this time is no exception (see below). By contrast, we regularly
introduce new cipher suites, extensions, etc., and while we do see the
occasional failure, they are much rarer and typically within the level
of breakage that clients can tolerate and deal with by reaching out to
affected servers. Moreover, lists lend themselves to future-proofing via
draft-davidben-tls-grease-00 in a way the current scheme does not.
An additional benefit is lists make it much easier to roll out
prototype/draft versions. Currently, we are using a hack where the
client offers {3, 4} but also includes a draft version number in an
extension. This does work, but requires servers process that extension
in perpetuity or at least until all draft version clients go away. With
a list, it’s trivial to offer a draft version by just including it. This
is the strategy HTTP/2 used (via ALPN) and it worked well.
Despite all of the above, it probably wouldn’t be worth fixing version
negotiation in 1.3 except for intolerance. Unfortunately, this fourth
time, it’s the same story as before. A probe of Alexa top million sites
with BoringSSL’s TLS 1.3 code (the Go version), shows 1.63% of
TLS-capable hosts reject a TLS 1.3 ClientHello. Note these are top sites
and traffic is top-heavy, so we can expect much higher usage-weighted
numbers. Qualys SSL Pulse reports 3.6%:
https://blog.qualys.com/ssllabs/2016/08/02/tls-version-intolerance-in-ssl-pulse
(Ignore the drop in the graph. We’ve long fixed the ClientHello
record-layer at {3, 1}. TLS 1.3 only codified existing practice here.)
If instead we use a TLS 1.3 ClientHello with version TLS 1.2, the
breakage drops to 0.017%. (Some of this is an NSS signature algorithms
bug, fixed last year, which we hope to clear by deploying RSA-PSS in
browsers early. The rest appears to be noise from transient errors which
crop up in large tests.)
These numbers are *far* too high for clients to accept as damage, which
means that they (at least browsers) will be forced to do fallback. This
represents a security risk (cf. POODLE) as well as hides serious interop
problems. The situation is even worse for non-browser clients, which may
be unable to deploy at all (Ubuntu 12.04, despite shipping an OpenSSL
release with TLS 1.2, had to disable it on the client.
https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1256576/comments/4 )
The major arguments against this change seem to be:
1. It’s inelegant to have two mechanisms.
2. We should fix broken servers
The first is true, but as with other changes, EKR’s PR replaces the 1.2
mechanism with one for 1.3, so we’ll just have one going forward. The
second would be nice, but as a practical matter, I spend a lot of time
trying to get those servers fixed and it doesn’t work very well here.
Better is simply to move to a situation where once those servers upgrade
they will be correctly behaving forever (instead of just handling 1.3
correctly and breaking with 1.4). This change does that.
Thanks,
David
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
