Subject: [TLS] Status of Cha-Cha/Poly Cipher Suites?

From: Jeffrey Walton <[email-masked]>
Date: Sat, 16 May 2015 17:24:35 -0400

What is the status of cipher suite values for the CHA-CHA/Poly Cipher suites?

The Chrome browser is now warning when either AES/GCM or CHA-CHA/Poly
Cipher suites are not used.

Lack of the cipher suite values is holding up OpenSSL's implementation. [1]

If the IETF considers Chrome (26% market share [2]) and Apache/OpenSSL
based servers (52% market share [3]), then it appears, then the cipher
suite values are long overdue.

Assigning the cipher suite values (whether the TLS WG approves of them
or not) appear to be consistent with RFC 3935:

   In attempting to resolve the question of the IETF's scope, perhaps
   the fairest balance is struck by this formulation: "protocols and
   practices for which secure and scalable implementations are expected
   to have wide deployment and interoperation on the Internet, or to
   form part of the infrastructure of the Internet."

The cipher suites already affects millions to billions of users and devices.

[1] https://mta.openssl.org/pipermail/openssl-users/2015-March/000866.html
[2] https://www.netmarketshare.com/browser-market-share.aspx?qprid=0&qpcustomd=0
[3] http://news.netcraft.com/archives/2014/04/02/april-2014-web-server-survey.html

---

From: Yoav Nir <[email-masked]>
Date: Sun, 17 May 2015 01:02:23 +0300

Hi, Jeffrey

The algorithm document has just been published: https

What remains for the TLS working group to do is to adopt a draft for ChaCha20-Poly1305 in TLS. There already is a candidate:
https://tools.ietf.org/html/draft-mavrogiannopoulos-chacha-tls-05

Once that’s done, the document can both progress and if needed, people can request early assignment of identifiers. The ciphersuite registry has a “specification required” policy. Strictly speaking, the private draft could be enough - we don’t have to have an RFC, but practically speaking, this document will only get assignment after it is adopted by the WG.

This is a similar procedure to that followed by the IPsecME working group, which has just finished WGLC on the IPsec version of this draft.

Yoav

> On May 17, 2015, at 12:24 AM, Jeffrey Walton <[email-masked]> wrote:
> 
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls

---

From: Dave Garrett <[email-masked]>
Date: Sat, 16 May 2015 18:07:40 -0400

> The algorithm document has just been published: https

https://tools.ietf.org/html/rfc7539

---

From: Yoav Nir <[email-masked]>
Date: Sun, 17 May 2015 01:25:54 +0300

Thanks.

> On May 17, 2015, at 1:07 AM, Dave Garrett <[email-masked]> wrote:
>

---

From: Ilari Liusvaara <[email-masked]>
Date: Sun, 17 May 2015 08:42:13 +0300

On Sun, May 17, 2015 at 01:02:23AM +0300, Yoav Nir wrote:
> What remains for the TLS working group to do is to adopt a draft for
> ChaCha20-Poly1305 in TLS. There already is a candidate:

The only comment I have regarding that draft is that it doesn't specify
what to stick to record payload. Ciphertext (|P| bytes) || Tag (16 bytes),
right?

> Once that’s done, the document can both progress and if needed, people
> can request early assignment of identifiers. The ciphersuite registry
> has a “specification required” policy. Strictly speaking, the private
> draft could be enough - we don’t have to have an RFC, but practically
> speaking, this document will only get assignment after it is adopted
> by the WG.

As note, GnuTLS 3.4.x implements (disabled by default) the abovementioned
draft, using CSID CCA0-CCA7 (which are noted in the draft).

> > suite values are long overdue.

Also, due to widespread use, the Chrome Chacha CSID CC13-CC15 could be marked
as "reserved" (or even given names), preferably with note pointing to
draft-agl-tls-chacha20poly1305-04 (there is perecedent for marking CSID as
reserved due to existing use). Those are not interoperable with the ones
in GnuTLS.

-Ilari

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Mon, 18 May 2015 10:19:44 +0200

> what to stick to record payload. Ciphertext (|P| bytes) || Tag (16 bytes),

Hi,
 I believed that the output format was explicit in rfc7539, but I was
wrong. I've clarified that point and hopefully that will be included in
the next draft update.

> draft, using CSID CCA0-CCA7 (which are noted in the draft).

Indeed, we've added new code points to allow interoperability testing.

regards,
Nikos

---

From: Yoav Nir <[email-masked]>
Date: Mon, 18 May 2015 13:36:52 +0300

> On May 18, 2015, at 11:19 AM, Nikos Mavrogiannopoulos <[email-masked]> wrote:
> 

So what’s stopping the chairs from polling the group for adoption?

Chairs?

Yoav

---

From: Sean Turner <[email-masked]>
Date: Mon, 18 May 2015 10:29:26 -0400

> So what’s stopping the chairs from polling the group for adoption?

Let’s just say it’s coming in the not to distant future.

spt

---

From: Watson Ladd <[email-masked]>
Date: Mon, 18 May 2015 09:52:55 -0700

> Let’s just say it’s coming in the not to distant future.

To quote John von Neumann: "If you say why not tomorrow, I say why not
today? If you say today at 5 o'clock, I say why not one o'clock?"

-- 
"Man is born free, but everywhere he is in chains".
--Rousseau.