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