In case folks hoped we could bump the ClientHello version without those dreaded browser fallbacks, I have bad news. :-( 1.3 intolerance very much exists. (Maybe we should just give up on ClientHello.version and use an extension? Extensions have rusted less.)
I picked a large list of top sites and tried connecting to them. Just under 2% of them could handle a TLS 1.2 ClientHello, but not the same ClientHello with the version switched to 1.3 (no other changes, so I haven't tested a real 1.3 ClientHello). They're not unknown hosts either. I expect if you probe any top site list, you'll very quickly find some. Fortunately, the ServerHello.random trick fixes this. But it currently clobbers the old server timestamp which tlsdate[1] uses for clock synchronization. There really should be a less silly secure timestamping protocol, but, today, tlsdate has users. Any servers which expect to be a tlsdate target can't honor this MUST without tlsdate gone. (FALLBACK_SCSV works fine as well, but I gather people prefer the ServerHello.random one and would be unhappy having to implement both in clients with a fallback because not all servers do the latter.) I mentioned this before, but rather than clobbering the first 8 bytes, the last 8 bytes seems as reasonable and avoids this unnecessary complication to TLS 1.3 deployment. If folks agree now that the fallback's resurrection is more certain, I'm happy to put together a PR. David [1] https://github.com/ioerror/tlsdate
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
