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

From: Roman Danyliw via Datatracker <[email-masked]>
Date: Wed, 08 Jan 2020 05:22:01 -0800

Roman Danyliw 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:
----------------------------------------------------------------------

These are all editorial.

** Section 1.  Per “Recent achievements in developing quantum computers …”, is
there a citation?

** Section 1. Per:
   If the preshared key has
   sufficient entropy and the PRF, encryption and authentication
   transforms are quantum-secure, then the resulting system is believed
   to be quantum resistant, that is, invulnerable to an attacker with a
   quantum computer.

-- The definition of quantum resistant doesn’t seem exactly precise.  A
quantum-resistant algorithm isn’t “invulnerable to an attacker with a quantum
computer”, rather isn’t it instead no easier to attack than with known
classical architectures?

-- The first clause says the underlying primitives are quantum-secure, but then
says that this translated into something being quantum-resistant.  I found it
confusing to mix both terms (which sometimes are used interchangeably)

** Section 1.  Per “This document describes a way to extend IKEv2 to have a
similar property; assuming that the two end systems share a long secret key
then the resulting exchange is quantum resistant.”, I stumbled over this
language a bit because I wasn’t sure which property you were referencing – was
it the list of things in the previous paragraph’s last sentence that made it
“quantum-secure”?

** Section 3. Per the description of modified IKEv2 key derivation:

-- Recommend explicitly citing the relevant section:
OLD:
Then, it computes this modification of the standard IKEv2 key derivation:

NEW:
Then, it computes this modification of the standard IKEv2 key derivation from
Section 2.14 of [RFC7296]:

-- Recommend explaining the notation/relationship between the “prime versions”
of the sub-keys (i.e., SK_d’ and SK_pi’ and SK_pr’) in the this SKEYSEED
formula with the SKEYSEED formula in Section 2.14 of [RFC72196].

** Editorial Nits:

-- Section 1.  Editorial. s/this note/this document/ -- trying to be consistent
on how the I-D references itself.

-- Section 4.  Editorial.  Recommended clarity:

OLD:
This will not affect the strength against a
   passive attacker; it would mean that an attacker with a quantum
   computer (which is sufficiently fast to be able to break the (EC)DH
   in real time) would not be able to perform a downgrade attack.

NEW:
This will not alter the resistance to a passive attack as even an attacker with
a quantum computer (which is sufficiently fast to be able to break the (EC)DH
in real time) would not be able to perform a downgrade attack.

-- Section 5.2.3.  Typo. s/Addtionally/Additionally/

-- Section 6.  Typo. s/transmited/transmitted/

---

From: "Valery Smyslov" <[email-masked]>
Date: Wed, 8 Jan 2020 17:41:59 +0300

Hi Roman,

> https://datatracker.ietf.org/doc/draft-ietf-ipsecme-qr-ikev2/

Do you mean a citation about achievements? I'm not sure it's easy to find a stable
reference here, but probably Scott or David or Panos have a good one...

> computer”, rather isn’t it instead no easier to attack than with known

My understanding is that it's infeasible to break such a system even 
with a help of quantum computer. 
Grover's algorithm still gives an attacker equipped with QC
an advantage comparing with classical architectures, but 
proper selection of algorithms and key lengths doesn't 
allow him to break the system.

It was discussed a bit during AD's review of the draft:
https://mailarchive.ietf.org/arch/msg/ipsec/8AEgzGjqsDMTUy1X0IB4JWv_zlE

And probably my co-authors will give more authoritative answer here.

> confusing to mix both terms (which sometimes are used interchangeably)

To be frank I don't feel difference here, but again I rely on my co-authors here.

> it the list of things in the previous paragraph’s last sentence that made it

I believe it is a property of being "quantum-secure" (or "quantum resistant").

If we change all instances of "quantum resistant" with "quantum-secure"
in the Section 1, will the text be more clear?

> Section 2.14 of [RFC7296]:

OK.

> formula with the SKEYSEED formula in Section 2.14 of [RFC72196].

I'm not sure I fully understand what you mean.
I think we provide formulas of how prime and non-prime versions
are correlated (i.e. how non-prime versions are computed from prime versions).
Am I missing something?

> on how the I-D references itself.

OK, already noted by Barry.

> in real time) would not be able to perform a downgrade attack.

No, this would change the meaning. The idea here that the second optional
step of marking all PPKs as mandatory has no effect against passive attackers
(because PPK is already used for all connections), instead by this step
we protect ourselves against a hypothetical downgrade attack performed
by active attacker. So, how about:

    This will not affect the strength against a
    passive attacker, but it would mean that an active attacker with a quantum
    computer (which is sufficiently fast to be able to break the (EC)DH
    in real time) would not be able to perform a downgrade attack.

> -- Section 6.  Typo. s/transmited/transmitted/

Thank you,
Valery.

> 
> 
> _______________________________________________
> IPsec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ipsec

---

From: "Panos Kampanakis (pkampana)" <[email-masked]>
Date: Wed, 8 Jan 2020 17:07:12 +0000

Hi Roman,

Two more comments in addition to Valery's. 

> > ** Section 1.  Per “Recent achievements in developing quantum computers …”, is there a citation?

[I-D.hoffman-c2pq] is a good citation which we use already that talks about the QC concern and Grover and Shor's algorithms. So we could cite it here as well. Now about the latest QC advancements, the latest that I know of was Google's quantum supremacy one https://www.nature.com/articles/d41586-019-03224-w But that will change with other announcements that will come a later. So, I am afraid there is no good citation here other than [I-D.hoffman-c2pq]. 

> -- The definition of quantum resistant doesn’t seem exactly precise.  

There have been four terms that can be used interchangeably. Quantum-safe used by ETSI, post-quantum used by NIST, quantum-secure, and quantum-resistant. Practically all these mean algorithms that are not susceptible to a variant of Shor's algorithm and offer adequate classical and PQ security. NIST defines it as "cryptographic systems that are secure against both quantum and classical computers, and can interoperate with existing communications protocols and networks. ". I guess we could use one of the terms throughout the document. And we could rephrase the sentence 

  invulnerable to an attacker with a
  quantum computer.

to say something like 

   secure against classical attackers 
   of today or future attackers with a 
   quantum computer.

Rgs, 
Panos

-----Original Message-----
From: IPsec <[email-masked]> On Behalf Of Valery Smyslov
Sent: Wednesday, January 08, 2020 9:42 AM
To: 'Roman Danyliw' <[email-masked]>; 'The IESG' <[email-masked]>
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [IPsec] Roman Danyliw's No Objection on draft-ietf-ipsecme-qr-ikev2-10: (with COMMENT)

Hi Roman,

> 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
> ** Section 1.  Per “Recent achievements in developing quantum 
> computers …”, is there a citation?

Do you mean a citation about achievements? I'm not sure it's easy to find a stable reference here, but probably Scott or David or Panos have a good one...

> -- The definition of quantum resistant doesn’t seem exactly precise.  
> A quantum-resistant algorithm isn’t “invulnerable to an attacker with 
> a quantum computer”, rather isn’t it instead no easier to attack than 
> with known classical architectures?

My understanding is that it's infeasible to break such a system even with a help of quantum computer. 
Grover's algorithm still gives an attacker equipped with QC an advantage comparing with classical architectures, but proper selection of algorithms and key lengths doesn't allow him to break the system.

> -- The first clause says the underlying primitives are quantum-secure, 
> but then says that this translated into something being 
> quantum-resistant.  I found it confusing to mix both terms (which 
> sometimes are used interchangeably)

> ** Section 1.  Per “This document describes a way to extend IKEv2 to 
> have a similar property; assuming that the two end systems share a 
> long secret key then the resulting exchange is quantum resistant.”, I 
> stumbled over this language a bit because I wasn’t sure which property 
> you were referencing – was it the list of things in the previous 
> paragraph’s last sentence that made it “quantum-secure”?

> Then, it computes this modification of the standard IKEv2 key 
> derivation from Section 2.14 of [RFC7296]:

OK.

> of the sub-keys (i.e., SK_d’ and SK_pi’ and SK_pr’) in the this 
> SKEYSEED formula with the SKEYSEED formula in Section 2.14 of [RFC72196].

I'm not sure I fully understand what you mean.
I think we provide formulas of how prime and non-prime versions are correlated (i.e. how non-prime versions are computed from prime versions).
Am I missing something?

> ** Editorial Nits:
> 
> -- Section 1.  Editorial. s/this note/this document/ -- trying to be 
> consistent on how the I-D references itself.

> This will not alter the resistance to a passive attack as even an 
> attacker with a quantum computer (which is sufficiently fast to be 
> able to break the (EC)DH in real time) would not be able to perform a 
> downgrade attack.

No, this would change the meaning. The idea here that the second optional step of marking all PPKs as mandatory has no effect against passive attackers (because PPK is already used for all connections), instead by this step we protect ourselves against a hypothetical downgrade attack performed by active attacker. So, how about:

Thank you,
Valery.

---

From: Benjamin Kaduk <[email-masked]>
Date: Mon, 13 Jan 2020 09:57:50 -0800

> > draft-ietf-ipsecme-qr-ikev2-10: No Objection
[...]
> are correlated (i.e. how non-prime versions are computed from prime versions).

I think the idea is something in the general vicinity of "the un-primed
values SK_d, SK_pi, and SK_pr are used as inputs to subsequent steps of the
IKEv2 exchange; this document uses the primed versions to represent the
output of prf+ that are used directly in regular IKEv2, in order to
introduce an additional operation (combination with PPK) between prf+ and
subsequant usage".  A reader looking at this document and RFC 7296
side-by-side will see that where RFC 7296 sets {SK_d [...]} = prf+
(SKEYSEED, [...]), this document uses the "primed" versions, and might
wonder what's different between SK_d (RFC 7296) and SK_d' (this document).

-Ben

---

From: Valery Smyslov <[email-masked]>
Date: Mon, 13 Jan 2020 21:02:36 +0300

Hi Ben,

> wonder what's different between SK_d (RFC 7296) and SK_d' (this

Thank you for clarification, we'll add similar clarification to the draft.

Regards,
Valery.

---

From: Roman Danyliw <[email-masked]>
Date: Mon, 13 Jan 2020 18:04:26 +0000

Hi!

> From: Benjamin Kaduk <[email-masked]>
> Sent: Monday, January 13, 2020 12:58 PM
> To: Valery Smyslov <[email-masked]>
> Cc: Roman Danyliw <[email-masked]>; 'The IESG' <[email-masked]>;
> [email-masked]; [email-masked]; [email-masked]; draft-
> [email-masked]
> > I think we provide formulas of how prime and non-prime versions are
> > correlated (i.e. how non-prime versions are computed from prime
> versions).
> > Am I missing something?
> 
> I think the idea is something in the general vicinity of "the un-primed values
> SK_d, SK_pi, and SK_pr are used as inputs to subsequent steps of the
> output of prf+ that are used directly in regular IKEv2, in order to introduce an
> additional operation (combination with PPK) between prf+ and subsequant
> usage".  A reader looking at this document and RFC 7296 side-by-side will see
> that where RFC 7296 sets {SK_d [...]} = prf+ (SKEYSEED, [...]), this document
> uses the "primed" versions, and might wonder what's different between
> SK_d (RFC 7296) and SK_d' (this document).

Yes.  That's the kind of clarifying language I think would help.  It's not that the formula isn't self-consistent to this draft.  It's that when this document says compute a "standard IKEv2 key derivation" and then "a reader looking at this document and RFC7296 ... might wonder what's the difference ..." (as Ben said).  

Thanks,
Roman