Subject: [IPsec] WG Last Call for draft-ietf-ipsecme-chacha20-poly1305: starts now, ends May 11

From: Paul Hoffman <[email-masked]>
Date: Sun, 26 Apr 2015 15:44:17 -0700

Greetings again. This begins the two-week WG Last Call on draft-ietf-ipsecme-chacha20-poly1305, which ends Monday May 11. We would love to hear from people in either of two groups:

- Those who have already reviewed an earlier version of this draft. Please re-read the draft now, and let us know if it is perfect, or if there anything else you want added or changed. This includes Yaron, PaulW, Tero, ScottF, and Valery.

- Those who have *not* yet reviewed this draft, but want to help the IETF create good standards in this area. If you are an IPsec implementer, or know one at your organization, reviewing this draft and sending any comments to the list (even just "seems fine" or "I liked it except this one thing") is useful to all of us.

It seems very likely that this new algorithm combination will appear in IKEv2 and ESP soon, and having folks give a bit more review will help prevent whoopsies in the future.

--Paul Hoffman

---

From: Yaron Sheffer <[email-masked]>
Date: Mon, 27 Apr 2015 10:46:21 +0300

I am still a bit confused about Sec. 3 (use in IKEv2):

- Where does it say (in this draft or in Sec. 2.7 of the CFRG draft) 
that the IV is included explicitly, and where exactly it should go?

- In the bullet that describes the IV, I would add text that the IKE 
Message ID is not an option, and why.

- How do we make sure that the key/IV combination is unique between 
Initiator and Responder?

Thanks,
	Yaron

---

From: Yoav Nir <[email-masked]>
Date: Mon, 27 Apr 2015 11:38:35 +0300

> On Apr 27, 2015, at 10:46 AM, Yaron Sheffer <[email-masked]> wrote:
> 
> - Where does it say (in this draft or in Sec. 2.7 of the CFRG draft) that the IV is included explicitly, and where exactly it should go?

It says that the IV is 64-bit, same as in section 2, and RFC 7296 section 3.14 says that the IV is explicit. Although in honesty, it also says that the size of the IV is equal to block length, which would make it 512 bits here?  Anyway, RFC 7296 does say that this is true only for CBC.

> - In the bullet that describes the IV, I would add text that the IKE Message ID is not an option, and why.

The whole idea of using sequence number as IV is now gone from the draft. If we want to add some path-not-taken text, it should probably go in the Security Considerations or maybe another appendix. I don’t really think it is relevant.

> - How do we make sure that the key/IV combination is unique between Initiator and Responder?

PRF+ generates a bitstring with separate SK_ei and SK_er for the initiator and responder respectively. Each is 36 octets (288 bits). While we don’t explicitly prevent PRF+ from generating the same 36 bytes twice, good PRFs hardly ever will. The same is not true for IKEv1 (RFC 2409) where the same SKEYID_e is used by both.

> _______________________________________________
> IPsec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ipsec

---

From: Yaron Sheffer <[email-masked]>
Date: Mon, 27 Apr 2015 12:38:32 +0300

Clearly we need to mention that the IV is included, despite the text of 
RFC 7296.

You are right about SK_ei/er. The second bullet in Sec. 3 should not 
mention KEYMAT, which is unrelated, and maybe should mention SK_ei/er.

Thanks,
	Yaron

---

From: Yoav Nir <[email-masked]>
Date: Tue, 28 Apr 2015 01:00:20 +0300

OK. Make those changes. I’ll post a new version tomorrow.

Yoav

> On Apr 27, 2015, at 12:38 PM, Yaron Sheffer <[email-masked]> wrote:
> 
> Clearly we need to mention that the IV is included, despite the text of RFC 7296.
> 
> You are right about SK_ei/er. The second bullet in Sec. 3 should not mention KEYMAT, which is unrelated, and maybe should mention SK_ei/er.
> 
> Thanks,
> 	Yaron
>