Re: [TLS] PR for anti-downgrade mechanism

[Eric Rescorla <[e-mail]>]

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!

-Ekr










On Fri, Oct 16, 2015 at 11:23 PM, Karthikeyan Bhargavan <
[e-mail]> wrote:

> Hi Brian, yes, the mechanism proposed here could also be used by TLS 1.2
> implementations to signal each other about their preferred connection
> parameters.
>
> To make most use of the bytes provided, one could use the sentinel value
> to indicate
> support for an extension, which then carries a signed server configuration
> of arbitrary size.
> The attacker would then be unable to downgrade the connection by deleting
> this extension.
>
> False Start is an interesting use case, because
> (a) it sends data before the server has confirmed the chosen
> version/ciphersuite/etc and
> (b) it already tries to prevent downgrades by whitelisting versions and
> ciphersuites.
> Some downgrade attacks fail because of (b), but others are easier to
> exploit because of (a).
> For example, Logjam was easier to mount on False Start clients since the
> attacker could
> collect the False Start data and decrypt it at leisure.
>
> Extended master secret (EMS) provides some additional protection to False
> Start, because the encryption
> keys implicitly include the full handshake transcript and, so if the MitM
> tampers with the connection,
> the False Start data would not be accepted by a server. (However, that
> this would not have prevented Logjam.)
> Moreover, even the EMS extension can be deleted by a MitM.
> The current proposal could protect EMS from downgrade by indicating
> support for it in the server hello.
>
> To sum up, we’re focusing on TLS 1.3 because we have a chance to bake in
> strong downgrade protection
> into its implementations from the very beginning. I think this could be
> useful for older versions too, as an optional
> mechanism which protects clients and servers that both implement it, and
> does not affect others.
>
> -Karthik
>
> On 17 Oct 2015, at 00:34, Brian Smith <[e-mail]> wrote:
>
> On Fri, Oct 16, 2015 at 12:12 PM, Martin Thomson <[e-mail]
> > wrote:
>
>> On 16 October 2015 at 13:39, Brian Smith <[e-mail]> wrote:
>> > That would be especially true for an implementation that does False
>> Start
>> > for TLS 1.2.
>>
>> I don't see how false start plays into this.  We could have clients
>> reject false start if they see this sentinel value.  But don't we want
>> to just treat this as an attack and abort instead?
>>
>
> Yes. The client needs the sentinel to know to abort the connection, if its
> willing to false start with TLS 1.2 when it also support TLS 1.3, right?
>
> Cheers,
> Brian
> --
> https://briansmith.org/
>
>
>
> _______________________________________________
> TLS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls
>
>