Subject: [Cfrg] Acceptance call for draft-nir-cfrg-chacha20-poly1305-05.txt

From: Alexey Melnikov <[email-masked]>
Date: Thu, 26 Jun 2014 23:11:43 +0100

Dear RG participants,
CFRG chairs received a request to accept draft-nir-cfrg-chacha20-poly1305-05.txt as a RG document:

 http://datatracker.ietf.org/doc/draft-nir-cfrg-chacha20-poly1305/

The document was discussed on the mailing list and chairs would like to know if there is enough interest to complete this document in CFRG.

The acceptance call starts today and will last for slightly over 2 weeks: please send your comments and statement of support (or not) for this work till the end of July 13th.

Thank you,
Alexey, on behalf of CFRG Chairs.

---

From: "Blumenthal, Uri - 0558 - MITLL" <[email-masked]>
Date: Thu, 26 Jun 2014 22:10:44 +0000

I'm familiar with this work, and support its acceptance/adoption.

TNX!
--
Regards,
Uri Blumenthal Voice: (781) 981-1638
Cyber Systems and Technology Fax: (781) 981-0186
MIT Lincoln Laboratory Cell: (339) 223-5363
244 Wood Street Email: <[email-masked]>
Lexington, MA 02420-9185

Web: http://www.ll.mit.edu/CST/

MIT LL Root CA:

<https://www.ll.mit.edu/labcertificateauthority.html>

DSN: 478-5980 ask Lincoln ext.1638

From: Alexey Melnikov [mailto:[email-masked]]
Sent: Thursday, June 26, 2014 06:11 PM
To: [email-masked] <[email-masked]>
Subject: [Cfrg] Acceptance call for draft-nir-cfrg-chacha20-poly1305-05.txt

Dear RG participants,

Thank you,

---

From: Yoav Nir <[email-masked]>
Date: Fri, 27 Jun 2014 12:49:40 +0300

Not surprisingly, I am in favor of having this draft adopted.

I should point out that this draft is needed as a reference for the IETF to use these algorithms. There is interest in adopting these algorithms for TLS and IPsec, but those efforts need (1) a stable document, and (2) the approval of CFRG that these algorithms are fine.

Yoav

---

From: Ilari Liusvaara <[email-masked]>
Date: Sun, 29 Jun 2014 09:45:58 +0300

On Thu, Jun 26, 2014 at 11:11:43PM +0100, Alexey Melnikov wrote:
> Thank you, Alexey, on behalf of CFRG Chairs.

Support for adoption.

-Ilari

---

From: Watson Ladd <[email-masked]>
Date: Sun, 29 Jun 2014 06:40:55 -0700

I support adoption.

On Thu, Jun 26, 2014 at 3:11 PM, Alexey Melnikov
<[email-masked]> wrote:
> Dear RG participants,
> CFRG chairs received a request to accept
> draft-nir-cfrg-chacha20-poly1305-05.txt as a RG document:
>
> The document was discussed on the mailing list and chairs would like to know
> if there is enough interest to complete this document in CFRG.
>
> The acceptance call starts today and will last for slightly over 2 weeks:
> please send your comments and statement of support (or not) for this work
> till the end of July 13th.
>
> Thank you,
> _______________________________________________
> Cfrg mailing list
> [email-masked]
> http://www.irtf.org/mailman/listinfo/cfrg
>

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

---

From: "Salz, Rich" <[email-masked]>
Date: Sun, 29 Jun 2014 09:43:18 -0400

> The document was discussed on the mailing list and chairs would like
> to know if there is enough interest to complete this document in CFRG.

I support this.  It would be good to have a standards-track definition and move it out of the 'neat hack by a server&browser company' category.

	/r$

--  
Principal Security Engineer
Akamai Technologies, Cambridge, MA
IM: [email-masked]; Twitter: RichSalz

---

From: Alyssa Rowan <[email-masked]>
Date: Sun, 29 Jun 2014 16:32:07 +0100

> The document was discussed on the mailing list and chairs would
> like to know if there is enough interest to complete this document
> in CFRG.

+1 strong support!

I think this is a great AEAD - at least as good as AES-GCM, and easier
to make constant-time; IPR free; faster in software. I think it also
suits hardware/embedded implementations quite well.

For those of you (or me!) maybe reaching this in a search in years to
come: the ChaCha20-Poly1305 AEAD from the CFRG proposed here for
adoption differs from draft-agl-tls-chacha20poly1305-04 originally
proposed by Adam Langley & Wan-Teh Chang (which has now expired, as
it's being replaced with draft-mavrogiannopoulos-chacha-tls-02 which
uses the final AEAD construction being defined here).

Instead of the lengths directly following their ciphertexts:

  draft-agl-tls-chacha20poly1305-04:
  AAD | len_AAD | ciphertext | len_ciphertext

this final version of the AEAD pads the Additional Authenticated Data
(if any) and ciphertext to a 16-byte block boundary (using between
0-15 zero bytes) and moves the lengths to the end:

  draft-nir-cfrg-chacha20-poly1305 (the final AEAD specified here):
  AAD | padding1 | ciphertext | padding2 | len_AAD | len_ciphertext

which is more efficient to implement (block-aligned, and the recipient
knows the lengths are at the end, instead of having to jump backwards
to find len_AAD). Thanks to Niels Moeller for that idea.

It's also different to the AEAD used in [email-masked],
by the way, which uses different Poly1305 padding and tries to encrypt
the length using a second stream cipher instance (but doesn't do
anything else to conceal the length at present).

- -- 
/akr

---

From: "Igoe, Kevin M." <[email-masked]>
Date: Mon, 30 Jun 2014 12:35:26 +0000

Sadly, as with all IRTF research groups, the CFRG is not authorized 
to produce standards track documents. 

> -----Original Message-----
> From: Cfrg [mailto:[email-masked]] On Behalf Of Salz, Rich
> Sent: Sunday, June 29, 2014 9:43 AM
> To: [email-masked]
> Subject: Re: [Cfrg] Acceptance call for draft-nir-cfrg-chacha20-
> poly1305-05.txt
> 
> I support this.  It would be good to have a standards-track definition
> and move it out of the 'neat hack by a server&browser company'
> category.
> 
> 	/r$
> 
> --

---

From: Yoav Nir <[email-masked]>
Date: Mon, 30 Jun 2014 15:50:41 +0300

Not in the normal course of events, but it has happened that after an IRTF group was done with a document, an IETF AD adopted it as if it came from an individual.

But that is not really necessary. An Informational RFC is perfectly fine as a normative reference.

Yoav