Re: [TLS] No cypher overlap

[[e-mail] (Martin Rex)]

Florian Weimer wrote:
> * Viktor Dukhovni:
> 
>> In that case, it should be said that a client MUST NOT advertise
>> TLS 1.3 unless it offers at least one of the TLS 1.3 MTI ciphers
>> (or perhaps less restrictive at least one TLS 1.3 compatible cipher).
> 
> Or the server should negotiate TLS 1.2 instead.
> 
> Servers should already do something similar today: For an
> extension-less TLS 1.2 handshake, they should negotiate TLS 1.1
> instead, to get a stronger PRF.


The facts and reasoning in this short statement is flawed.

The TLSv1.2 PRF uses SHA256 throughout, and the hash of the PRF in TLS
is *NOT* negotiated through extensions, but through TLS cipher suites
(which do not need extensions).

TLSv1.2 has exactly one mandatory to implement ciphersuite:

  https://tools.ietf.org/html/rfc5246#section-9

  TLS_RSA_WITH_AES_128_CBC_SHA

and this cipher suite works perfectly fine without TLS extensions,
and will be used with a SHA-1 PRF for TLSv1.0 & TLSv1.1 and with a
SHA-256 PRF with TLSv1.2.

The highest security level (in the NIST SP800-57 part1 sense) that
you can get with this cipher suite is the equivalent of 128-bit
-- but that requires that you use server certificates with
RSA keys of at least 3072-bit.  The most commonly used server
certificates today use 2048-bit RSA keys and limit the security to
112-bit.

The use of a SHA-1 PRF in TLSv1.0 and TLSv1.1 is perfectly OK with
NIST SP800-57 part1 for 128-bit security.


The "weakness" of extension-less TLSv1.2 affects only the
the weakened digitally-signed transform and the behaviour suggested
in rfc5246 section 7.4.1.4.1 for the absence of the signature_algorithms
extension, and the incredibly behaviour that some implementations
exhibit.


In the history of TLS RFCs there are two examples of completely botched
descriptions of default behaviour for a TLS extension when it is not sent.

The first extreme is in the informational document rfc4492 (TLS cipher
suites with Elliptic Curves), where it says, when the extension is
absent, assume that the peer supports *EVERYTHING*.  The opposite
extreme nonsense is what TLSv1.2 describes for the TLSv1.2 signature
extension when the extension is not sent, because it suggest a 
braindead self-limitation to an algorithm that had already been
deprecated and end-of-lifed with only 2 years left when TLSv1.2
was published, and no such limitation exists in earlier TLS versions.


-Martin