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

[Panos Kampanakis (pkampana)]

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)

[Valery Smyslov]

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)

[Paul Wouters]

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

Re: [IPsec] [Gen-art] Genart last call review of draft-ietf-ipsecme-qr-ikev2-09

[Alissa Cooper]

Christer, thanks for your review. Valery, thanks for your responses. I entered 
a No Objection ballot.

Alissa


> On Dec 13, 2019, at 3:17 PM, Christer Holmberg via Datatracker 
>  wrote:
> 
> Reviewer: Christer Holmberg
> Review result: Almost Ready
> 
> I am the assigned Gen-ART reviewer for this draft. The General Area
> Review Team (Gen-ART) reviews all IETF documents being processed
> by the IESG for the IETF Chair.  Please treat these comments just
> like any other last call comments.
> 
> For more information, please see the FAQ at
> 
> .
> 
> Document: draft-ietf-ipsecme-qr-ikev2-09
> Reviewer: Christer Holmberg
> Review Date: 2019-12-13
> IETF LC End Date: 2019-12-25
> IESG Telechat date: Not scheduled for a telechat
> 
> Summary: The document is well-written, and almost ready for publication.
> However, I have a couple of minor comments that I would like the authors to
> address.
> 
> Major issues: None
> 
> Minor issues:
> 
> Q1:
> 
> The Security Considerations lists IKEv2/IPSec algorithms that are not
> considered quantum-resistant. However, that is not mentioned anywhere else. I
> think it would be good to mention that in the Abstract and/or Introduction.
> 
> Q2:
> 
> Section 3 says:
> 
>   "If the responder does not support this specification or does not have
>   any PPK configured, then it ignores the received notification and
>   continues with the IKEv2 protocol as normal."
> 
> I assume the ignoring of a non-supported notification and continuing with
> normal IKEv2 is part of the IKEv2 specification. If so, I suggest to say add
> something like:
> 
> ", as described in RFC."
> 
> Nits/editorial comments:
> 
> Q3:
> 
> The Security Considerations talk about the Grover's algorithm. Please add a
> reference.
> 
> 
> ___
> Gen-art mailing list
> gen-...@ietf.org
> https://www.ietf.org/mailman/listinfo/gen-art

___
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 via Datatracker]

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