Re: [IPsec] Alissa Cooper's No Objection on draft-ietf-ipsecme-qr-ikev2-10: (with COMMENT)
Hi Alissa, Just adding a couple more responses: >> I think the citation for [NISTPQCFP] should link to the actual call for proposals. We will add a link to the CFP pointing to https://csrc.nist.gov/CSRC/media/Projects/Post-Quantum-Cryptography/document s/call-for-proposals-final-dec-2016.pdf Hopefully the URL will not change as Paul also pointed out. >>future cryptographical results), below is a list of defined IKEv2 and >>IPsec algorithms that should not be used, as they are known to >>provide less than 128 bits of post-quantum security" > I think that it's OK here (because the first SHOULD is normative, while the second is just an advise of what algorithms are not secure from current cryptographers point of view). As authors, we require 256-bit keys (assuming Grover halves key search time which makes it 128-bits of PQ security). Now, NIST has in their FAQs that they consider 128-bits AES (64-bit PQ security level) good enough for a long time because Grover cannot be parallelized. Even though we see the rationale behind this, we feel that using 256-bit keys for this draft (128-bit PQ security) is trivial and without extra cost so that is what implementers should use. But we did not make this a normative "SHOULD" just to avoid conflicting with NIST. We wanted to stay loyal to what we say in the Sec Considerations section "while this RFC doesn't claim to give advice as to what algorithms are secure [...]". Let us know if there are objections. Panos -Original Message- From: IPsec On Behalf Of Valery Smyslov Sent: Monday, January 06, 2020 12:40 PM To: 'Alissa Cooper' ; 'The IESG' Cc: ipsec@ietf.org; ipsecme-cha...@ietf.org; 'David Waltermire' ; draft-ietf-ipsecme-qr-ik...@ietf.org Subject: Re: [IPsec] Alissa Cooper's No Objection on draft-ietf-ipsecme-qr-ikev2-10: (with COMMENT) Hi Alissa, > -- > COMMENT: > -- > > I think this document should formally update RFC 7296. Was that > discussed in the WG? I don't think it is necessary. This document defines an extension to IKEv2, which is negotiated by means of exchange of notifications (a "de facto" standard negotiation mechanism in IKEv2), so it doesn't change anything defined in RFC7296. An application compliant with RFC7296 will remain compliant after this specification is (hopefully) be published as RFC. We have a lot of extensions to IKEv2 defined they didn't update RFC7296. > I think the citation for [NISTPQCFP] should link to the actual call > for proposals. I'll let Panos or Scott comment on it. > Section 6: > > "In addition, the policy SHOULD be set to negotiate only quantum- >resistant symmetric algorithms; while this RFC doesn't claim to give >advice as to what algorithms are secure (as that may change based on >future cryptographical results), below is a list of defined IKEv2 and >IPsec algorithms that should not be used, as they are known to >provide less than 128 bits of post-quantum security" > > This paragraph mixes normative SHOULD with non-normative "should not" > in the > same paragraph. I was wondering if that is intentional. I think that it's OK here (because the first SHOULD is normative, while the second is just an advise of what algorithms are not secure from current cryptographers point of view). Regards, Valery. ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec smime.p7s Description: S/MIME cryptographic signature ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Alissa Cooper's No Objection on draft-ietf-ipsecme-qr-ikev2-10: (with COMMENT)
Hi Alissa, > -- > COMMENT: > -- > > I think this document should formally update RFC 7296. Was that discussed > in the WG? I don't think it is necessary. This document defines an extension to IKEv2, which is negotiated by means of exchange of notifications (a "de facto" standard negotiation mechanism in IKEv2), so it doesn't change anything defined in RFC7296. An application compliant with RFC7296 will remain compliant after this specification is (hopefully) be published as RFC. We have a lot of extensions to IKEv2 defined they didn't update RFC7296. > I think the citation for [NISTPQCFP] should link to the actual call for > proposals. I'll let Panos or Scott comment on it. > Section 6: > > "In addition, the policy SHOULD be set to negotiate only quantum- >resistant symmetric algorithms; while this RFC doesn't claim to give >advice as to what algorithms are secure (as that may change based on >future cryptographical results), below is a list of defined IKEv2 and >IPsec algorithms that should not be used, as they are known to >provide less than 128 bits of post-quantum security" > > This paragraph mixes normative SHOULD with non-normative "should not" > in the > same paragraph. I was wondering if that is intentional. I think that it's OK here (because the first SHOULD is normative, while the second is just an advise of what algorithms are not secure from current cryptographers point of view). Regards, Valery. ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Alissa Cooper's No Objection on draft-ietf-ipsecme-qr-ikev2-10: (with COMMENT)
On Mon, 6 Jan 2020, Alissa Cooper via Datatracker wrote: I think this document should formally update RFC 7296. Was that discussed in the WG? Extensions do not update the core RFC, unless they change behaviour specified in that core RFC. That is, someone implementing the core RFC should know about this extension because they need to change something in their implementation of the core RFC (not this document). I do not think that is the case here. So I do not think it should Update 7296. I think the citation for [NISTPQCFP] should link to the actual call for proposals. Is that a really stable link? I'm sceptical (of most external links) Section 6: "In addition, the policy SHOULD be set to negotiate only quantum- resistant symmetric algorithms; while this RFC doesn't claim to give advice as to what algorithms are secure (as that may change based on future cryptographical results), below is a list of defined IKEv2 and IPsec algorithms that should not be used, as they are known to provide less than 128 bits of post-quantum security" This paragraph mixes normative SHOULD with non-normative "should not" in the same paragraph. I was wondering if that is intentional. I think capitalizing "should not" makes sense. Paul ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
[IPsec] Alissa Cooper's No Objection on draft-ietf-ipsecme-qr-ikev2-10: (with COMMENT)
Alissa Cooper has entered the following ballot position for draft-ietf-ipsecme-qr-ikev2-10: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-ipsecme-qr-ikev2/ -- COMMENT: -- I think this document should formally update RFC 7296. Was that discussed in the WG? I think the citation for [NISTPQCFP] should link to the actual call for proposals. Section 6: "In addition, the policy SHOULD be set to negotiate only quantum- resistant symmetric algorithms; while this RFC doesn't claim to give advice as to what algorithms are secure (as that may change based on future cryptographical results), below is a list of defined IKEv2 and IPsec algorithms that should not be used, as they are known to provide less than 128 bits of post-quantum security" This paragraph mixes normative SHOULD with non-normative "should not" in the same paragraph. I was wondering if that is intentional. ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec