Subject: [TLS] Thoughts on Version Intolerance

From: Hanno Böck <[email-masked]>
Date: Mon, 18 Jul 2016 13:08:43 +0200

Hi,

Recently both Adam Langley [1] and David Benjamin [2] indicated that
they expect with TLS 1.3 Browsers will have to bring back the infamous
version falbacks that caused so much trouble in the past (POODLE etc.)
to work around broken implementations of the TLS handshake.

I don't blame browser vendors for this, I can understand their
reasoning why they think they have to do this, although I don't share
their opinion. But I think this sheds a light on the sorry state of TLS
implementations and I want to ask if there's a better way out of this.

Let me quickly summarize how I see the situation:
* The issue has been known for a long time. I found a document from
  Mozilla [3] from 2003 that describes the core issue.
* While there is a lot of scattered discussion about the issue, the
  pure documentation status of this problem is far from ideal. I am not
  aware of any good documentation that even describes how exactly
  version intolerance happens. The "classic" variant seems to be
  implementations that just close the connection if they are contacted
  with a version number higher than what they support. But there are
  also weirder variants where a connection attempt with TLS 1.2 will be
  downgraded to SSLv3, but a connection attempt with TLS 1.0 will lead
  to an answer with TLS 1.0. Questions I couldn't easily answer is how
  connections are terminated (TCP disconnect? TLS alert? Timeouts?)
  Also I'm not fully aware what the different version numbers
  (ClientHelo + record version number) mean in context of a handshake
  and how this influences version intolerance issues.
* There don't seem to be any straightforward tools that test for
  version intolerance. The SSL Labs test does detect version
  intolerance, but it's limited to public facing https servers and it
  doesn't seem to detect some of the weirder variations (as described
  above). There's also a test in Hubert Kario's tlsfuzzer, but I've
  been unable to get it to work. I tried to create a test myself, but
  the results were highly erratic and I'm not sure why.
* We don't have good data on the issue. The latest numbers I could find
  came from Ivan Ristic in 2013 [4], and from David Benjamin we know he
  considers the problem to be large enough that version fallbacks are
  inevitable. That's far from good data. We also don't seem to have any
  public list of affected vendors, devices and webpages.

I want to try to work on some of those issues in the near future.
Roughly I'd like to see that we work on a plan to reduce TLS brokenness
in general and in particular - right now as this is an issue affecting
the deployment of TLS 1.3 - Version intolerance.

Things that I think we could and should do:
* Talk to developers of test tools (sslyze, testssl, openvas, but also
  commercial tools etc.) that they include appropriate tests in their
  tools and warn about these issues. Also it'd be great if e.g. things
  like the google webmaster tools or any other public test tools for
  webservers/websites could test for this.
* Raise this issue with pentesters and tell them they should include
  this when they're testing devices / products. (Of course this
  requires to have test tools in the first place.)
* Get some data from internet wide scans and make it public. Maybe have
  a public shame list of the top X pages breaking TLS.
* In general, more and better detailed documentation of this and
  similar issues, also raise this as a potential research topic.

My hope would be that we can avoid the reintroduction of version
fallbacks or at the very least reduce the amount of time they have to
be used. And hopefully at least avoid them altogether for TLS 1.4 or
whatever comes after 1.3.

I'm in Berlin at IETF96 in case people want to discuss this. As this is
terribly late for this I don't know if this can be included in the TLS
WG discussion as it's probably already packed with other issues (but I'd
happily introduce the issue if people want to discuss it).

[1] https://www.imperialviolet.org/2016/05/16/agility.html
[2] https://www.ietf.org/mail-archive/web/tls/current/msg20207.html
[3]
https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSS/Notes_on_TLS_-_SSL_3.0_Intolerant_Servers
[4] https://www.ietf.org/mail-archive/web/tls/current/msg10657.html

-- 
Hanno Böck
https://hboeck.de/

mail/jabber: [email-masked]
GPG: BBB51E42

---

From: Hubert Kario <[email-masked]>
Date: Mon, 18 Jul 2016 15:08:03 +0200

>   the results were highly erratic and I'm not sure why.

I hope that the updated README helps about this (just pushed the changes),
tell me if anything else is missing

feel free to send the problems with the test you wrote yourself
(but please remember, the note in README applies - it's an alpha, so
no API stability guarantees)

>   public list of affected vendors, devices and webpages.

I'm running a test against the Alexa Top 1 million /right now/ using this
code:
https://github.com/jvehent/cipherscan/pull/109

In general it's a rough check, i.e. it's only a check for client hello
version intolerance, irrespective of record layer version, ciphers or
extensions (it sends multiple probes, based on different clients and
then modified)

I've also added an Xmas-client hello message[1] that aims to trigger as
many intolerancies as possible, but it's mostly just to single out
some weirder servers.

e.g. some servers will just close connection if you send them an SNI
name they don't expect

 1 - similar to https://en.wikipedia.org/wiki/Christmas_tree_packet

>   webservers/websites could test for this.

+1, especially TLS 1.3 client hello version intolerance should be
an outright failure of any TLS test

>   a public shame list of the top X pages breaking TLS.

I'm working on it. I'll make the scan data public, but I'll leave the
shaming part to somebody else

>   similar issues, also raise this as a potential research topic.

+1 again, I think we should do a more "negative" reading of the TLS standard
(as in what the peer should do if the other side does not behave as
expected) both to specify what alerts should be sent, when, and when
such "misbehavior" MUST NOT trigger any failure in the other side

-- 
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

---

From: Ilari Liusvaara <[email-masked]>
Date: Mon, 18 Jul 2016 16:11:07 +0300

> implementations and I want to ask if there's a better way out of this.

Ocassionally browsers also send odd stuff: Recently I ran into a browser
that sends empty session_ticket (or whatever) instead of session_ticket
with empty ticket.

This becomes an issue when the server is pretty hard about TLS hanshake
syntax.
 
>   and how this influences version intolerance issues.

Things are made even more complicated by the intearction of extension
intolerance: Newer TLS versions might involve new extensions, which
may choke a server, causing extension intolerance to be misdiagnosed
as version intolerance.

>   the results were highly erratic and I'm not sure why.

Also, I have seen at least one server that SSL labs claimed is
intolerant to TLS 1.2, but browser could connect using TLS 1.2
ClientHello without fallback (verified using wireshark).

No real idea what caused that.
 
>   webservers/websites could test for this.

I think SSL labs has had TLS 1.3 intoleance test for a long time. Of
course, it probably doesn't test with what real-world TLS 1.3 ClientHello
looks like...

-Ilari

---

From: David Benjamin <[email-masked]>
Date: Mon, 18 Jul 2016 13:30:04 +0000

If we keep trying to salvage the ClientHello version number, we will be
chasing down intolerance forever. (And I'm honestly bored of doing that.)
I'd prefer we move it to an extension. Either an empty indicator extension
for each version or a single version extension with a list of versions. Or
maybe fake cipher suites if people want it nearer the front.

The important thing is lists can be actively defended. We simply burn a
bunch of u16s and have clients advertise a few random fake ones in every
ClientHello. (I'll be writing something up soon to request that range for
extensions, cipher suites, and curves.) I expect this will make it much
less likely anyone will accidentally ship a server that rejects unknown
versions (or whatever else).

On Mon, Jul 18, 2016 at 1:08 PM Hanno Böck <[email-masked]> wrote:

>   to an answer with TLS 1.0.

(I have only seen this once. I'm guessing someone tried to write a filter
which dispatched between two different backends and got it wrong.)

> Questions I couldn't easily answer is how

Connections can get shut off in all kinds of ways. It's buggy servers
getting confused, so the space is pretty open-ended. Various flavors of TCP
disconnects happen, as do alerts. (Not timeouts. Those we can't even
address with a fallback.)

>   and how this influences version intolerance issues.

The record version number is meaningless in the protocol. It's frozen at
TLS 1.0 for the ClientHello (and, in 1.3, for all records) and not relevant
for version negotiation or fallbacks.

(Note: at least a while ago SSL Labs' intolerance check incorrectly used
the record-layer number. I don't know if this has been fixed. But apart
from that bug, there is no relation between the two.)

>   public list of affected vendors, devices and webpages.

I have quite conclusive data. TLS 1.3 version intolerance is real. The
version negotiation mechanism in draft-ietf-tls-tls13-14 will not be
deployable on the web without a fallback. 2% is a very large number.

I don't want to play the "davidben publicly shames such-and-such site or
vendor" game, which is why I haven't been naming names and reaching out to
people privately. If you prefer a more noisy approach, I didn't do anything
complicated. Just send a 1.2 ClientHello and then swap the number for 1.3
to see if it stopped working.

>   webservers/websites could test for this.

Test suites are great, but I don't think we can rely on people to know to
run them in every corner of the ecosystem.

> whatever comes after 1.3.

The only way we're going to do that is by ditching the ClientHello.version
field.

> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>

---

From: Hubert Kario <[email-masked]>
Date: Wed, 20 Jul 2016 11:20:46 +0200

> many intolerancies as possible, but it's mostly just to single out

So I have partial results after scanning around 14 000 domains.
The scanner was able to connect to 12 606 hosts that presented unexpired
certificates signed by CA's in Mozilla root program.

Of those:
93% support TLSv1.2 protocol (11807)
a single one is intolerant to TLSv1.2 Client Hello
3.7% (469) are intolerant to TLSv1.3 Client Hello
4.4% (556) are intolerant to TLSv1.4 Client Hello

(by intolerant, I mean, I was not able to connect to them with any hello
message that looked like an IE, Chrome or Firefox Client Hello with just
version changed or additionally some or all extensions removed)

at the same time, 15.5% (1965) are intolerant to an "Xmas tree" Client
Hello (one that includes many ciphers, few TLSv1.3 key shares, etc. bringing
its size to something like 2800 bytes)
49% (6240) are intolerant to a Client Hello with no extensions but
big number of ciphers that bring its size to 16388 bytes)
91.5% (11539) are intolerant to a Client Hello with no extensions
but a number of ciphers that bring it well above single record layer limit
(16.5KiB)

so it looks to me like while we may gain a bit of compatibility by
using extension based mechanism to indicate TLSv1.3, it looks to
me like the 1RTT mechanism will uncover more bugs like the one in F5
accelerators (the 256-512 byte black hole)
-- 
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

---

From: Hanno Böck <[email-masked]>
Date: Wed, 20 Jul 2016 12:01:25 +0200

On Wed, 20 Jul 2016 11:20:46 +0200
Hubert Kario <[email-masked]> wrote:

> using extension based mechanism to indicate TLSv1.3,

Just quick: This was discussed yesterday, David Benjamin had an
interesting proposal, but it was largely met with resistance. So from
the WG discussion yesterday I had the impression that we will most
likely stay with the existing clienthello version mechanism. While that
will cause us more trouble, it's probably the cleaner option anyway. So
we definitely should continue investigating version intolerance and
tell people to fix their stuff.

I'm now also collecting some data and have some preliminary
suspicion on affected devices. My numbers roughly match yours that we
are in the more or less 3% area of 1.3 intolerance.

-- 
Hanno Böck
https://hboeck.de/

---

From: [email-masked] (Martin Rex)
Date: Wed, 20 Jul 2016 12:14:01 +0200 (CEST)

Hanno Böck wrote:

Checking application/pgp-signature: FAILURE
>> using extension based mechanism to indicate TLSv1.3,

Forget TLS extensions, forget ClientHello.client_version.
Both in fundamentally broken, and led to Web Browsers coming up
with the "downgrade dance" that is target&victim of the POODLE attack.

We know fairly reliably what kind of negotiation works just fine:
TLS cipher suite codepoints.

Please define *ALL* TLSv1.3-specific cipher suites to
  a) indicate that the client offering it supports (at least) TLSv1.3
  b) that indication (a) will override any lower ClientHello.client_version
     that may have been used for backwards compatibility.

> are in the more or less 3% area of 1.3 intolerance.

The TLSv1.2 version intolerance is already a huge problem,
and I'm not seeing it go away.  Acutally Microsoft created an
awfully large installed base of TLSv1.2-intolerant servers
(the entire installed base of Win7 through Win8.1 aka 2008R2, 2012, 2012R2).

I would really like to see the TLS WG improving the situation
rather than keep sitting on its hands.  The problem has been well-known
since 2005.  And the "downgrade dance" was a predictably lame approach
to deal with the situation, because it completely subverts/evades the
cryptographic protection of the TLS handshake.

-Martin

---

From: Ilari Liusvaara <[email-masked]>
Date: Wed, 20 Jul 2016 13:57:36 +0300

> its size to something like 2800 bytes)

Wonder how big part of the difference is due to steps (eg. 1024 and
2048 bytes) in between and how much is due to the extra extensions or
cihpers.

> but a number of ciphers that bring it well above single record layer limit

Wonder how much of that is again size thresholds (in Ciphersuites and
in total ClientHello size) and how much is fragmenting the Client
Hello to multiple fragments...

-Ilari

---

From: Hubert Kario <[email-masked]>
Date: Wed, 20 Jul 2016 14:36:06 +0200

> TLS cipher suite codepoints.

please re-read my mail, they don't:

> cryptographic protection of the TLS handshake.

it's not IETF's fault that the implementers add unspecified by IETF
restrictions and limitations to parsers of Client Hello messages or that
they can't handle handshake messages split over multiple record layer
messages, despite the standard being very explicit in that they MUST
support this

---

From: Hubert Kario <[email-masked]>
Date: Wed, 20 Jul 2016 14:46:51 +0200

On Wednesday, 20 July 2016 13:57:36 CEST Ilari Liusvaara wrote:
> > Hello (one that includes many ciphers, few TLSv1.3 key shares, etc.
> > bringing its size to something like 2800 bytes)
> 

yes, that's something I'd like to figure out too, but I was thinking of
using a bisect approach to do it, so it will be more complex to do =>
I won't do this for this month's scan

patches welcome, though :)

---

From: Kyle Rose <[email-masked]>
Date: Wed, 20 Jul 2016 14:49:03 +0200

> messages, despite the standard being very explicit in that they MUST

When the failures are limited to obscure implementations, and/or popular
ones with a hope of being updated, I'm in the "fix your shit" camp.

When a substantial fraction of the internet breaks, this approach is less
clearly the right one because it can result in the never-ending downgrade
dance, or in limited deployment of new versions/ossification. I hope (with
no real evidence) that given the strong level of involvement of the major
browsers in 1.3 development that advantage goes to the client.

Kyle

---

From: Hubert Kario <[email-masked]>
Date: Wed, 20 Jul 2016 15:13:57 +0200

> browsers in 1.3 development that advantage goes to the client.

I think that implementing complex binary cryptographic protocols is simply 
hard.

At the same time many corner cases are not encountered in day to day use, many 
failures are completely silent (TLS POODLE).

Which means that many implementers stop working on their TLS stack as soon as 
they can connect to default OpenSSL instance or to google.com, or can process 
hello message from Internet Explorer/Chrome.

While I think that the standard should be more strict, and the section D.4. we 
know from RFC 5246 should be much longer in the TLSv1.3 document, it won't 
matter if the implementers won't read the thing.

And from what I can see, people that implemented the servers that 90% of Alexa 
top 1 million sites use, simply haven't recognized that section D is 
important. Let alone tested that their implementation actually follows 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

---

From: Watson Ladd <[email-masked]>
Date: Wed, 20 Jul 2016 06:24:50 -0700

> On Wednesday, 20 July 2016 14:49:03 CEST Kyle Rose wrote:
<snip>
> I think that implementing complex binary cryptographic protocols is simply
And what conclusion should one draw about TLS 2.0 (*ahem* 1.3) as a
result of this realization?

One hopes the IETF manages to avoid overcomplicating (extending and
supporting necessary usecases actually) QUIC. I've given up on any
substantial improvements in TLS.

Sincerely,
Watson

---

From: Hubert Kario <[email-masked]>
Date: Wed, 20 Jul 2016 15:37:05 +0200

> result of this realization?

we need what I'm already working on - a test suite (and a standard that
makes it easy to know what is the expected behaviour for an implementation, in 
all cases)

---

From: Benjamin Kaduk <[email-masked]>
Date: Wed, 20 Jul 2016 10:43:37 -0500

> interesting proposal, but it was largely met with resistance. So from

I had some follow-up discussion with David and a few others later in the
day.  One point that I think was not clear during the WG session was
whether the check for whether a server's version negotiation is
futureproof could be done in the hot path, so that it is impossible to
implement a server that works in a major browser and is (e.g., 1.4)
version-intolerant.

Right now, if a browser wants to probe for (e.g., 1.3) version
intolerance, it essentially has to treat it as a data-collection step,
either doing the fallback dance on failure or just doing the probe in
parallel with a 1.2 clienthello that is actually used for the
connection, since we know that 1.3-intolerance exists.  With David's
proposal (and potentially variants of the other ones), browsers could
implement a check that sends nonexistent versions in their clienthello,
so that once a server implements 1.3, it would not be 1.4-intolerant.

If we just keep with the current version negotiation scheme, we'll
always be stuck in the "data-collecting" mode and won't be able to
strictly enforce the future-proofing, since there are existing servers
that are intolerant to the current scheme, and the browsers will be
blamed for breaking sites on those servers if the browsers try to
introduce strict enforcement of version negotiation future-proofing.

-Ben

---

From: [email-masked] (Martin Rex)
Date: Wed, 20 Jul 2016 19:30:27 +0200 (CEST)

Hubert Kario wrote:
> Martin Rex wrote:

You're seriously confusing things here.

Any ClientHello with > 200 Cipher suite code points indicates fairly insane
Client behaviour, so rejecting it is _perfectly_sane_ server behaviour.

Trying to support theoretical encoding size limits is a stupid idea,
because it leads to endless security problems.  Imposing sane sizes
plus a safety margin is solid implementation advice.

Large stuff that doesn't need to be exchanged in abbreviated handshakes
should *NEVER* be included in ClientHello, because of the performance
penalties this creates (Network bandwidth for TLS handshake,
and TCP slow start).

>> (the entire installed base of Win7 through Win8.1 aka 2008R2, 2012, 2012R2).

Please recheck with a vanilla (aka extension-free) ClientHello that
has ClientHello.client_version = (3,3), to recognize all TLSv1.2-intolerant
implementations in your counts.

> support this.

Nope, not really.  Limiting PDU sizes to reasonably sane sizes is
perfectly valid behaviour.  X.509v3 certificates can theoretically include
CAT MPEGs and amount to megabytes.  A TLS implementation that limits
the certificate chain (i.e. the TLS Certificate Handshake message) to
a reasonably sane size with safety margin, say 32 KBytes in total,
is acting totally reasonable.  Anyone who creates an insane PKI deserves
to loose, and deserves to loose quite badly.

-Martin

---

From: Watson Ladd <[email-masked]>
Date: Wed, 20 Jul 2016 11:11:56 -0700

> Client behaviour, so rejecting it is _perfectly_sane_ server behaviour.

The IANA registry contains
> plus a safety margin is solid implementation advice.

No, using languages that permit memory safety violations leads to problems.
Somehow I doubt you would call avoiding those languages sane implementation
advice. Yes, a device with 8kbyte RAM could have a problem with large
Client Hellos, but I doubt that is the issue here.

> implementations in your counts.

Since TLS 1.0 servers have been instructed to ignore extensions, which
finally got used in TLS 1.2. Hardly matters exactly what causes the problem.

> to loose, and deserves to loose quite badly.

Unless we specify minimum sizes that must be handled, this creates
difficult interop problems, particularly when sizes need to be expanded.
That size is less then one SPHINCS signature for instance.

---

From: David Benjamin <[email-masked]>
Date: Thu, 21 Jul 2016 10:19:34 +0000

> introduce strict enforcement of version negotiation future-proofing.

[Credit where credit is due, I was not the first to propose the version
list. I don't know who was first, but Dave Garrett had proposed the same
thing. The TLS 1.3 implementors effectively did so too with the draft
version extension. Though I think the fake versions idea is new?]

I should also add that, even if we ever got to our prerequisite quiet
point, this scheme is still problematic. If we had a list, all clients
could participate in this fuzzing and we have a shot at vaccinating the
ecosystem. This one violates the specification, so only clients which can
rapidly deploy changes can safely do it. (Some sort of field trial
mechanism, for instance.) And it requires manual work to sustain: I would
probably only do it for, say, 3 months at a time and manually extend so
long as TLS 1.4 does not exist. I would not want to cause problems by
forgetting to turn it off.

And as Hubert notes, there may well be other intolerance triggers to clear
through. 1.3 has a larger ClientHello. We have also never added a new
signature algorithm before. But I think that just means we have more rusted
protocol joints fix rather than just the one.

Fortunately, most of our other joints admit this kind of fuzzing. It's just
the versioning scheme (fixable with a list), and large ClientHellos. I
don't have a good answer to the second one, but I would be very happy if it
were our only problem. It's much easier to understand. The version one is
surprisingly difficult. The conversations usually go like this:

"Hi, your server software appears to have a bug where you reject TLS 1.2
ClientHellos rather than implementing the version negotiation right."
"Okay, we will deploy TLS 1.2."
"No, please don't fix this with 1.2. That's a different problem."
"You don't want us to add 1.2?"
"No no no. Please do switch to 1.2. I mean... oh, nevermind. I'll just
email you later for 1.3."

I am obviously exaggerating for humor, but it's a very common confusion and
I think is part of why version intolerance keeps on existing.

If you implement the latest version of TLS but are intolerant to N+1, even
if no clients did fallbacks, your bug will not be noticed and you'll thrive
in the ecosystem. Then when we go to deploy N+1, we have problems. We want,
as much as possible, turn tomorrow's interop failures into today's interop
failures so the bugs are caught before software ships.

David

---

From: Hubert Kario <[email-masked]>
Date: Thu, 21 Jul 2016 12:42:52 +0200

> Client behaviour, so rejecting it is _perfectly_sane_ server behaviour.

and which part of the standard says that it is "_perfectly_sane_" server 
behaviour?
 
> plus a safety margin is solid implementation advice.

unlike the endless incompatibility problems?

> penalties this creates (Network bandwidth for TLS handshake,

I suggest you take a look at the key_share extension and what are the size 
requirements for PQcrypto key exchanges

> implementations in your counts.

and what about those servers that will abort connection if the RC4 ciphes are 
below the 64'th position in the list?

> to loose, and deserves to loose quite badly.

if it's valid, please point me to the part of RFC that says that.

and we're not talking about Certificate message here, we're talking about 
Client Hello. The absolute upper size limit for it is 131396 bytes. Any 
implementation that can't process messages that big is simply RFC non 
compliant.

Besides, so what that you can send megabyte sized certificates thought TLS?
even if you do consider it a DoS, pausing the ECDHE key exchange with
a large curve just before Client Key Exchange message is a far more effective 
use of attacker's resources.
-- 
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

---

From: Ilari Liusvaara <[email-masked]>
Date: Thu, 21 Jul 2016 13:52:46 +0300

> protocol joints fix rather than just the one.

Could be useful to scan for SignatureScheme. I think the most worthwhile 6
to scan would be:

0x0003 (ECDSA-NONE in TLS 1.2)
0x0004 (UNKNOWN4-NONE in TLS 1.2)
0x0404 (UNKNOWN4-SHA256 in TLS 1.2)
0x0700 (ANON-UNKNOWN7 in TLS 1.2)
0x0703 (ECDSA-UNKNOWN7 in TLS 1.2)
0x0704 (UNKNOWN4-UNKNOWN7 in TLS 1.2)

And then see how many servers do anything retarded with these...

-Ilari

---

From: Peter Gutmann <[email-masked]>
Date: Thu, 21 Jul 2016 12:25:48 +0000

Martin Rex <[email-masked]> writes:

>Limiting PDU sizes to reasonably sane sizes is perfectly valid behaviour.
>X.509v3 certificates can theoretically include CAT MPEGs and amount to
>megabytes.

We really need a TLS scanner that does this just to see what happens.  When I
created that cat-MPEG cert, I fed it to both MSIE and Netscape.  Both happily
accepted it, and then essentially become nonfunctional because although they
saw nothing wrong with accepting a cert of that size, they couldn't actually
deal with it.  In Netscape's case I had to delete the .db file before it could
be used again.  I wouldn't be surprised if you can quite effectively DoS
assorted TLS implementations with stuff like this.

(This is one of the design features of TLS-LTS, if both sides do -LTS then the
Hello only needs a single extension to specify everything.  Combine that with
PSK, so no certs, and you get quite an efficient protocol, the only thing of
any size is the keyex and server signature).

Peter.

---

From: Hubert Kario <[email-masked]>
Date: Thu, 21 Jul 2016 14:35:32 +0200

On Thursday, 21 July 2016 12:25:48 CEST Peter Gutmann wrote:
> We really need a TLS scanner that does this just to see what happens.  When
> I created that cat-MPEG cert, I fed it to both MSIE and Netscape.  Both
> happily accepted it, and then essentially become nonfunctional because
> although they saw nothing wrong with accepting a cert of that size, they
> couldn't actually deal with it.  In Netscape's case I had to delete the .db
> file before it could be used again.  I wouldn't be surprised if you can
> quite effectively DoS assorted TLS implementations with stuff like this.

if you have such certificate, you can use this script from tlsfuzzer to test 
if server won't explode by processing it:
https://github.com/tomato42/tlsfuzzer/blob/master/scripts/test-rsa-sigs-on-certificate-verify.py

(I haven't tested if it actually can send a 2MiB large certificate, but in 
general there are no limits in tlslite-ng or tlsfuzzer, so it should work just 
fine, bugreports welcome if that is not the case).

---

From: Dave Garrett <[email-masked]>
Date: Thu, 21 Jul 2016 16:04:25 -0400

> and which part of the standard says that it is "_perfectly_sane_" server 

On this specific type of issue, I agree with Martin here that sanity checks for over-the-top configurations are reasonable, however we should be standardizing this, not having every implementation do this ad hoc. We really should go through a list of these sort of implementation break points and start picking arbitrary lines to add to the spec. They don't have to be ideal numbers; just something better than an upper limit of 2^15-2 suites (2 bytes each; 2^16-2 max sized vector) would be nice, for this example. Yes, certain fields have to stay open-ended, namely extensions, but reasonable limits should be added where appropriate.

Dave

---

From: Hubert Kario <[email-masked]>
Date: Fri, 22 Jul 2016 12:08:00 +0200

On Thursday, 21 July 2016 16:04:25 CEST Dave Garrett wrote:
> On this specific type of issue, I agree with Martin here that sanity checks
> for over-the-top configurations are reasonable, however we should be
> standardizing this, not having every implementation do this ad hoc. We
> really should go through a list of these sort of implementation break
> points and start picking arbitrary lines to add to the spec. They don't
> have to be ideal numbers; just something better than an upper limit of
> 2^15-2 suites (2 bytes each; 2^16-2 max sized vector) would be nice, for
> this example. Yes, certain fields have to stay open-ended, namely
> extensions, but reasonable limits should be added where appropriate.

I don't think that limiting the client hello by just under 2^16 bytes will 
help much.

For memory-limited applications, simply not noting the presence
of unrecognised/unsupported ciphers is an easy and robust way of handling huge 
cipher lists. So limiting it doesn't help much. As you've pointed out, 
extension list needs to stay unlimited. There's nothing else - session_id 
already is tiny and compression_methods is just a drop, everything else has 
static sizes.

I'm quite sure that if I were sending a huge extension or many big extensions, 
the percentage of servers that are incompatible to them would be similar, if 
not worse. A relatively small 3KiB client hello already causes issues and this 
is not exactly something impossible to achieve with just TLSv1.2 and session 
tickets. 

(I'll try to have more concrete numbers on Monday)
-- 
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

---

From: Brian Smith <[email-masked]>
Date: Fri, 22 Jul 2016 15:37:24 -1000

> is not exactly something impossible to achieve with just TLSv1.2 and session

Don't expect a server to accept a ClientHello with a session ticket it
didn't produce. In particular, a server could very reasonably reject a
session ticket larger than the ones it produces, and it might produce
only very small ones.

More generally, when assessing compatibility, generally it is better
to consider only initial handshakes, using the data one would normally
send in an initial handshake. And, if you are considering 0-RTT key
shares, then it would be better to measure the case where only ECC key
shares are used separately from the case where non-ECC (old-school DH)
key shares are used.

Cheers,
Brian

---

From: David Benjamin <[email-masked]>
Date: Sat, 23 Jul 2016 06:03:41 +0000

> shares are used separately from the case where non-ECC (old-school DH)

Indeed I just finished a probe that tested many more handshake variations:

1. 1.2 ClientHello
2. 1.3 ClientHello with all curves predicted[*]
3. 1.3 ClientHello with only X25519 + P-256 predicted
4. 1.2 ClientHello with 1.3 sigalgs
5. 1.2 ClientHello with fake 1.3 version

I still need to fully analyze the data and experiment with the servers that
behave strangely, but the overwhelming majority of 1.3-intolerant servers
are intolerant to just the version. (They fail to connect with only 2, 3,
and 5.)

(Note that one must complete the handshake to get a full picture. Sending
the ClientHello isn't enough. Full analysis pending, but sending a 1.2
ServerHello and failing around the Finished message seems to happen often
enough.)

I did find one group of servers which is intolerant to the new signature
algorithms in some inexplicable way. (It's not as straight-forward as
avoiding numbers that end in 0-3 or having too many. Hopefully I'll manage
to figure out what's up with them.)

I have not found any servers which are sensitive to 2 vs 3. (That said,
there is a group in my data which is consistent with being intolerant to
large ClientHellos. But every one I've looked at so far was a transient
network error in probing. I'll need to re-run a few of these hosts to get
better data.)

But the one thing that is extremely clear is the problem is
ClientHello.version. This should not be surprising. We've done this three
times already, and it's always been ClientHello.version. There may be the
occasional satellite problem beyond it, but we will never be rid of
fallbacks if we continue to try something which reality is desperately
trying to tell us doesn't work.

David

[*] Our implementation doesn't do FFDHE. Although between X25519, P-256,
P-384, and P-521, that's decently large.

---

From: Yuhong Bao <[email-masked]>
Date: Sat, 23 Jul 2016 07:10:27 +0000

I was the one who found out about how they "fixed" TLS 1.1 version intolerance in Cisco CSS11503 equipment:

https://bugzilla.mozilla.org/show_bug.cgi?id=1143035

________________________________
From: TLS <[email-masked]> on behalf of David Benjamin <[email-masked]>
Sent: Thursday, July 21, 2016 3:19:34 AM
To: Benjamin Kaduk; Hanno Böck; [email-masked]
Subject: Re: [TLS] Thoughts on Version Intolerance

On Wed, Jul 20, 2016 at 5:43 PM Benjamin Kaduk <[email-masked]<mailto:[email-masked]>> wrote:
On 07/20/2016 05:01 AM, Hanno Böck wrote:
> Hubert Kario <[email-masked]<mailto:[email-masked]>> wrote:
>

[Credit where credit is due, I was not the first to propose the version list. I don't know who was first, but Dave Garrett had proposed the same thing. The TLS 1.3 implementors effectively did so too with the draft version extension. Though I think the fake versions idea is new?]

I should also add that, even if we ever got to our prerequisite quiet point, this scheme is still problematic. If we had a list, all clients could participate in this fuzzing and we have a shot at vaccinating the ecosystem. This one violates the specification, so only clients which can rapidly deploy changes can safely do it. (Some sort of field trial mechanism, for instance.) And it requires manual work to sustain: I would probably only do it for, say, 3 months at a time and manually extend so long as TLS 1.4 does not exist. I would not want to cause problems by forgetting to turn it off.

And as Hubert notes, there may well be other intolerance triggers to clear through. 1.3 has a larger ClientHello. We have also never added a new signature algorithm before. But I think that just means we have more rusted protocol joints fix rather than just the one.

Fortunately, most of our other joints admit this kind of fuzzing. It's just the versioning scheme (fixable with a list), and large ClientHellos. I don't have a good answer to the second one, but I would be very happy if it were our only problem. It's much easier to understand. The version one is surprisingly difficult. The conversations usually go like this:

"Hi, your server software appears to have a bug where you reject TLS 1.2 ClientHellos rather than implementing the version negotiation right."
"Okay, we will deploy TLS 1.2."
"No, please don't fix this with 1.2. That's a different problem."
"You don't want us to add 1.2?"
"No no no. Please do switch to 1.2. I mean... oh, nevermind. I'll just email you later for 1.3."

I am obviously exaggerating for humor, but it's a very common confusion and I think is part of why version intolerance keeps on existing.

If you implement the latest version of TLS but are intolerant to N+1, even if no clients did fallbacks, your bug will not be noticed and you'll thrive in the ecosystem. Then when we go to deploy N+1, we have problems. We want, as much as possible, turn tomorrow's interop failures into today's interop failures so the bugs are caught before software ships.

David

-Ben

_______________________________________________
TLS mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/tls

---

From: Yuhong Bao <[email-masked]>
Date: Sat, 23 Jul 2016 07:16:24 +0000

I should also mention the APC fiasco:

http://www.apc.com/us/en/faqs/FA238115/

UPDATED MARCH-2016: Unable to access my APC Network Management Card (NMC) enabled device via HTTPS (SSL/TLS)<http://www.apc.com/us/en/faqs/FA238115/>
www.apc.com
UPDATED MARCH-2016: Unable to access my APC Network Management Card (NMC) enabled device via HTTPS (SSL/TLS)

I wonder if anyone has tested the TLS 1.2 implementation they did later not only for version intolerance but also for other bugs like GCM nonce reuse.

David

-Ben

---

From: Ivan Ristić <[email-masked]>
Date: Sat, 23 Jul 2016 17:59:35 +0200

> are in the more or less 3% area of 1.3 intolerance.

FYI: I am seeing TLS 1.3 intolerance at 3.2% in the most recent SSL
Pulse scan (July 2016).

I'll propose that a chart is added to the SSL Pulse monthly report so
that we can track the percentage it in the following months.

---

From: Hubert Kario <[email-masked]>
Date: Sat, 23 Jul 2016 17:52:38 -0400 (EDT)

----- Original Message -----
> From: "Brian Smith" <[email-masked]>
> To: "Hubert Kario" <[email-masked]>
> Cc: "Dave Garrett" <[email-masked]>, "<[email-masked]>" <[email-masked]>
> Sent: Saturday, July 23, 2016 3:37:24 AM

oh, I agree, I don't plan to use session_ticket for testing client hello size

> shares are used separately from the case where non-ECC (old-school DH)

what I wanted to say, is that those limits are most likely hardcoded in
the libraries (OpenSSL's certainly were), so they may well be ticking time
bombs for the time when some user deploys such broken implementation with
client certificates and for one reason or other connecting clients have
very big certificates.

Then you can hit those limits even if using TLSv1.2 protocol.
-- 
Regards,
Hubert Kario
Quality Engineer, QE BaseOS Security team
Email: [email-masked]
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic

---

From: Hubert Kario <[email-masked]>
Date: Sat, 23 Jul 2016 18:10:50 -0400 (EDT)

----- Original Message ----- 

> From: "David Benjamin" <[email-masked]>
> To: "Brian Smith" <[email-masked]>, "Hubert Kario" <[email-masked]>
> Cc: "<[email-masked]>" <[email-masked]>
> Sent: Saturday, July 23, 2016 8:03:41 AM

> On Sat, Jul 23, 2016 at 3:37 AM Brian Smith < [email-masked] > wrote:

> > Hubert Kario < [email-masked] > wrote:
> 

> (Note that one must complete the handshake to get a full picture. Sending the
> ClientHello isn't enough. Full analysis pending, but sending a 1.2

technically, it's a regular bug, not intolerance

intolerance is when we can't get Server Hello message

On the other hand we have servers like clkmon.com, which seem to choke on measly
1356 byte long Client Hello messages...
-- 
Regards,
Hubert Kario
Quality Engineer, QE BaseOS Security team
Email: [email-masked]
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic

---

From: Yuhong Bao <[email-masked]>
Date: Sun, 24 Jul 2016 16:50:21 +0000

I don't have access unfortunately, but I wonder which companies on this mailing list are using the affected APC devices.

________________________________
From: Peter Gutmann <[email-masked]>
Sent: Sunday, July 24, 2016 5:01:42 AM
To: Yuhong Bao
Subject: RE: [TLS] Thoughts on Version Intolerance

Do you have access to a device running that software, or are you just passing on the info?  I'd like to run some test messages against it...

Peter.

________________________________
From: TLS [[email-masked]] on behalf of Yuhong Bao [[email-masked]]
Sent: Saturday, 23 July 2016 19:16
To: David Benjamin; Benjamin Kaduk; Hanno Böck; [email-masked]
Subject: Re: [TLS] Thoughts on Version Intolerance

David

-Ben

---

From: Hubert Kario <[email-masked]>
Date: Mon, 25 Jul 2016 13:13:11 +0200

> (I'll try to have more concrete numbers on Monday)

So I extended the scanning script to perform two tests - send a "Very 
Compatible"[1] Client Hello and ones that was extended to be 64KiB long either 
through addition of padding extension or cipher suites[2]. Then the size that 
was accepted by server was found through binary search by stripping the 
additional cipher suites or reducing the size of the padding extension.

Around first 4300 domains were scanned from the Alexa top 1 million this way. 
4388 hosts[3] answered to at least a single connection with an unexpired 
certificate signed by a CA in Mozilla trust program.

Of those, 45 (1.03%) could not be connected to (did not receive a Server 
Hello/.../Server Hello Done reply) with the "Very Compatible" client hello. 
And one caused the scan script to abort.

There were no TLSv1.2 client hello incompatible or TLS extension incompatible 
hosts in the scan.

170 were detected as TLS 1.3 incompatible (3.9%)
183 were detected as TLS 1.4 incompatible (4.2%)
229 were detected as TLS 1.253 incompatible (5.22%)

in the below excerpt (full list below, this is just entries that have at least 
4 servers with same behaviour), "e/<number>" means that it's the smallest size 
of "Very Compatible" client hello extended through the padding extension that 
causes its rejection by server, similarly "c/<number>" indicates smallest size 
rejected by server when the client hello is made big through addition of 
cipher suite IDs

size e/17676                             10        0.2279
size e/17676 c/16408                     4         0.0912
size e/17676 c/16409                     4         0.0912
size e/17520                             251       5.7201
size e/17520 c/16408                     122       2.7803
size e/17520 c/16409                     124       2.8259
size e/17468                             5         0.1139
size e/17468 c/16408                     3         0.0684
size e/17468 c/16409                     2         0.0456
size e/16389                             3328      75.8432
size e/16389 c/16389                     1750      39.8815
size e/16389 c/16390                     1560      35.5515
size e/16385                             339       7.7256
size e/16385 c/16385                     178       4.0565
size e/16385 c/16386                     153       3.4868
size e/16340                             5         0.1139
size e/10245                             41        0.9344
size e/10245 c/10245                     28        0.6381
size e/10245 c/10246                     12        0.2735
size e/4092                              9         0.2051
size e/4092 c/4093                       8         0.1823
size e/2049                              4         0.0912
size e/1356                              10        0.2279
size e/1356 c/1356                       5         0.1139
size e/1356 c/1357                       5         0.1139

size c/16646                             5         0.1139
size c/16408                             142       3.2361
size c/16409                             142       3.2361
size c/16389                             1760      40.1094
size c/16390                             1571      35.8022
size c/16385                             182       4.1477
size c/16386                             155       3.5324
size c/10245                             28        0.6381
size c/10246                             12        0.2735
size c/4093                              8         0.1823
size c/1356                              5         0.1139
size c/1357                              5         0.1139
size c/409                               5         0.1139

Cumulative distribution function for size intolerancies looks like this:

size <c/512                              12        0.2733
size <c/1024                             16        0.3644
size <c/2048                             33        0.7515
size <c/4096                             47        1.0704
size <c/8192                             47        1.0704
size >=c/8192                            4064      92.5529

size <e/512                              0         0
size <e/1024                             0         0
size <e/2048                             11        0.2505
size <e/4096                             32        0.7288
size <e/8192                             34        0.7743
size >=e/8192                            4077      92.849

so while there are about 3-4% of servers which are outright incompatible to 
TLSv1.3 version in Client Hello, there are also around 2% of servers which are 
problematic to connect to (with TLSv1.2 hello) or with a large (up to 4KiB) 
client hello

-- 

 1 - few most common ciphers (ECDHE, ECDSA, DHE, AES, 3DES, RC4, with GCM, 
SHA-256, SHA-1 and MD5 HMACs, empty renegotiation info scsv) and common 
extensions (SNI, supported groups, EC point formats, session ticket, NPN, 
ALPN, status request and signature algorithms) with no non-standard or 
uncommon values
 2 -  ciphersuites were addded from the 0x2000-0xa000 range (excluding 
TLS_FALLBACK_SCSV)
 3 - if different IPs serve the www.example.com and exmple.com domains, both 
were scanned

Full list:

Intolerancies                            Count     Percent
----------------------------------------+---------+-------
Huge Cipher List                         4143      94.4166
Huge Cipher List (trunc c/16388)         2488      56.7001
SSL 3.254                                229       5.2188
TLS 1.0                                  37        0.8432
TLS 1.1                                  8         0.1823
TLS 1.3                                  170       3.8742
TLS 1.4                                  183       4.1705
Very Compatible                          45        1.0255
Xmas tree                                687       15.6563
size c/10245                             28        0.6381
size c/10246                             12        0.2735
size c/10831                             1         0.0228
size c/10953                             1         0.0228
size c/11001                             1         0.0228
size c/1153                              3         0.0684
size c/1154                              1         0.0228
size c/1155                              1         0.0228
size c/11621                             2         0.0456
size c/11634                             1         0.0228
size c/11697                             1         0.0228
size c/11710                             2         0.0456
size c/11728                             1         0.0228
size c/12044                             1         0.0228
size c/12252                             1         0.0228
size c/12289                             1         0.0228
size c/12443                             1         0.0228
size c/12444                             1         0.0228
size c/13464                             1         0.0228
size c/1356                              5         0.1139
size c/1357                              5         0.1139
size c/13839                             1         0.0228
size c/14486                             1         0.0228
size c/14487                             3         0.0684
size c/15488                             1         0.0228
size c/15503                             1         0.0228
size c/15507                             1         0.0228
size c/15675                             1         0.0228
size c/15912                             1         0.0228
size c/15931                             1         0.0228
size c/15993                             1         0.0228
size c/16008                             1         0.0228
size c/16013                             1         0.0228
size c/16015                             1         0.0228
size c/16016                             2         0.0456
size c/16020                             1         0.0228
size c/16040                             3         0.0684
size c/16094                             1         0.0228
size c/16206                             1         0.0228
size c/16209                             1         0.0228
size c/16272                             1         0.0228
size c/16273                             1         0.0228
size c/16289                             1         0.0228
size c/16353                             1         0.0228
size c/16367                             1         0.0228
size c/16369                             2         0.0456
size c/16375                             2         0.0456
size c/16385                             182       4.1477
size c/16386                             155       3.5324
size c/16387                             1         0.0228
size c/16388                             1         0.0228
size c/16389                             1760      40.1094
size c/16390                             1571      35.8022
size c/16404                             1         0.0228
size c/16406                             1         0.0228
size c/16408                             142       3.2361
size c/16409                             142       3.2361
size c/1645                              1         0.0228
size c/16645                             3         0.0684
size c/16646                             5         0.1139
size c/1979                              1         0.0228
size c/20420                             1         0.0228
size c/2049                              2         0.0456
size c/2050                              1         0.0228
size c/24993                             1         0.0228
size c/354                               2         0.0456
size c/407                               1         0.0228
size c/4076                              1         0.0228
size c/4077                              1         0.0228
size c/408                               1         0.0228
size c/409                               5         0.1139
size c/4092                              1         0.0228
size c/4093                              8         0.1823
size c/410                               3         0.0684
size c/555                               1         0.0228
size c/663                               1         0.0228
size c/664                               1         0.0228
size c/666                               1         0.0228
size c/8360                              1         0.0228
size c/8361                              1         0.0228
size c/9853                              1         0.0228
size c/9886                              1         0.0228
size c/9961                              1         0.0228
size c/9963                              1         0.0228
size e/10245                             41        0.9344
size e/10245 c/10245                     28        0.6381
size e/10245 c/10246                     12        0.2735
size e/10245 c/663                       1         0.0228
size e/10953                             1         0.0228
size e/10953 c/10953                     1         0.0228
size e/11001                             1         0.0228
size e/11001 c/11001                     1         0.0228
size e/11404                             1         0.0228
size e/11404 c/16375                     1         0.0228
size e/11621                             1         0.0228
size e/11621 c/11621                     1         0.0228
size e/11634                             1         0.0228
size e/11634 c/11634                     1         0.0228
size e/11696                             1         0.0228
size e/11696 c/11697                     1         0.0228
size e/11709                             2         0.0456
size e/11709 c/11710                     2         0.0456
size e/11728                             1         0.0228
size e/11728 c/11728                     1         0.0228
size e/11763                             1         0.0228
size e/11763 c/9886                      1         0.0228
size e/11828                             1         0.0228
size e/11828 c/1645                      1         0.0228
size e/12232                             1         0.0228
size e/12232 c/12252                     1         0.0228
size e/12288                             1         0.0228
size e/12288 c/12289                     1         0.0228
size e/12318                             1         0.0228
size e/12318 c/15931                     1         0.0228
size e/12441                             1         0.0228
size e/12441 c/16209                     1         0.0228
size e/13378                             1         0.0228
size e/13378 c/16375                     1         0.0228
size e/1356                              10        0.2279
size e/1356 c/1356                       5         0.1139
size e/1356 c/1357                       5         0.1139
size e/13927                             1         0.0228
size e/13927 c/13839                     1         0.0228
size e/14036                             1         0.0228
size e/14036 c/12044                     1         0.0228
size e/14297                             1         0.0228
size e/14297 c/11621                     1         0.0228
size e/14489                             1         0.0228
size e/14489 c/12444                     1         0.0228
size e/14490                             2         0.0456
size e/14490 c/16390                     2         0.0456
size e/14744                             1         0.0228
size e/14744 c/16385                     1         0.0228
size e/15313                             1         0.0228
size e/15313 c/16094                     1         0.0228
size e/15490                             1         0.0228
size e/15490 c/16206                     1         0.0228
size e/15892                             1         0.0228
size e/15892 c/8361                      1         0.0228
size e/15988                             1         0.0228
size e/15988 c/16353                     1         0.0228
size e/16006                             1         0.0228
size e/16006 c/16013                     1         0.0228
size e/16020                             2         0.0456
size e/16020 c/15912                     1         0.0228
size e/16020 c/16390                     1         0.0228
size e/16021                             2         0.0456
size e/16021 c/16389                     1         0.0228
size e/16021 c/16390                     1         0.0228
size e/16022                             1         0.0228
size e/16022 c/16389                     1         0.0228
size e/16040                             3         0.0684
size e/16040 c/16040                     3         0.0684
size e/16171                             1         0.0228
size e/16171 c/16390                     1         0.0228
size e/16271                             1         0.0228
size e/16271 c/16008                     1         0.0228
size e/16275                             3         0.0684
size e/16275 c/15675                     1         0.0228
size e/16275 c/16385                     1         0.0228
size e/16275 c/16390                     1         0.0228
size e/16289                             1         0.0228
size e/16289 c/16289                     1         0.0228
size e/16303                             1         0.0228
size e/16303 c/16386                     1         0.0228
size e/16319                             1         0.0228
size e/16319 c/16389                     1         0.0228
size e/16339                             3         0.0684
size e/16339 c/16273                     1         0.0228
size e/16339 c/16390                     1         0.0228
size e/16339 c/407                       1         0.0228
size e/16340                             5         0.1139
size e/16340 c/16016                     1         0.0228
size e/16340 c/408                       1         0.0228
size e/16340 c/409                       3         0.0684
size e/16341                             3         0.0684
size e/16341 c/410                       3         0.0684
size e/16343                             1         0.0228
size e/16343 c/409                       1         0.0228
size e/16372                             1         0.0228
size e/16372 c/16390                     1         0.0228
size e/16379                             1         0.0228
size e/16379 c/16385                     1         0.0228
size e/16385                             339       7.7256
size e/16385 c/16385                     178       4.0565
size e/16385 c/16386                     153       3.4868
size e/16385 c/16390                     2         0.0456
size e/16385 c/354                       2         0.0456
size e/16385 c/409                       1         0.0228
size e/16385 c/664                       1         0.0228
size e/16385 c/666                       1         0.0228
size e/16385 c/8360                      1         0.0228
size e/16387                             3         0.0684
size e/16387 c/16389                     3         0.0684
size e/16388                             3         0.0684
size e/16388 c/16386                     1         0.0228
size e/16388 c/16388                     1         0.0228
size e/16388 c/16389                     1         0.0228
size e/16389                             3328      75.8432
size e/16389 c/10831                     1         0.0228
size e/16389 c/1154                      1         0.0228
size e/16389 c/12443                     1         0.0228
size e/16389 c/13464                     1         0.0228
size e/16389 c/14486                     1         0.0228
size e/16389 c/14487                     3         0.0684
size e/16389 c/15488                     1         0.0228
size e/16389 c/15503                     1         0.0228
size e/16389 c/15507                     1         0.0228
size e/16389 c/15993                     1         0.0228
size e/16389 c/16015                     1         0.0228
size e/16389 c/16016                     1         0.0228
size e/16389 c/16367                     1         0.0228
size e/16389 c/16369                     2         0.0456
size e/16389 c/16387                     1         0.0228
size e/16389 c/16389                     1750      39.8815
size e/16389 c/16390                     1560      35.5515
size e/16562                             3         0.0684
size e/16562 c/16409                     3         0.0684
size e/16645                             1         0.0228
size e/16645 c/16646                     1         0.0228
size e/16740                             3         0.0684
size e/16740 c/16409                     3         0.0684
size e/17297                             1         0.0228
size e/17297 c/16408                     1         0.0228
size e/17423                             1         0.0228
size e/17423 c/16408                     1         0.0228
size e/17424                             1         0.0228
size e/17424 c/16408                     1         0.0228
size e/17468                             5         0.1139
size e/17468 c/16408                     3         0.0684
size e/17468 c/16409                     2         0.0456
size e/17512                             3         0.0684
size e/17512 c/16408                     3         0.0684
size e/17519                             1         0.0228
size e/17519 c/16408                     1         0.0228
size e/17520                             251       5.7201
size e/17520 c/1153                      2         0.0456
size e/17520 c/1155                      1         0.0228
size e/17520 c/16404                     1         0.0228
size e/17520 c/16406                     1         0.0228
size e/17520 c/16408                     122       2.7803
size e/17520 c/16409                     124       2.8259
size e/17522                             1         0.0228
size e/17522 c/16408                     1         0.0228
size e/17529                             1         0.0228
size e/17529 c/16408                     1         0.0228
size e/17532                             1         0.0228
size e/17532 c/16409                     1         0.0228
size e/17537                             1         0.0228
size e/17537 c/16408                     1         0.0228
size e/17585                             1         0.0228
size e/17585 c/16409                     1         0.0228
size e/17676                             10        0.2279
size e/17676 c/16408                     4         0.0912
size e/17676 c/16409                     4         0.0912
size e/17676 c/4076                      1         0.0228
size e/17676 c/4077                      1         0.0228
size e/17706                             3         0.0684
size e/17706 c/16408                     3         0.0684
size e/17720                             1         0.0228
size e/17720 c/16272                     1         0.0228
size e/18032                             1         0.0228
size e/18032 c/16409                     1         0.0228
size e/18174                             1         0.0228
size e/18174 c/16409                     1         0.0228
size e/18277                             1         0.0228
size e/18277 c/16409                     1         0.0228
size e/2046                              1         0.0228
size e/2046 c/1979                       1         0.0228
size e/2049                              4         0.0912
size e/2049 c/1153                       1         0.0228
size e/2049 c/2049                       2         0.0456
size e/2049 c/2050                       1         0.0228
size e/2053                              1         0.0228
size e/2053 c/555                        1         0.0228
size e/20615                             1         0.0228
size e/20615 c/16409                     1         0.0228
size e/21501                             1         0.0228
size e/21501 c/20420                     1         0.0228
size e/25785                             1         0.0228
size e/25785 c/24993                     1         0.0228
size e/3218                              1         0.0228
size e/3218 c/16646                      1         0.0228
size e/3219                              1         0.0228
size e/3219 c/16646                      1         0.0228
size e/3474                              2         0.0456
size e/3474 c/16645                      2         0.0456
size e/3475                              1         0.0228
size e/3475 c/16645                      1         0.0228
size e/3731                              1         0.0228
size e/3731 c/16646                      1         0.0228
size e/3735                              1         0.0228
size e/3735 c/16646                      1         0.0228
size e/4092                              9         0.2051
size e/4092 c/4092                       1         0.0228
size e/4092 c/4093                       8         0.1823
size e/7866                              1         0.0228
size e/7866 c/16020                      1         0.0228
size e/8155                              1         0.0228
size e/8155 c/16390                      1         0.0228
size e/8362                              1         0.0228
size e/8362 c/16385                      1         0.0228
size e/8364                              1         0.0228
size e/8364 c/16389                      1         0.0228
size e/8365                              1         0.0228
size e/8365 c/16389                      1         0.0228
size e/8366                              1         0.0228
size e/8366 c/16389                      1         0.0228
size e/9853                              1         0.0228
size e/9853 c/9853                       1         0.0228
size e/9960                              1         0.0228
size e/9960 c/9961                       1         0.0228
size e/9963                              1         0.0228
size e/9963 c/9963                       1         0.0228
x:missing information                    1         0.0228
-- 
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com

---

From: Brian Smith <[email-masked]>
Date: Tue, 26 Jul 2016 16:27:32 -1000

> size >=c/8192                            4064      92.5529

This seems like a good indication that clients should limit the number
of cipher suites in the client hello.

> size <e/2048                             11        0.2505

A finer-grained breakdown of sizes between 0-2048 bytes is a better
area to focus on. I personally would try very hard to ensure my
ClientHello fits comfortably in a single packet if at all possible, at
least for a connection to a server that I don't have a session ticket
(or equivalent) for.

> size e/2053 c/555                        1         0.0228

When we consider the most reasonable (initial) ClientHello sizes, it
seems that the ClientHello version number intolerance is a much more
significant problem than size intolerance, if I'm understanding your
numbers correctly.

Cheers,
Brian
-- 
https://briansmith.org/

---

From: Hubert Kario <[email-masked]>
Date: Wed, 27 Jul 2016 12:10:58 +0200

you've missed one more number:

> > Hello/.../Server Hello Done reply) with the "Very Compatible" client hello

so while TLS1.3 intolerance it is a bigger problem, it's a bigger problem by a 
factor of two or three (depending what sizes you consider problematic), not by 
an order of magnitude

And given that the "best"[1] key share for post quantum crypto now is 1824 
bytes in size, going above 2048 byte for client hello's on first connect is 
not unreasonable. That is *if* rlwe with those parameters turns out to be good 
enough and we won't need something even larger.

 1 - https://www.imperialviolet.org/2015/12/24/rlwe.html
-- 
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

---

From: David Benjamin <[email-masked]>
Date: Wed, 27 Jul 2016 12:48:28 +0000

>  1 - https://www.imperialviolet.org/2015/12/24/rlwe.html

While we will indeed someday need to deal with that problem, it is still a
ways out. Even with no intolerance of any kind, I do not expect any
reasonable client to be willing to waste that much bandwidth on a key share
that the vast majority of servers will not use. (HelloRetryRequest exists,
so there is no need to predict all groups.)

Checking numbers from Chrome, the overwhelming majority of today's ECDHE[*]
servers select P-256, though one can expect X25519 to start coming up.
(Google servers select it today, and I believe OpenSSL 1.1.0 is expected to
as well. Probably others too.) With no prior knowledge, those two groups
seem by far the most reasonable to send in an initial ClientHello. For
reference, our in-progress TLS 1.3 implementation in Chrome does this with
a 517-byte ClientHello, of which 186 bytes are the padding to bring it up
to 5 + 512.

With prior knowledge, of course, many things are possible. Perhaps a client
will remember the group a server used last time (or use the
ServerHello.supported_groups extension) and, if we believe the server
prefers an unpredicted group, even if much much larger, predict that one.
With prior knowledge, endpoint intolerance is less of a concern.

I can imagine various unpleasant options should we need to balance
predicting a widely-used large key share with intolerance, but by then any
plans we make now will no longer be valid anyway.

David

[*] Negotiated FFDHE exists in TLS 1.3 and server-fiat DHE in TLS 1.2, but
this irrelevant as those two are totally different animals anyway. All they
have in common is the last three letters.