Subject: Re: [TLS] No cypher overlap

From: Florian Weimer <[email-masked]>
Date: Sat, 01 Aug 2015 23:16:42 +0200

* Hubert Kario:

> On Tuesday 28 July 2015 16:01:55 Viktor Dukhovni wrote:
>> 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).
>
> MTI does not mean Mandatory To Enable

Are you sure?  That's extremely surprising.

Of course, people are free to run the servers in odd configuration,
but my understanding is that's not TLS anymore.

---

From: Florian Weimer <[email-masked]>
Date: Sat, 01 Aug 2015 23:19:14 +0200

> (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.

---

From: [email-masked] (Martin Rex)
Date: Sun, 2 Aug 2015 16:35:42 +0200 (CEST)

> 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

---

From: Hubert Kario <[email-masked]>
Date: Mon, 03 Aug 2015 13:36:22 +0200

> Are you sure?  That's extremely surprising.

yes, I'm sure:

per https://tools.ietf.org/html/rfc5246#page-65

>9.  Mandatory Cipher Suites
>
>   In the absence of an application profile standard specifying
>   otherwise, a TLS-compliant application MUST implement the cipher
>   suite TLS_RSA_WITH_AES_128_CBC_SHA (see Appendix A.5 for the
>   definition).

-- 
Regards,
Hubert Kario
Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic

---

From: Simon Josefsson <[email-masked]>
Date: Mon, 03 Aug 2015 21:13:09 +0200

>>   suite TLS_RSA_WITH_AES_128_CBC_SHA (see Appendix A.5 for the

I don't read anything about enable in deployments here?  Having code
implementing something does not prevent configuration (and even default
settings) to disable something.

/Simon