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