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

[David Benjamin <[e-mail]>]

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.)


> -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.)

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
>>
>>
>