[TLS] PR for anti-downgrade mechanism

[Eric Rescorla]

Hi folks,

Please take a look at the following PR which documents a suggestion
made by Karthik Bhargavan about how to prevent protection against
downgrade against downgrade from TLS 1.3 to TLS 1.2 and below.

  https://github.com/tlswg/tls13-spec/pull/284

The idea is that if a TLS 1.3 server receives a TLS 1.2 or below
ClientHello, it sets the top N bits of the ServerRandom to be a
specific fixed value. TLS 1.3 clients which receive a TLS 1.2 or below
ServerHello check for this value and abort if they receive it. This
allows for detection of downgrade attacks over and above the Finished
handshake as long as ephemeral cipher suites are used (because the
signature on the ServerKeyExchange covers the random values). No
protection is provided for static RSA cipher suites, but this still
has some value if you have an attack which only affects (EC)DHE.

I've written this up with 48 bits and a specific fixed value (03 04 03
04 03 04) but that's just a strawman and we can bikeshed on that if
people think this is a good idea.

Thanks,
-Ekr
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] PR for anti-downgrade mechanism

[Karthikeyan Bhargavan]

A few more words on this proposal.

- The goal is to protect TLS 1.3 clients and servers from attacks on TLS 1.* 
ciphersuites.
   E.g. if a new attack on the MD5 | SHA1 concatenation in TLS 1.0 is 
announced, 
   connections between TLS 1.3 clients and servers would still be protected.
   Similarly, if the Apache default 1024-bit DHE group is broken, connections 
between
   TLS 1.3 clients and servers remain unaffected.
   (In the current TLS 1.3 design, an attacker could downgrade the connection 
and break
it in both these cases. No, the fallback SCSV does not help.)

- We propose to fix the first N bits of the server random, but we can carry 
whatever information we want here.
   Protocol version + ciphersuite sounds like a good start to use up 4 bytes.
   (This would, for example, have protected TLS 1.2 against the Logjam attack 
on TLS 1.0.)

- The key idea is that the server random is signed even in older versions of 
TLS, and so
   we will get downgrade protection for free, without modifying these older 
versions in any way.
   (A protocol extension for TLS 1.* would not work, since the extension itself 
could be deleted by the attacker.)

- The first 4 bytes were traditionally used for a timestamp, so using (say) 4 
bytes in a new way 
  does not lose entropy/replay-protection in comparison for servers that 
implement timestamps. 
  However, we do lose some replay-protection when compared to servers that use 
the full 32 bytes. 

- There is a 1/(2^N) chance that valid connections to TLS 1.2 servers will be 
dropped by
   TLS 1.3 clients, because of this proposal. This only happens for servers 
that do not 
   use the unix timestamp (the current timestamp is greater than 0304).
   Still, we need to carefully choose N so that this risk of connection 
dropping is acceptable.

- The proposed mechanism only protects TLS 1.3 clients and servers that 
exclusively support 
   signature-based ciphersuites (DHE/ECDHE) even for older versions of TLS. 
E.g. it does not 
   protect against downgrade to RSA or PSK ciphersuites. 

- We note that RSA ciphersuites already provide a version downgrade mitigation, 
  although it has itself caused many headaches due to bleichenbacher attacks.
  But if a server implements good side-channel resistance to bleichenbacher 
attacks,
  TLS 1.3 can be protected from downgrades to both RSA and (EC)DHE ciphersuites 
in
  older protocol versions.



> On 09 Oct 2015, at 14:23, Eric Rescorla  wrote:
> 
> Hi folks,
> 
> Please take a look at the following PR which documents a suggestion
> made by Karthik Bhargavan about how to prevent protection against
> downgrade against downgrade from TLS 1.3 to TLS 1.2 and below.
> 
>   https://github.com/tlswg/tls13-spec/pull/284 
> 
> 
> The idea is that if a TLS 1.3 server receives a TLS 1.2 or below
> ClientHello, it sets the top N bits of the ServerRandom to be a
> specific fixed value. TLS 1.3 clients which receive a TLS 1.2 or below
> ServerHello check for this value and abort if they receive it. This
> allows for detection of downgrade attacks over and above the Finished
> handshake as long as ephemeral cipher suites are used (because the
> signature on the ServerKeyExchange covers the random values). No
> protection is provided for static RSA cipher suites, but this still
> has some value if you have an attack which only affects (EC)DHE.
> 
> I've written this up with 48 bits and a specific fixed value (03 04 03
> 04 03 04) but that's just a strawman and we can bikeshed on that if
> people think this is a good idea.
> 
> Thanks,
> -Ekr
> 
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] PR for anti-downgrade mechanism

[Yngve N. Pettersen]

On Fri, 09 Oct 2015 12:48:38 -, Karthikeyan Bhargavan  
 wrote:


- We note that RSA ciphersuites already provide a version downgrade  
mitigation,
  although it has itself caused many headaches due to bleichenbacher  
attacks.
  But if a server implements good side-channel resistance to  
bleichenbacher attacks,
  TLS 1.3 can be protected from downgrades to both RSA and (EC)DHE  
ciphersuites in

  older protocol versions.


For reference, the version field in the TLS premaster secret is not  
checked by many servers, IIRC some of them have large market shares.


--
Sincerely,
Yngve N. Pettersen

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] PR for anti-downgrade mechanism

[Karthikeyan Bhargavan]

> For reference, the version field in the TLS premaster secret is not checked 
> by many servers, IIRC some of them have large market shares.

That’s good to know. It would be tempting to recommend that TLS 1.3 servers 
disable RSA (encryption) ciphersuites for all protocol versions, but I guess 
this is not likely to happen for backwards compatibility reasons?

> 
> -- 
> Sincerely,
> Yngve N. Pettersen
> 
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] PR for anti-downgrade mechanism

[Eric Rescorla]

On Fri, Oct 9, 2015 at 3:09 PM, Karthikeyan Bhargavan <
karthik.bharga...@gmail.com> wrote:

>
> > For reference, the version field in the TLS premaster secret is not
> checked by many servers, IIRC some of them have large market shares.
>
> That’s good to know. It would be tempting to recommend that TLS 1.3
> servers disable RSA (encryption) ciphersuites for all protocol versions,
> but I guess this is not likely to happen for backwards compatibility
> reasons?


This seems like RFC 6919 Territory:
https://tools.ietf.org/html/rfc6919#section-1

-Ekr

>
> > --
> > Sincerely,
> > Yngve N. Pettersen
> >
> > ___
> > TLS mailing list
> > TLS@ietf.org
> > https://www.ietf.org/mailman/listinfo/tls
>
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] PR for anti-downgrade mechanism

[Short, Todd]

On Oct 9, 2015, at 8:48 AM, Karthikeyan Bhargavan 
mailto:karthik.bharga...@gmail.com>> wrote:

- There is a 1/(2^N) chance that valid connections to TLS 1.2 servers will be 
dropped by
   TLS 1.3 clients, because of this proposal. This only happens for servers 
that do not
   use the unix timestamp (the current timestamp is greater than 0304).
   Still, we need to carefully choose N so that this risk of connection 
dropping is acceptable.

I’m thinking this chance can be reduced to 0.
Wouldn’t a TLSv1.3 client be able to recognize that it’s connecting to a 
TLSv1.2 server, and not parse the first N bits of the server random?

--
-Todd Short
// tsh...@akamai.com
// "One if by land, two if by sea, three if by the Internet."

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] PR for anti-downgrade mechanism

[Eric Rescorla]

On Fri, Oct 9, 2015 at 3:23 PM, Short, Todd  wrote:

>
>
> On Oct 9, 2015, at 8:48 AM, Karthikeyan Bhargavan <
> karthik.bharga...@gmail.com> wrote:
>
> - There is a 1/(2^N) chance that valid connections to TLS 1.2 servers will
> be dropped by
>TLS 1.3 clients, because of this proposal. This only happens for
> servers that do not
>use the unix timestamp (the current timestamp is greater than 0304).
>Still, we need to carefully choose N so that this risk of connection
> dropping is acceptable.
>
>
> I’m thinking this chance can be reduced to 0.
> Wouldn’t a TLSv1.3 client be able to recognize that it’s connecting to a
> TLSv1.2 server, and not parse the first N bits of the server random?
>

The idea is to distinguish this case from the case where they are
connecting to
an attacker pretending to be a TLS 1.2 server.

-Ekr

--
> -Todd Short
> // tsh...@akamai.com
> // "One if by land, two if by sea, three if by the Internet."
>
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] PR for anti-downgrade mechanism

[Viktor Dukhovni]

On Fri, Oct 09, 2015 at 02:23:30PM +0200, Eric Rescorla wrote:

> Hi folks,
> 
> Please take a look at the following PR which documents a suggestion
> made by Karthik Bhargavan about how to prevent protection against
> downgrade against downgrade from TLS 1.3 to TLS 1.2 and below.
> 
>   https://github.com/tlswg/tls13-spec/pull/284
> 
> The idea is that if a TLS 1.3 server receives a TLS 1.2 or below
> ClientHello, it sets the top N bits of the ServerRandom to be a
> specific fixed value. TLS 1.3 clients which receive a TLS 1.2 or below
> ServerHello check for this value and abort if they receive it. This
> allows for detection of downgrade attacks over and above the Finished
> handshake as long as ephemeral cipher suites are used (because the
> signature on the ServerKeyExchange covers the random values). No
> protection is provided for static RSA cipher suites, but this still
> has some value if you have an attack which only affects (EC)DHE.

I think this is "too clever" (a "hack" not a design) and offers
incomplete protection (does nothing to protect RSA key transport).
So I do not support adoption of this proposal.

If new attacks against TLS 1.0--1.2 emerge that enable MITM via
version downgrade combined with use of weaker algorithms, then
we'll just have to prohibit those weaker algorithms in TLS 1.3
servers (and possibly also clients).

-- 
Viktor.

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] TLS 1.3 - Support for compression to be removed

[Joseph Salowey]

The chairs have read through this thread and do not see any new information
that would cause the working group to reconsider the decision to remove
compression from TLS 1.3.   Discussions about clarifying the language and
intent of the document are OK.

Thanks,

J&S

On Thu, Oct 8, 2015 at 6:42 PM, Eric Rescorla  wrote:

>
>
> On Thu, Oct 8, 2015 at 11:22 PM, Martin Rex  wrote:
>
>> Eric Rescorla wrote:
>> > Short, Todd  wrote:
>> >>
>> >> However, for those ClientHello?s that support older versions, the
>> >> compression_method field may contain other values. This means that if a
>> >> TLSv1.3 client happened to support compression for TLSv1.2, it would be
>> >> unable to negotiate that via a single ClientHello. There?s no way to
>> >> attempt to negotiate TLSv1.2+compression and TLSv1.3+no-compression in
>> a
>> >> single ClientHello.
>>
>> Yup, that is the problem with the current text.
>
>
> Thanks for clarifying this.
>
>
>>
>>
>> >
>> >> In effect, the document is stating that a TLSv1.3 client MUST NOT
>> support
>> >> compression, regardless of the protocol version that may be negotiated.
>> >
>> > Yes, this is what I believe it says and what I believe the WG had
>> consensus
>> > on, the reasoning being that we really wished to just remove the feature
>> > entirely. If the chairs declare consensus on something else, I will of
>> > course edit it to say something else.
>>
>> The current text is trying to force a specific policy in a fashion
>> that is in the worst conceivable violation of rfc2119 section 6 that
>> is possible.
>>
>> A ClientHello with
>>
>> ClientHello.client_version = (3,3)
>> ClientHello.compression_methods = (1,0)
>>
>> will be interoperable with TLSv1.0, TLSv1.1, TLSv1.2 and TLSv1.3 servers.
>>
>>
>> ClientHello.client_version = (3,4)
>> ClientHello.compression_methods = (1,0)
>>
>> will be interoperable with TLSv1.0, TLSv1.1 and TLSv1.2 servers,
>> but TLSv1.3 servers that follow the stupid idea will choke and
>> abort with an "illegal_parameter" alert.
>>
>> Essentially, the current wording is calling for a newly creating what
>> must be called a "compression method intolerance" -- but essentially
>> it is indistinguishable from a "TLS version intolerance"
>
>
> Hmm... I'm not sure I follow this argument. We have a bunch of rules for
> how TLS 1.3 clients MUST behave and TLS 1.3 servers will choke if
> they don't. This doesn't create any present interop problem and only
> creates a problem if in future we wish to reintroduce compression.
> Is that your concern?
>
>
>
>> For a number of years, it seemed to have been consensus in the IETF TLS WG
>> that TLS version intolerance is an implemenattion defect and a real
>> problem.
>> It would be sad if the current TLS WG would confirm that recklessly adding
>> handshake failure causing new intolerances into TLSv1.3 is the new
>> engeneering approach.
>
>
> As I said, I edited the document in conformance with what I believed the
> chair declaration of WG consensus was. If the WG consensus is to remove
> this requirement, then I will of course do so. So, rather than going back
> and
> forth, I would suggest that the best way for you to proceed here is to:
>
> 1. Ask the chairs to re-state the previous consensus. If I misunderstood,
> then that's
> easy.
> 2. If you're still not happy, then you could ask the chairs to re-assess
> the currnet
> consensus.
> 3. If you're still not happy, and you believe this violates 2119, then you
> can of
> course appeal.
>
> This of course also goes for people who think we should re-allow
> compression.
>
> Best,
> -Ekr
>
>
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] TLS 1.3 - Support for compression to be removed

[Martin Rex]

Joseph Salowey wrote:
>
> The chairs have read through this thread and do not see any new information
> that would cause the working group to reconsider the decision to remove
> compression from TLS 1.3.

I am (and I was) perfectly fine with removing compression from TLSv1.3.
(btw. our own implementation never implemented TLS compression).


>
> Discussions about clarifying the language and
> intent of the document are OK.

But in the previous discussion only Todd Short seems to understand, why I am
objecting to one specific requirement in the current plan to achieve
removal of compression from TLSv1.3.

>>>
>>> A ClientHello with
>>>
>>> ClientHello.client_version = (3,3)
>>> ClientHello.compression_methods = (DEFLATE(1),null(0))
>>>
>>> will be interoperable with TLSv1.0, TLSv1.1, TLSv1.2 and TLSv1.3 servers.
>>>
>>>
>>> ClientHello.client_version = (3,4)
>>> ClientHello.compression_methods = (DEFLATE(1),null(0))
>>>
>>> will be interoperable with TLSv1.0, TLSv1.1 and TLSv1.2 servers,

The issue is about the TLSv1.3 server response for the second case above.

If we want to have compression removed from TLSv1.3, then my suggested
wording would be sufficient, and provide proper and robust negotiation
of TLS protocol options:

   All TLS protocol
  versions require the "null" compression method MUST be included/present
  in the compression_methods list of ClientHello.  A TLSv1.3 server that
  is offered and selects/negotiates protocol version TLSv1.3, MUST select
  the "null" compression method, and MUST ignore all other compression
  methods that might appear in the compression_methods list of ClientHello.

The (current) text, which Eric quoted, on the other hand:

For any TLS 1.3
  ClientHello, this field MUST contain only the ?null? compression method
  with the code point of 0. If a TLS 1.3 ClientHello is received with any
  other value in this field, the server MUST generate a fatal
  'illegal_parameter' alert.

would require a TLSv1.3 server to unconditionally abort the TLS handshake
rather than to negotiate the "null" compression and continue the handshake.

The original intent of the ClientHello & ServerHello handshake messages
is negotiation of TLS protocol parameters, and choking&aborting rather
than performing selection&negotiation of the desired protocol options
is what we see in the installed base in form of "TLS version intolerance"
and "TLS extensions intolerance", and what caused browser implementors
to come up with an insecure&dangerous scheme known as "downgrade dance",
which was demonstrated to be a bad idea, because it is what made POODLE
possible in the first place.

The proposed "choke on everything but compression_method = (0)" rather
than "you MUST select the null compression method for TLSv1.3" is
particularly weird due to the statement that follows the current text:


  Note that TLS 1.3 servers may receive TLS 1.2
  or prior ClientHellos which contain other compression methods and MUST
  follow the procedures for the appropriate prior version of TLS.


-Martin

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] PR for anti-downgrade mechanism

[Dave Garrett]

On Friday, October 09, 2015 12:49:02 pm Viktor Dukhovni wrote:
> I think this is "too clever" (a "hack" not a design) and offers

Every fix to an issue in this 20 year old protocol will be a hack.

> incomplete protection (does nothing to protect RSA key transport).

Better than none, for a very low cost.

> So I do not support adoption of this proposal.
> 
> If new attacks against TLS 1.0--1.2 emerge that enable MITM via
> version downgrade combined with use of weaker algorithms, then
> we'll just have to prohibit those weaker algorithms in TLS 1.3
> servers (and possibly also clients).

Those changes are harder to make than they should be, unless we want to do that 
now.


Dave

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] PR for anti-downgrade mechanism

[Eric Rescorla]

It's largely arbitrary, but the reasoning is as follows. There are
apparently
some TLS 1.2 servers which randomly generate the entire server random
(and https://tools.ietf.org/html/draft-mathewson-no-gmtunixtime-00 would
encourage more to do so). The chance of a false positive between such
a server and a TLS 1.3 client is 2^{-32}, which seemed a bit high.

-Ekr


On Fri, Oct 9, 2015 at 10:15 PM, Dave Garrett 
wrote:

> On Friday, October 09, 2015 08:23:30 am Eric Rescorla wrote:
> >   https://github.com/tlswg/tls13-spec/pull/284
> >
> > The idea is that if a TLS 1.3 server receives a TLS 1.2 or below
> > ClientHello, it sets the top N bits of the ServerRandom to be a
> > specific fixed value.
> [...]
> > I've written this up with 48 bits and a specific fixed value (03 04 03
> > 04 03 04) but that's just a strawman and we can bikeshed on that if
> > people think this is a good idea.
>
> I support this, though I would like to know why 6 bytes was chosen instead
> of just 4. I don't object; I would just like to know the reasoning here.
>
>
> Dave
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] PR for anti-downgrade mechanism

[Viktor Dukhovni]

On Fri, Oct 09, 2015 at 10:23:09PM +0200, Eric Rescorla wrote:

> It's largely arbitrary, but the reasoning is as follows. There are
> apparently some TLS 1.2 servers which randomly generate the entire server
> random (and https://tools.ietf.org/html/draft-mathewson-no-gmtunixtime-00 
> would
> encourage more to do so). The chance of a false positive between such
> a server and a TLS 1.3 client is 2^{-32}, which seemed a bit high.

Yes, law of large numbers.  While any one session is unlikely to
fail, the chance of some sessions failing needlessly becomes
appreciable, and some of failures may be have high criticality and
be latency sensitive.  

Of course packet corruption undetected by TCP checksums is perhaps
more likely, and the client should treat this like as data corruption,
rather than a MITM attack, and just reconnect and try again.

The problem is that reconnecting is not something the TLS layer
can do.  And applications might not be instrumented to recover as
quickly or as gracefully as they should.  Plus, not all use of TLS
is over unreliable network transports.  TLS is also used over Unix
domain sockets, where one does not expect either MITM attacks or
data corruption.

So even 2^{-48} is perhaps not quite low enough.  I still think
we're better off fixing serious problems in TLS 1.2 as we find
them regardles of whether the server and client happen to also
support 1.3.

-- 
Viktor.

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] PR for anti-downgrade mechanism

[Dave Garrett]

On Friday, October 09, 2015 04:38:00 pm Viktor Dukhovni wrote:
> So even 2^{-48} is perhaps not quite low enough.

Going to a full 64-bit looks like a good idea to me. The loss of those 4 bytes 
of entropy for old versions isn't likely to matter at all, though, please 
correct me if someone thinks otherwise.

On a related note, I think it might be a good idea to add a note somewhere 
stating that TLS 1.3 now only uses the hello random values indirectly, but 
they're still used via the session hash.

On a tangential note, if anyone sees the need to increase the entropy 
introduced in the hellos, a supplemental random extension sent by both 
endpoints would be trivial to create with the current design. (questioning the 
size of the randoms here is an explicit question in the current TLS WG charter, 
as is the topic of additional downgrade mechanisms)


Dave

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] PR for anti-downgrade mechanism

[Salz, Rich]

> It's largely arbitrary, but the reasoning is as follows.

And so that we can put "TLS1.3" as the six bytes in UTF-8.

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] TLS 1.3 - Support for compression to be removed

[Martin Rex]

Watson Ladd wrote:
> 
> Why is it important that clients be permitted to signal support for
> compression and TLS 1.3 conditionally? Remember, we also want to phase
> out the use of compression in TLS 1.2.

compression in TLS is *NOT* generally bad, and not generally a problem.

It may be a problem for usage scenarios where attacker-supplied content
and unknown content are mixed prior to compression, and in particular
where an attacker is freely given elaborate control over the behaviour
of one of the endpoints (e.g. SSL-VPNs and Web-Browsers), but there
are many more, perfectly valid usage scenarios, where TLS compression
is in current use, such as copying huge sparse files over a
TLS-protected communication channel.

-Martin

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] PR for anti-downgrade mechanism

[Brian Smith]

On Fri, Oct 9, 2015 at 2:23 AM, Eric Rescorla  wrote:

> Please take a look at the following PR which documents a suggestion
> made by Karthik Bhargavan about how to prevent protection against
> downgrade against downgrade from TLS 1.3 to TLS 1.2 and below.
>
>   https://github.com/tlswg/tls13-spec/pull/284
>
> The idea is that if a TLS 1.3 server receives a TLS 1.2 or below
> ClientHello, it sets the top N bits of the ServerRandom to be a
> specific fixed value.
>

1. Why would the server ever receive a TLS 1.2 or below ClientHello from a
client that supports TLS 1.3? Why doesn't the already-standardized
downgrade SCSV mechanism work for those cases?

2. My understanding is that every TLS 1.3 ClientHello contains a
ClientKeyShare extension and that no TLS 1.2 or below ClientHello contains
a ClientKeyShare extension. Therefore, the presence or absence of the
ClientKeyShare extension already signals whether the client is attempting a
TLS 1.3 handshake, or a handshake for a lower TLS version. Thus, also
specifying ClientHello.client_version = 0x0304 is redundant. And, we've
already seen clear evidence that ClientHello.client_version = 0x0304 leads
to severe compatibility issues. So, why not just use
ClientHello.client_version = 0x0303 and rely on the presence of the
ClientKeyShare extension to disambiguate TLS 1.3 vs TLS 1.2 or below?

Cheers,
Brian
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] PR for anti-downgrade mechanism

[Karthikeyan Bhargavan]

> 1. Why would the server ever receive a TLS 1.2 or below ClientHello from a 
> client that supports TLS 1.3? Why doesn't the already-standardized downgrade 
> SCSV mechanism work for those cases?

The attack we’re protecting against is the following:
- a TLS 1.3 client sends a client hello and the MitM changes the version field 
to TLS 1.0 (say) with some weak signature-based ciphersuite (e.g. 
DHE/DHE-EXPORT + AES-CBC)
- for good measure, the MitM also drops any protocol extensions that are 
inconvenient (e.g. FFDHE/extended master secret/…)
- the TLS 1.3 server thinks the client does not support TLS 1.3 and so falls 
back to the requested protocol
- in TLS 1.0, the server signature does not include the version, ciphersuite, 
or extensions, so the client accepts the server flight and computes a master 
secret and finished message

Now, the crucial step is that if the downgraded protocol is so weak that the 
attacker can (with some computational effort) forge the server’s finished 
message, the connection will complete.
There are some instances in which the attacker may be able to achieve this: by 
breaking SHA-1, or a weak DHE group, by redoing some variation of the triple 
handshake attack, or by 
exploiting some software bug in a rarely used low-preference ciphersuite. Note 
that the client did not fallback, the server did, so Fallback SCSV does not 
apply.

The key observation is that downgrade protection in TLS 1.2 (and below) relies 
on the Finished MAC, but the elements that go into computing this MAC (DH 
group, hash algorithm)
are themselves negotiated within the handshake and may be downgraded. This is a 
fundamental protocol limitation that is addressed by TLS 1.3. Now, our goal is 
to protect TLS 1.3 itself
from older protocol versions.

From an academic researcher’s viewpoint, there are two reasons to suggest such 
a countermeasure. 
1) Historically, signalling the ciphersuite in the server signature would have 
prevented high-profile attacks like FREAK, Logjam, and the cross-protocol 
attack between ECDHE/DHE in 2012.
I agree that trying to protect from potential attacks may seem speculative, 
but the idea is to provide some additional protection against future attacks 
even if all TLS clients and servers are not immediately patched.
2) Looking forward, a number of researchers would like to give a strong 
security theorem for TLS 1.3, but at present we would not be able to guarantee 
security for any TLS 1.3 implementation 
that also implements older protocol versions, because we would then also 
have to prove secure all the ciphersuites used in these old versions (some of 
which are certainly broken from the
point of view of provable security). For our proofs, we’d like nothing 
better than to be able to assume that older versions of TLS have been disabled, 
but I guess that is unlikely to happen soon.


It would have been nice not to rely on a “clever” trick, but we could not see 
how else to add any mechanism that could itself not be deleted by an attacker 
in older versions. 
TLS has a long history of signalling downgrades in strange ways.  The RSA PMS 
still includes the protocol version due to an old SSL3->SSL2 downgrade attack. 
The Fallback SCSV is a signal encoded in a bogus ciphersuite, because SSL3 does 
not support extensions. 
These are all unfortunate hacks, made necessary by the limited handshake 
protections in older versions.
The chief benefit is that we can then protect clients and servers that 
implement our brand new protocol version.

Best,
Karthik



> 
> Cheers,
> Brian
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls