Re: [TLS] Thoughts on Version Intolerance

[David Benjamin <[e-mail]>]

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

> Hubert Kario <[e-mail]> wrote:
> > 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.
>
> 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.


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.