We already have a useless field in the record header; the record_version is
fixed to { 3, 1 }; and this is not a coincidence.
I think it would be better to maintain a 1.2-compatible version negotiation for
backwards compatibility, and have a more robust and expressive version
negotiation option. Now would be the time to do it.
--
-Todd Short
// [email protected]<mailto:[email protected]>
// "One if by land, two if by sea, three if by the Internet."
On Sep 8, 2016, at 12:04 PM, David Benjamin
<[email protected]<mailto:[email protected]>> 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=QBEcQsqoUDdk1Q26CzlzNPPUkKYWIh1LYsiHAwmtRik&m=X-0L9PRkXf7K_CpAiDi6ldM0ih6EM7it43_XJISkgbY&s=fCNNhmCZPHLsW70DqP-eY42xLYXw7VoNlcGFxxclzhU&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=QBEcQsqoUDdk1Q26CzlzNPPUkKYWIh1LYsiHAwmtRik&m=X-0L9PRkXf7K_CpAiDi6ldM0ih6EM7it43_XJISkgbY&s=3BBgAzG_3OoX8D2qjnRLgfpNqVc2-FnuFp2RZc0Vh2M&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=QBEcQsqoUDdk1Q26CzlzNPPUkKYWIh1LYsiHAwmtRik&m=X-0L9PRkXf7K_CpAiDi6ldM0ih6EM7it43_XJISkgbY&s=hvA2qSwecmuUYK2wCsG4PwXECtYXm5aKMN1yDHMIV50&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
[email protected]<mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/tls
_______________________________________________
TLS mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/tls
