Re: [TLS] PR for anti-downgrade mechanism

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 0304xxxx).
   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 <ekr@rtfm.com> 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 <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