Re: [TLS] PR for anti-downgrade mechanism

On Sat, Oct 17, 2015 at 12:00 PM, Viktor Dukhovni <ietf-dane@dukhovni.org>
wrote:

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

Hopefully, yes.

If so, is it necessary to have a variable high octet?

Note: I am proposing this in the low octet. Not that it's that
important either way.

> Just a single
> fixed patter signalling ">= 1.3" would then suffice.
>

If you wanted to cover 1.2 -> 1.1, then you would want this.

-Ekr

> 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.
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>