OK. Make those changes. I’ll post a new version tomorrow. Yoav
> On Apr 27, 2015, at 12:38 PM, Yaron Sheffer <yaronf.i...@gmail.com> 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 > > On 04/27/2015 11:38 AM, Yoav Nir wrote: >> >>> On Apr 27, 2015, at 10:46 AM, Yaron Sheffer <yaronf.i...@gmail.com> wrote: >>> >>> 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? >> >> 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. >> >>> Thanks, >>> Yaron >>> >>> On 04/27/2015 01:44 AM, Paul Hoffman wrote: >>>> 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 >>>> >>> >>> _______________________________________________ >>> IPsec mailing list >>> IPsec@ietf.org >>> https://www.ietf.org/mailman/listinfo/ipsec >> _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
