Subject: Re: [TLS] Confirming Consensus on supporting only AEAD ciphers

From: Peter Gutmann <[email-masked]>
Date: Tue, 29 Apr 2014 15:55:54 +0000

Fedor Brunner <[email-masked]> writes:

>The Mandatory Cipher Suite for TLS 1.2 was TLS_RSA_WITH_AES_128_CBC_SHA. What
>is the mandatory cipher in TLS 1.3 ? Maybe
>TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 using Curve25519 for ECDHE ?

Ugh, no.  That takes the ciphers from <industry-standard>+<industry-standard>
+<industry-standard> to <oddball-nonstandard>+<oddball-nonstandard>+<oddball-
nonstandard>+<industry-standard>.  Make the defaults something that can be
implemented with a standard crypto library, and leave the oddball stuff as
optional fashion statements.

(No disrespect intended for the algorithms I've designated as "oddball", but I
want something where the default is built from standard, accepted, widely-
recognised algorithms so I don't have to explain to every customer what
ChaCha20 is and why it's being used to protect their banking transactions).

Peter.

---

From: Watson Ladd <[email-masked]>
Date: Tue, 29 Apr 2014 09:26:22 -0700

> ChaCha20 is and why it's being used to protect their banking transactions).

Well, Vanguard uses RC4. That said I think
TLS_ECDHE_RSA_AES_GCM_SHA256 with P256 as ECDHE is implemented widely,
and pretty secure. Yes, there is a performance gain from Curve25519,
but that's not necessary.

Sincerely,
Watson Ladd

>
> Peter.
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls

-- 
"Those who would give up Essential Liberty to purchase a little
Temporary Safety deserve neither  Liberty nor Safety."
-- Benjamin Franklin

---

From: Peter Bowen <[email-masked]>
Date: Tue, 29 Apr 2014 09:27:08 -0700

> optional fashion statements.

TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 with the secp256r1 curve is
probably the best option from the existing registries.  If there is a
desire to avoid EC (and therefore avoid bringing in more extensions,
then TLS_RSA_WITH_AES_128_GCM_SHA256 is the next best choice from the
existing registries.

Thanks,
Peter

---

From: Michael D'Errico <[email-masked]>
Date: Tue, 29 Apr 2014 09:51:58 -0700

>>> What is the mandatory cipher in TLS 1.3 ?

I suggest none.  There are too many to choose from and nobody will
listen anyway.

Or maybe a better answer would be to provide a suggestion for each
of the major key-exchange methods:

     C02B  TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
     C02F  TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
     009E  TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
     00A2  TLS_DHE_DSS_WITH_AES_128_GCM_SHA256
     009C  TLS_RSA_WITH_AES_128_GCM_SHA256

Mike

---

From: Martin Thomson <[email-masked]>
Date: Tue, 29 Apr 2014 10:01:34 -0700

> I suggest none.  There are too many to choose from and nobody will

That's a recipe for interoperability failure.

>     009C  TLS_RSA_WITH_AES_128_GCM_SHA256

I think that we have consensus not to do this particular one.

---

From: Michael D'Errico <[email-masked]>
Date: Tue, 29 Apr 2014 10:33:41 -0700

Martin Thomson wrote:
>> I suggest [not naming a mandatory-to-implement cipher suite in the
>> TLS 1.3 spec.].  There are too many [cipher suites] to choose from
>> and nobody will listen anyway.
> 

I'm suggesting that the TLS 1.3 spec. is not the place for this piece
of information since it is a moving target:

     TLS 1.0 required TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA.
     TLS 1.1 required TLS_RSA_WITH_3DES_EDE_CBC_SHA.
     TLS 1.2 required TLS_RSA_WITH_AES_128_CBC_SHA

Current consensus says none of those previously-mandatory ciphers will
even be compatible with TLS 1.3.

A Best Current Practice document like draft-sheffer-tls-bcp-02 that
tracks best practices is more useful than having the TLS spec. become
obsolete soon after it's published.  BTW that draft suggests these
cipher suites:

     TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
     TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
     TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
     TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384

Mike