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
