On Sat, Jul 23, 2016 at 3:37 AM Brian Smith <br...@briansmith.org> wrote:
> Hubert Kario <hka...@redhat.com> 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.
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
