Re: [TLS] PR for anti-downgrade mechanism

[Karthikeyan Bhargavan <[e-mail]>]

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] <mailto:[e-mail]>> wrote:
> On 16 October 2015 at 13:39, Brian Smith <[e-mail] <mailto:[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/ <https://briansmith.org/>
>