Subject: [IPsec] Alissa Cooper's No Objection on draft-ietf-ipsecme-qr-ikev2-10: (with COMMENT)

From: Alissa Cooper via Datatracker <[email-masked]>
Date: Mon, 06 Jan 2020 09:24:46 -0800

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.

---

From: Paul Wouters <[email-masked]>
Date: Mon, 6 Jan 2020 12:37:13 -0500 (EST)

> I think this document should formally update RFC 7296. Was that discussed in

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

Is that a really stable link? I'm sceptical (of most external links)

> same paragraph. I was wondering if that is intentional.

I think capitalizing "should not" makes sense.

Paul

---

From: Valery Smyslov <[email-masked]>
Date: Mon, 6 Jan 2020 20:40:29 +0300

Hi Alissa,

> 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

I'll let Panos or Scott comment on it.

> 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.

---

From: "Panos Kampanakis (pkampana)" <[email-masked]>
Date: Mon, 6 Jan 2020 18:12:06 +0000

Hi Alissa, 

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. 

> 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-masked]> On Behalf Of Valery Smyslov
Sent: Monday, January 06, 2020 12:40 PM
To: 'Alissa Cooper' <[email-masked]>; 'The IESG' <[email-masked]>
Cc: [email-masked]; [email-masked]; 'David Waltermire'
<[email-masked]>; [email-masked]
Subject: Re: [IPsec] Alissa Cooper's No Objection on
draft-ietf-ipsecme-qr-ikev2-10: (with COMMENT)

Hi Alissa,

> 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.

> 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-masked]
https://www.ietf.org/mailman/listinfo/ipsec