On Wed, Jun 1, 2016 at 3:53 PM, David Benjamin <david...@chromium.org> wrote:
> On Wed, Jun 1, 2016 at 6:43 PM Eric Rescorla <e...@rtfm.com> wrote: > >> 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. >> > > That sounds reasonable to me. I'd probably suggest still putting it at the > end since there's no reason to risk things, but I'm not aware of anything > that uses the client timestamp. (None of the clients I maintain send it.) > Putting it at the end of the client gives the client options, so that would be fine. > >> -Ekr >> >> P.S. The FALLBACK_SCSV isn't a substitute because it isn't signed by the >> server. >> > > Yeah, FALLBACK_SCSV only gives us TLS 1.0-1.2-level downgrade protection > (otherwise the version fallback even loses that one). I only mean in terms > of mitigating the additional damage done by the fallback, not replacing the > entire mechanism. > > (Although, do we actually get the stronger protection if the client > accepts plain RSA key exchange? I've never been very clear on that. > Realistically, clients will be accepting plain RSA for a long while.) > Yes, that's correct. I don't believe we have a good plan for plain RSA. -Ekr > David > > >> >> 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
