On Wed, Jun 1, 2016 at 6:57 PM Eric Rescorla <e...@rtfm.com> wrote: > 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. >
To get this thread back on the original point, I put together a PR here for the minimal change which just moves it to the end of server_random. This would be sufficient to fix the problem which prevents today's 1.2 servers from implementing 1.3. https://github.com/tlswg/tls13-spec/pull/508 I don't particular care whether it's moved to the client or not. If you think that's better, I'm happy to change it or defer to a different PR. (I wasn't sure exactly what construction you were thinking for the client_random version.) David > > >> >>> -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
