Re: [TLS] PR for anti-downgrade mechanism

[Viktor Dukhovni <[e-mail]>]

On Sat, Oct 17, 2015 at 11:35:35AM -0700, Eric Rescorla wrote:

> Trying to close the loop on this, I think people are generally in favor of
> this
> mechanism, so we just need a concrete construction.
> 
> I propose we use an N bit field divided as follows
> 
> - N - 8 bits of fixed sentinel.
> - 8 bits of version number with the semantics being the highest TLS version
>   number supported by the server, encoded with the high nibble being
>   the major version and the low version being the minor version. So,
>   concretely a TLS 1.3 implementation would use 0x34 here.
> 
> I imagine people have opinions about N and the sentinel, but for
> concreteness
> I suggest that N = 64 bits, and that we use the ASCII string
> 'DOWNGRD' as the sentinel.
> 
> Let the bikeshedding begin!

IIRC for TLS >= 1.3 the entire server hello (as part of a session
transcript digest that includes it) is signed with the key exchange.
So TLS 1.3 already protects against rollbacks from 1.4 to 1.3.

If so, is it necessary to have a variable high octet?  Just a single
fixed patter signalling ">= 1.3" would then suffice.

I must admit to not have looked closely, so perhaps wrong end of
the stick...  If the above is however correct, I think simpler is
better, over-engineering this work-around "side-channel" is I think
unwise.  This seems to be a protection against rollback to TLS <
1.3, for TLS >= 1.3, the protocol should solve any issues more
naturally than by overloading the server-random.

-- 
	Viktor.