Subject: [TLS] TLS 1.2 Long-term Support Profile vs HTTP/2.0

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Fri, 01 Apr 2016 09:54:51 +0200

On Wed, 2016-03-16 at 12:36 +0000, Peter Gutmann wrote:
> After a number of, uh, gentle reminders from people who have been
> waiting for
> this, I've finally got around to posting the TLS-LTS draft I
> mentioned a while
> back.  It's now available as:
> 
> > http://www.ietf.org/id/draft-gutmann-tls-lts-00.txt

I liked the idea of an LTS profile for TLS 1.2, however I just realized
that RFC7540 [0] blacklists (with no rationale) 3 out of the 4 LTS
ciphersuites and I'm wondering how practically useful will be that
profile.

regards,
Nikos

[0]. https://tools.ietf.org/html/rfc7540#appendix-A

---

From: Dave Garrett <[email-masked]>
Date: Fri, 1 Apr 2016 23:17:18 -0400

> [0]. https://tools.ietf.org/html/rfc7540#appendix-A

As no such TLS 1.2 LTS existed at the time of publication (which multiple people, including myself, said would have been better), some kind of sane cipher restrictions were needed to avoid perpetual use of obsolete crypto. The consensus was requiring TLS 1.2+ with only PFS+AEAD cipher suites, however at the last minute implementors started complaining about the requirements and it was reduced to a blacklist of non-compliant cipher suites instead of requiring them to just update their APIs to handle things properly.

Noted at the end of the section:
https://tools.ietf.org/html/rfc7540#page-94

Dave

---

From: Peter Gutmann <[email-masked]>
Date: Sun, 3 Apr 2016 08:18:20 +0000

Nikos Mavrogiannopoulos <[email-masked]> writes:

>I liked the idea of an LTS profile for TLS 1.2, however I just realized that
>RFC7540 [0] blacklists (with no rationale) 3 out of the 4 LTS ciphersuites
>and I'm wondering how practically useful will be that profile.

I chose the two sets of algorithms that were secure and had the most
widespread acceptance/support/popularity/whatever, in other words the ones
where there was the biggest chance of developers being able to say "yeah, we
do that already".

>[0]. https://tools.ietf.org/html/rfc7540#appendix-A

I think the reason why there's no rationale is because there's no rational
explanation for lumping TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 in with the likes
of TLS_RSA_EXPORT_WITH_RC4_40_MD5.

Peter.

---

From: Martin Thomson <[email-masked]>
Date: Sun, 3 Apr 2016 21:44:53 +1000

> of TLS_RSA_EXPORT_WITH_RC4_40_MD5.

You evidently believe that a decision to move to AEAD only is
irrational.  Others, myself included, do not.

---

From: Yoav Nir <[email-masked]>
Date: Sun, 3 Apr 2016 10:27:59 -0300

> On 3 Apr 2016, at 8:44 AM, Martin Thomson <[email-masked]> wrote:
> 

Agree. TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 is fine if you also implement the EtM extension that nobody did. OTOH everybody implemented AES-GCM, so that’s better in the “yeah, we do that already” criterion. And as Dave McGrew’s draft showed us, you can fit CBC + HMAC into an AEAD in case you really, really like CBC and HMAC.

Yoav