Re: [IPsec] WG Last Call for draft-ietf-ipsecme-chacha20-poly1305: starts now, ends May 11
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 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
Re: [IPsec] WG Last Call for draft-ietf-ipsecme-chacha20-poly1305: starts now, ends May 11
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
Re: [IPsec] WG Last Call for draft-ietf-ipsecme-chacha20-poly1305: starts now, ends May 11
Thanks. I’ve fixed this in my working draft of -06, which should be published soon. Yoav On Apr 27, 2015, at 1:05 PM, Doyle, Stephen stephen.do...@intel.com wrote: In the ESP Example in Appendix A, the 'Next Header' field is missing from the ESP Trailer portion of the plaintext. Regards, Steve -- Intel Shannon Limited Registered in Ireland Registered Office: Collinstown Industrial Park, Leixlip, County Kildare Registered Number: 308263 Business address: Dromore House, East Park, Shannon, Co. Clare This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. ___ 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
Re: [IPsec] WG Last Call for draft-ietf-ipsecme-chacha20-poly1305: starts now, ends May 11
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
Re: [IPsec] WG Last Call for draft-ietf-ipsecme-chacha20-poly1305: starts now, ends May 11
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
[IPsec] WG Last Call for draft-ietf-ipsecme-chacha20-poly1305: starts now, ends May 11
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
