Subject: [IPsec] I-D Action: draft-ietf-ipsecme-chacha20-poly1305-06.txt

From: [email-masked]
Date: Tue, 28 Apr 2015 00:03:58 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the IP Security Maintenance and Extensions Working Group of the IETF.

        Title           : ChaCha20, Poly1305 and their use in IKE & IPsec
        Author          : Yoav Nir
	Filename        : draft-ietf-ipsecme-chacha20-poly1305-06.txt
	Pages           : 11
	Date            : 2015-04-28

Abstract:
   This document describes the use of the ChaCha20 stream cipher along
   with the Poly1305 authenticator, combined into an AEAD algorithm for
   the Internet Key Exchange protocol (IKEv2) and for IPsec.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-ipsecme-chacha20-poly1305/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-ipsecme-chacha20-poly1305-06

A diff from the previous version is available at:
https:https://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-chacha20-poly1305-06

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Yoav Nir <[email-masked]>
Date: Tue, 28 Apr 2015 10:14:38 +0300

Hi

Changes include:
 - Clarified keying material derivation for IKE
 - Calrified that IV is included in the Encrypted payload
 - Fixed the requirements for padding in the Encrypted payload so as not to require padding bytes.
 - Added a paragraph on the (non-)secrecy of the Salt based on discussion in the TLS mailing list
 - Fixed some errors in the examples (thanks to Steve Doyle and Martin Willi)

Those examples are all synthetic, generated by calling the same ChaCha20 / Poly1305 implementation that I made for creating the examples in the CFRG draft. They were not created with an IKE daemon or a IPsec driver, so they are prone to such errors.

I did *not* include the suggestion by Paul Wouters to tighten up the requirements for generating and parsing padding in the IKEv2 encrypted payload, as this changes the SHOULD in RFC 7296 to a MUST for the sender, and a “MUST accept any” to “MUST NOT accept any except” for the receiver. I don’t want to make such a change without the WG telling me to.

Yoav

> On Apr 28, 2015, at 10:03 AM, [email-masked] wrote:
> 
> 
> _______________________________________________
> IPsec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ipsec

---

From: Michael Richardson <[email-masked]>
Date: Tue, 28 Apr 2015 11:52:19 -0400

> Those examples are all synthetic, generated by calling the same
    > ChaCha20 / Poly1305 implementation that I made for creating the
    > examples in the CFRG draft. They were not created with an IKE daemon or
    > a IPsec driver, so they are prone to such errors.

I read the diffs, and find they all make sense.