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