Re: [IPsec] Roman Danyliw's No Objection on draft-ietf-ipsecme-qr-ikev2-10: (with COMMENT)
Hi!
> -Original Message-
> From: Benjamin Kaduk
> Sent: Monday, January 13, 2020 12:58 PM
> To: Valery Smyslov
> Cc: Roman Danyliw ; 'The IESG' ;
> ipsec@ietf.org; ipsecme-cha...@ietf.org; david.walterm...@nist.gov; draft-
> ietf-ipsecme-qr-ik...@ietf.org
> Subject: Re: [IPsec] Roman Danyliw's No Objection on draft-ietf-ipsecme-qr-
> ikev2-10: (with COMMENT)
>
> On Wed, Jan 08, 2020 at 05:41:59PM +0300, Valery Smyslov wrote:
> >
> > > Roman Danyliw has entered the following ballot position for
> > > draft-ietf-ipsecme-qr-ikev2-10: No Objection
> > >
> > >
> > > --
> > > COMMENT:
> > >
> > > --
> [...]
> >
> > > -- 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].
> >
> > 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?
>
> 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).
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
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Roman Danyliw's No Objection on draft-ietf-ipsecme-qr-ikev2-10: (with COMMENT)
Hi Ben,
> On Wed, Jan 08, 2020 at 05:41:59PM +0300, Valery Smyslov wrote:
> >
> > > Roman Danyliw has entered the following ballot position for
> > > draft-ietf-ipsecme-qr-ikev2-10: No Objection
> > >
> > > --
> > > COMMENT:
> > > --
> [...]
> >
> > > -- 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].
> >
> > 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?
>
> 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).
Thank you for clarification, we'll add similar clarification to the draft.
Regards,
Valery.
> -Ben
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Roman Danyliw's No Objection on draft-ietf-ipsecme-qr-ikev2-10: (with COMMENT)
On Wed, Jan 08, 2020 at 05:41:59PM +0300, Valery Smyslov wrote:
>
> > Roman Danyliw has entered the following ballot position for
> > draft-ietf-ipsecme-qr-ikev2-10: No Objection
> >
> > --
> > COMMENT:
> > --
[...]
>
> > -- 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].
>
> 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?
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
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Roman Danyliw's No Objection on draft-ietf-ipsecme-qr-ikev2-10: (with COMMENT)
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 On Behalf Of Valery Smyslov Sent: Wednesday, January 08, 2020 9:42 AM To: 'Roman Danyliw' ; 'The IESG' Cc: ipsec@ietf.org; ipsecme-cha...@ietf.org; david.walterm...@nist.gov; draft-ietf-ipsecme-qr-ik...@ietf.org Subject: Re: [IPsec] Roman Danyliw's No Objection on draft-ietf-ipsecme-qr-ikev2-10: (with COMMENT) Hi Roman, > 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? 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... > ** 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? 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. > -- 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) To be frank I don't feel difference here, but again I rely on my co-authors here. > ** 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”? 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 3. Per the description of modified IKEv2 key derivation: > > -- Recommend explicitly
Re: [IPsec] Roman Danyliw's No Objection on draft-ietf-ipsecme-qr-ikev2-10: (with COMMENT)
Hi Roman, > 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? 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... > ** 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? 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. > -- 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) To be frank I don't feel difference here, but again I rely on my co-authors here. > ** 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”? 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 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]: OK. > -- 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]. 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. OK, already noted by Barry. > -- 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. 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
