2% is actually pretty good, but I agree that we're going to need fallback. I'd be fine with moving the 8 bytes to the end, but I wonder if it would be better to instead have the *client* indicate its max version and the server check. That would have the advantage that it would leave more of the server random intact.
-Ekr P.S. The FALLBACK_SCSV isn't a substitute because it isn't signed by the server. On Wed, Jun 1, 2016 at 3:29 PM, David Benjamin <david...@chromium.org> wrote: > 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 > >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
