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 <ipsec-boun...@ietf.org> On Behalf Of Valery Smyslov Sent: Wednesday, January 08, 2020 9:42 AM To: 'Roman Danyliw' <r...@cert.org>; 'The IESG' <i...@ietf.org> 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 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 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/ Thank you, Valery. > > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec _______________________________________________ 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
