Re: [TLS] Downgrade protection, fallbacks, and server time

[Eric Rescorla <[e-mail]>]

On Wed, Jun 1, 2016 at 3:53 PM, David Benjamin <[e-mail]>
wrote:

> On Wed, Jun 1, 2016 at 6:43 PM Eric Rescorla <[e-mail]> 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 <[e-mail]>
>> 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
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/tls
>>>
>>>
>>