Re: [TLS] Version negotiation, take two

[Andrei Popov]

Both exist. E.g. China has at least one national TLS version (and cipher 
suites), and Russia has cipher suites.

The line is blurred anyway, because a cipher suite (or extension) can introduce 
new protocol message formats, state machine changes, authentication schemes, ...

-Original Message-
From: Salz, Rich [mailto:rs...@akamai.com] 
Sent: Wednesday, September 14, 2016 12:09 PM
To: Andrei Popov ; Hubert Kario 
Cc: tls@ietf.org
Subject: RE: [TLS] Version negotiation, take two

Are there national TLS standards, or just national crypto-suites?
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Version negotiation, take two

[Salz, Rich]

Are there national TLS standards, or just national crypto-suites?
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Version negotiation, take two

[Andrei Popov]

Basically, I don't feel strongly about the switch to the proposed version 
negotiation mechanism. But if we are going to make this change based on the 
theory of having only one extension point and actively defending it, then we 
should probably follow the theory and send a separate TLS extension per TLS 
version.
 
> I don't think we should depart from the "highest mutually supported version" 
> negotiation algorithm...
Correct, but it's not clear what represents "the highest" protocol version in 
the world where national TLS "standards" exist. Is country X-TLS (e.g. with 
integrated MITM support) a higher version than TLS 1.3? The server will make a 
choice based on the server's preferences. In a way, the proposed version 
negotiation mechanism makes it slightly easier to implement servers that 
support country X-TLS alongside IETF TLS versions.

Cheers,

Andrei

-Original Message-
From: Hubert Kario [mailto:hka...@redhat.com] 
Sent: Wednesday, September 14, 2016 11:03 AM
To: Andrei Popov 
Cc: David Benjamin ; tls@ietf.org
Subject: Re: [TLS] Version negotiation, take two

On Wednesday, 14 September 2016 17:39:59 CEST Andrei Popov wrote:
> Do you mean a TLS extension code point per TLS version?

yes, e.g. if extension 0x00a0 is present assume TLSv1.3 support, 0x0121, 
TLSv1.4; same way EMS and MtE works

> One argument against this was that this makes it difficult to express 
> the client's prioritization of TLS versions, but IMHO arguably the 
> server should not care.

I don't think we should depart from the "highest mutually supported version" 
negotiation algorithm, any kind of preference in the client list is likely to 
cause additional problems - version misnegotiation

if client will want to advertise support for TLSv1.3 and TLSv1.5 but not
TLSv1.4 it will still be able to do that
 
> -Original Message-
> From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of Hubert Kario
> Sent: Wednesday, September 14, 2016 9:40 AM
> To: David Benjamin 
> Cc: tls@ietf.org
> Subject: Re: [TLS] Version negotiation, take two
> 
> On Wednesday, 14 September 2016 16:17:50 CEST David Benjamin wrote:
> 
> > Yes, we find list intolerance too---servers which only look at the 
> > second byte in a cipher suite, servers which forgot a default in 
> > their NamedGroup switch-case, servers which get confused on unknown 
> > HashAlgorithms, servers which require the final extension 
> > non-empty---but this is dramatically less than version intolerance.
> > It's usually within tolerable levels that we needn't resort to fallbacks.
> > 
> > The proposal switches from something which we know does not work to 
> > something new. Perhaps this new one will break too, but it is very 
> > similar to things that have worked before, and I am hopeful that 
> > GREASE will help.
> 
> Was the option to do "one extension point = specific TLS version supported"
> 
> discussed too? What arguments are there against it?
> 
> --
> Regards,
> Hubert Kario
> Senior Quality Engineer, QE BaseOS Security team
> Web: www.cz.redhat.com
> Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic


--
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Version negotiation, take two

[Hubert Kario]

On Wednesday, 14 September 2016 17:39:59 CEST Andrei Popov wrote:
> Do you mean a TLS extension code point per TLS version?

yes, e.g. if extension 0x00a0 is present assume TLSv1.3 support, 0x0121, 
TLSv1.4; same way EMS and MtE works

> One argument against this was that this makes it difficult to express the
> client's prioritization of TLS versions, but IMHO arguably the server
> should not care.

I don't think we should depart from the "highest mutually supported version" 
negotiation algorithm, any kind of preference in the client list is likely to 
cause additional problems - version misnegotiation

if client will want to advertise support for TLSv1.3 and TLSv1.5 but not 
TLSv1.4 it will still be able to do that
 
> -Original Message-
> From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of Hubert Kario
> Sent: Wednesday, September 14, 2016 9:40 AM
> To: David Benjamin 
> Cc: tls@ietf.org
> Subject: Re: [TLS] Version negotiation, take two
> 
> On Wednesday, 14 September 2016 16:17:50 CEST David Benjamin wrote:
> 
> > Yes, we find list intolerance too---servers which only look at the 
> > second byte in a cipher suite, servers which forgot a default in their 
> > NamedGroup switch-case, servers which get confused on unknown 
> > HashAlgorithms, servers which require the final extension 
> > non-empty---but this is dramatically less than version intolerance. 
> > It's usually within tolerable levels that we needn't resort to fallbacks.
> > 
> > The proposal switches from something which we know does not work to 
> > something new. Perhaps this new one will break too, but it is very 
> > similar to things that have worked before, and I am hopeful that GREASE
> > will help.
> 
> Was the option to do "one extension point = specific TLS version supported"
> 
> discussed too? What arguments are there against it?
> 
> --
> Regards,
> Hubert Kario
> Senior Quality Engineer, QE BaseOS Security team
> Web: www.cz.redhat.com
> Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic


-- 
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic

signature.asc
Description: This is a digitally signed message part.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Version negotiation, take two

[Andrei Popov]

Do you mean a TLS extension code point per TLS version?
One argument against this was that this makes it difficult to express the 
client's prioritization of TLS versions, but IMHO arguably the server should 
not care.

Cheers,

Andrei

-Original Message-
From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of Hubert Kario
Sent: Wednesday, September 14, 2016 9:40 AM
To: David Benjamin 
Cc: tls@ietf.org
Subject: Re: [TLS] Version negotiation, take two

On Wednesday, 14 September 2016 16:17:50 CEST David Benjamin wrote:
> Yes, we find list intolerance too---servers which only look at the 
> second byte in a cipher suite, servers which forgot a default in their 
> NamedGroup switch-case, servers which get confused on unknown 
> HashAlgorithms, servers which require the final extension 
> non-empty---but this is dramatically less than version intolerance. 
> It's usually within tolerable levels that we needn't resort to fallbacks.
> 
> The proposal switches from something which we know does not work to 
> something new. Perhaps this new one will break too, but it is very 
> similar to things that have worked before, and I am hopeful that GREASE will 
> help.

Was the option to do "one extension point = specific TLS version supported" 
discussed too? What arguments are there against it?

--
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Version negotiation, take two

[Hubert Kario]

On Wednesday, 14 September 2016 16:17:50 CEST David Benjamin wrote:
> Yes, we find list intolerance too---servers which only look at the second
> byte in a cipher suite, servers which forgot a default in their NamedGroup
> switch-case, servers which get confused on unknown HashAlgorithms, servers
> which require the final extension non-empty---but this is dramatically less
> than version intolerance. It's usually within tolerable levels that we
> needn't resort to fallbacks.
> 
> The proposal switches from something which we know does not work to
> something new. Perhaps this new one will break too, but it is very similar
> to things that have worked before, and I am hopeful that GREASE will help.

Was the option to do "one extension point = specific TLS version supported" 
discussed too? What arguments are there against it?

-- 
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic

signature.asc
Description: This is a digitally signed message part.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Version negotiation, take two

[David Benjamin]

On Wed, Sep 14, 2016 at 11:46 AM Benjamin Kaduk  wrote:

> On 09/14/2016 04:56 AM, Hubert Kario wrote:
>
> First, I don't think that the argument that the current version scheme doesn't
> lend itself to future-proofing is correct. Just as with GREASE, browsers can
> send much higher version than they really support if they do that on a time
> limited basis.
>
>
> David had previously convinced me that it doesn't actually work very well,
> but I forget the reasoning he used to do so. :(
>

Right, this was suggested at Berlin but is not very realistic.

First it requires that clients do so with very careful precautions
(time-limited, server-side field trials, etc.). There cannot be
fake-TLS-1.4 clients by the time real-TLS-1.4 is to exist. If enough
implementations mess up, we lose. With a list, any library can freely
implement this without depending on extra infrastructure.

Second, even if we were to advertise TLS 1.4 when we really mean TLS 1.3,
we still cannot deploy TLS 1.3 as-is without a TLS 1.2 fallback.
Version-intolerant servers will continue to get deployed unnoticed. We need
to get to a quiet point where the extension point works before we can start
meaningfully applying GREASE. All GREASE does is try to exercise
rarely-exercised extension point.

Because I am unreasonably amused by this metaphor, if the joint has
completely rusted shut already, we won't be able to get the GREASE in
there. It needs to have some mobility left.

Second, while the "joint" which handles new extensions IDs doesn't seem to be
> rusting, it's not the case with lists in particular extensions. SNI being the
> prime example where sending anything but a single host name value will most
> likely lead to your client hello being either misinterpreted or rejected.
>
>
>
> But people will ~always be sending multiple elements in the list in the
> version-negotiation extension -- you can't just send TLS 1.3; you also send
> 1.2 for the near future.  And if browsers are grease-ing from the
> beginning, I don't really see this one rusting.
>

Right, SNI should just never have been an extension point. We have
multi-valued lists elsewhere and they've worked fine. I can only speak to
Chrome's experience, but we add cipher suites without worry. We
successfully deployed X25519. RSA-PSS is going through the release process
now. (We expect breakage from an old NSS bug, but probes of top sites
suggest it will be tolerable.) TLS 1.3 adds even more lists. We're already
assuming lists work.

Yes, we find list intolerance too---servers which only look at the second
byte in a cipher suite, servers which forgot a default in their NamedGroup
switch-case, servers which get confused on unknown HashAlgorithms, servers
which require the final extension non-empty---but this is dramatically less
than version intolerance. It's usually within tolerable levels that we
needn't resort to fallbacks.

The proposal switches from something which we know does not work to
something new. Perhaps this new one will break too, but it is very similar
to things that have worked before, and I am hopeful that GREASE will help.

David
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Version negotiation, take two

[Benjamin Kaduk]

On 09/14/2016 04:56 AM, Hubert Kario wrote:
> First, I don't think that the argument that the current version scheme 
> doesn't 
> lend itself to future-proofing is correct. Just as with GREASE, browsers can 
> send much higher version than they really support if they do that on a time 
> limited basis.

David had previously convinced me that it doesn't actually work very
well, but I forget the reasoning he used to do so. :(

> Second, while the "joint" which handles new extensions IDs doesn't seem to be 
> rusting, it's not the case with lists in particular extensions. SNI being the 
> prime example where sending anything but a single host name value will most 
> likely lead to your client hello being either misinterpreted or rejected.
>

But people will ~always be sending multiple elements in the list in the
version-negotiation extension -- you can't just send TLS 1.3; you also
send 1.2 for the near future.  And if browsers are grease-ing from the
beginning, I don't really see this one rusting.

-Ben
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Suspicious behaviour of TLS server implementations

[Hubert Kario]

On Wednesday, 14 September 2016 15:35:16 CEST Andreas Walz wrote:
> Hi,
> 
> >>> Hubert Kario  09/12/16 6:56 PM >>>
> > 
> > are you aware of the tlsfuzzer framework?
> > https://github.com/tomato42/tlsfuzzer
> 
> @Hubert Kario: Thanks for pointing me to tlsfuzzer. I had a look at the
> repository before and I skimmed through the code. However, I didn't run the
> code and I don't know details about the way it is generating input. Is
> there some paper or presentation about it?

there are presentation slides in the docs/ directory

Decision which messages are to be generated is done using scenarios that 
describe conversations between client and server. See in scripts/ for them; a 
simple example is scripts/test-conversation.py while an example of negative 
test would be scripts/test-early-application-data.py

in tlsfuzzer/messages.py is the code that generates the messages, client hello 
is here:
https://github.com/tomato42/tlsfuzzer/blob/master/tlsfuzzer/messages.py#L306

Example of a test case you were asking about (the one with data extending past 
extensions) would be scripts/test-truncating-of-client-hello.py

The messages themselves are generated through a combination of sensible 
defaults and "guessing" expected values by inspecting already exchanged 
messages (think TLS state machine that explicitly has support for any state 
transitions).

In general, it allows you to both negotiate connections and send arbitrary 
messages (through changing their order, modifying them pre or post encryption, 
or sending raw values). In particular, it does support renegotiation despite 
the the fact that the underlying tls library doesn't.
-- 
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic

signature.asc
Description: This is a digitally signed message part.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Suspicious behaviour of TLS server implementations

[Andreas Walz]

Hi,

>>> Hubert Kario  09/12/16 6:56 PM >>>
> are you aware of the tlsfuzzer framework?
> https://github.com/tomato42/tlsfuzzer

@Hubert Kario: Thanks for pointing me to tlsfuzzer. I had a look at the 
repository before and I skimmed through the code. However, I didn't run the 
code and I don't know details about the way it is generating input. Is there 
some paper or presentation about it? 

>>> Peter Gutmann  09/14/16 1:39 PM >>>
> My code checks for extensions all the way down, but I could quite easily be
> persuaded that ignoring trailing garbage is OK too, based on what earlier
> versions of TLS did.  Like RFC 3546 originally did for extensions, some future
> RFC might add a new field at the end, so not failing on finding more data may
> be a good thing.  Or at least I can't see why it would be a bad thing.

@Peter Gutmann: Thanks for your take on that. Actually, and I might easily be 
missing something here, I do see some issues with adding new fields to the 
ClientHello in the future (i.e. following the "client_hello_extension_list"). 
As far as I can see, there is no way within a ClientHello to convey some kind 
of a version of the ClientHello format itself (as the ClientHello's version 
field is just indicating the highest version the client supports). That is, the 
only mechanism I see here is the same as the one that allowed to add extensions 
to a ClientHello message with RFC3546. However, that door has explicitly been 
closed therein in section 2.1 (as Hubert Kario pointed out)

A server that supports the extensions mechanism MUST accept only
client hello messages in either the original or extended ClientHello
format, and (as for all other messages) MUST check that the amount of
data in the message precisely matches one of these formats; if not
then it MUST send a fatal "decode_error" alert.  This overrides the
"Forward compatibility note" in [TLS].

A similar statement is given in RFC5246, section 7.4.1.2.:

A server MUST accept ClientHello
messages both with and without the extensions field, and (as for all
other messages) it MUST check that the amount of data in the message
precisely matches one of these formats; if not, then it MUST send a
fatal "decode_error" alert.

Thus, to my understanding, any new field in the ClientHello would automatically 
break backward compatibility (at least with older compliant servers or unless 
everyone explicitly skips a MUST check in the interest of forward 
compatibility).

___

Andreas Walz
Research Engineer
Institute of reliable Embedded Systems and Communication Electronics (ivESK)
Offenburg University of Applied Sciences, 77652 Offenburg, Germany





>>> Peter Gutmann  09/14/16 1:39 PM >>>
Martin Rex  writes:

>The actual problem is the design flaw in TLS that availability of null
>compression is not implied, but rather given a seperate codepoint, and the
>server choosing null compression and continuing even when it is not
>explicitly asserted by the client, is a server silently making up for that
>design flaw in the TLS spec.

Yup, and I'd say it's perfectly valid behaviour.  Compression is an optional
extra, but you need to explicitly specify that you don't want it, something
that's popular in the PKI world where you have a supposedly optional
capability that isn't actually optional so you need to fill it with a dummy
value to indicate that you don't care about it.

>Up to TLSv1.2, TLS extensions were purely optional, so an implementation that
>unconditionally ignores everything following compression methods is at least
>fully conforming to SSLv3, TLSv1.0 and TLSv1.1.
>
>For an TLS implementation that parses TLS extensions, the behaviour of what
>to do about trailing garbage is a different matter.  Personally I prefer
>aborting in case of garbage trailing TLS extensions.

My code checks for extensions all the way down, but I could quite easily be
persuaded that ignoring trailing garbage is OK too, based on what earlier
versions of TLS did.  Like RFC 3546 originally did for extensions, some future
RFC might add a new field at the end, so not failing on finding more data may
be a good thing.  Or at least I can't see why it would be a bad thing.

>What the server does in presence of multiple TLS extensions of the same type
>is implementation defined.  I think it would be extremely reasonable for a
>server to perform a simple plausibility check on decode whether it is
>decoding the same TLS extension more than once, and then abort with a
>decode_error alert, in order to have ambiguities caught early. Recognizing
>duplicate TLS extensions that the server does not support/implement does not
>(yet) create ambiguities (for that server) and requires more complex code, so
>I would not implement that check.

+1.  Remembering that you've already done a known extension is one thing, but
having to 

Re: [TLS] Suspicious behaviour of TLS server implementations

[Peter Gutmann]

Martin Rex  writes:

>The actual problem is the design flaw in TLS that availability of null
>compression is not implied, but rather given a seperate codepoint, and the
>server choosing null compression and continuing even when it is not
>explicitly asserted by the client, is a server silently making up for that
>design flaw in the TLS spec.

Yup, and I'd say it's perfectly valid behaviour.  Compression is an optional
extra, but you need to explicitly specify that you don't want it, something
that's popular in the PKI world where you have a supposedly optional
capability that isn't actually optional so you need to fill it with a dummy
value to indicate that you don't care about it.

>Up to TLSv1.2, TLS extensions were purely optional, so an implementation that
>unconditionally ignores everything following compression methods is at least
>fully conforming to SSLv3, TLSv1.0 and TLSv1.1.
>
>For an TLS implementation that parses TLS extensions, the behaviour of what
>to do about trailing garbage is a different matter.  Personally I prefer
>aborting in case of garbage trailing TLS extensions.

My code checks for extensions all the way down, but I could quite easily be
persuaded that ignoring trailing garbage is OK too, based on what earlier
versions of TLS did.  Like RFC 3546 originally did for extensions, some future
RFC might add a new field at the end, so not failing on finding more data may
be a good thing.  Or at least I can't see why it would be a bad thing.

>What the server does in presence of multiple TLS extensions of the same type
>is implementation defined.  I think it would be extremely reasonable for a
>server to perform a simple plausibility check on decode whether it is
>decoding the same TLS extension more than once, and then abort with a
>decode_error alert, in order to have ambiguities caught early. Recognizing
>duplicate TLS extensions that the server does not support/implement does not
>(yet) create ambiguities (for that server) and requires more complex code, so
>I would not implement that check.

+1.  Remembering that you've already done a known extension is one thing, but
having to track a potentially arbitrary number of extensions that you don't
know what to do with anyway doesn't seem worthwhile.  And then there's the
same problem as with ignoring extra data at the end of the hello, at some
point a future RFC may define an extension where having duplicate copies makes
sense or is even required for things to work.  So you don't really gain
anything by ignoring duplicate unknown extensions, and will potentially break
things in the future if you do reject them.

Having said that, some extensions are purely signalling extensions, like EMS
and EtM.  I'm not sure if there's any problem with accepting doubles of those,
it could just be the other side being emphatic.  Consider how you'd need to
report this to the user, "shut down the TLS connection because I saw two
copies of some extension you've never heard of before", you can imagine what a
user who sees that would think of the anal-retentive &^@#* who added special
code to the handshake in order to reject it if this condition is encountered.

Peter.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Version negotiation, take two

[Hubert Kario]

First, I don't think that the argument that the current version scheme doesn't 
lend itself to future-proofing is correct. Just as with GREASE, browsers can 
send much higher version than they really support if they do that on a time 
limited basis.

Second, while the "joint" which handles new extensions IDs doesn't seem to be 
rusting, it's not the case with lists in particular extensions. SNI being the 
prime example where sending anything but a single host name value will most 
likely lead to your client hello being either misinterpreted or rejected.

On Tuesday, 13 September 2016 13:18:34 CEST Sean Turner wrote:
> All,
> 
> There appears to be an emerging consensus here to adopt the change proposed
> by this PR.  Please indicate whether you are unwilling (and why) to accept
> this change by September 16th.
> 
> J
> 
> > On Sep 08, 2016, at 12:04, 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