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 <[email protected]> On Behalf Of Valery Smyslov Sent: Monday, January 06, 2020 12:40 PM To: 'Alissa Cooper' <[email protected]>; 'The IESG' <[email protected]> Cc: [email protected]; [email protected]; 'David Waltermire' <[email protected]>; [email protected] 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 [email protected] https://www.ietf.org/mailman/listinfo/ipsec
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
