Re: [TLS] Version negotiation, take two

[Benjamin Kaduk <[e-mail]>]

This is the best proposal I've seen given the deployment constraints
imposed by reality.  Perhaps it could be tweaked to improve it slightly,
but I support merging this version.

-Ben

On 09/08/2016 11:04 AM, 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
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_tlswg_tls13-2Dspec_pull_632&d=DQMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=sssDLkeEEBWNIXmTsdpw8TZ3tAJx-Job4p1unc7rOhM&m=aarB3I3r_Kn7FPWJq9AJd1ivPK1niUnkupGujPoRKpk&s=1euqoGMgrdBFwR2KiZey_Du1pzwHcBTJJgTNL0Ynvo0&e=>
>
> 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
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__blog.qualys.com_ssllabs_2016_08_02_tls-2Dversion-2Dintolerance-2Din-2Dssl-2Dpulse&d=DQMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=sssDLkeEEBWNIXmTsdpw8TZ3tAJx-Job4p1unc7rOhM&m=aarB3I3r_Kn7FPWJq9AJd1ivPK1niUnkupGujPoRKpk&s=6ziW12EZ1iGkM2bN_6ooRy7CV9SPp0CVFv4hX7bpYSw&e=>
>
> (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
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__bugs.launchpad.net_ubuntu_-2Bsource_openssl_-2Bbug_1256576_comments_4&d=DQMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=sssDLkeEEBWNIXmTsdpw8TZ3tAJx-Job4p1unc7rOhM&m=aarB3I3r_Kn7FPWJq9AJd1ivPK1niUnkupGujPoRKpk&s=tBAuUGE2Q0PBvobD02Z-2PhxBDD1DP7dGKm1M6YxIQM&e=>
> )
>
> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls