Last call; does anyone have any objections if I send these changes to the RFC editors as a final modification?
From: Scott Fluhrer (sfluhrer) <sfluhrer=40cisco....@dmarc.ietf.org> Sent: Thursday, June 11, 2020 4:05 PM To: Scott Fluhrer (sfluhrer) <sfluh...@cisco.com>; ipsec@ietf.org Subject: RE: Last minute change to draft-ietf-ipsecme-qr-ikev2 Does anyone else have comments about this text (either for or against)? Paul, Tero, you had previously chimed in; do either of you something to say? From: IPsec <ipsec-boun...@ietf.org<mailto:ipsec-boun...@ietf.org>> On Behalf Of Scott Fluhrer (sfluhrer) Sent: Monday, June 08, 2020 11:06 AM To: ipsec@ietf.org<mailto:ipsec@ietf.org> Subject: Re: [IPsec] Last minute change to draft-ietf-ipsecme-qr-ikev2 Tero had this comment (which didn't make it onto this mailing list): Btw, there is similar text in RFC7296 (base IKEv2) saying following: When using pre-shared keys, a critical consideration is how to assure the randomness of these secrets. The strongest practice is to ensure that any pre-shared key contain as much randomness as the strongest key being negotiated. Deriving a shared secret from a password, name, or other low-entropy source is not secure. These sources are subject to dictionary and social-engineering attacks, among others. so one option would also point to IKEv2 RFC and say that same restrictions for not using low-entropy key that apply for pre-shared keys there applies also PPK. That comment strikes me as having a good point; the pre-shared keys in IKE are subject to exactly the same dictionary attack that a PPK would have, and so the same advice would apply to both. On the other hand, asking the reader to dig through a 142 page document for the relevant advice, or even scan through 3 pages of the security considerations would appear to be less friendly than we could be; in addition, advice for PPKs also need to consider Quantum Computers (which were not a consideration with IKE pre-shared keys). How about this text (which integrates suggestions both from the security considerations of both RFC7296 and the PPK text, while trying to not sound like Frankentext [1]. A critical consideration is how to assure the randomness of this post-quantum preshared key. Quantum computers are able to perform Grover's algorithm [GROVER]; that effectively halves the size of a symmetric key. In addition, an adversary, even with a conventional computer, can perform a dictionary search over plausible post-quantum preshared key values. The strongest practice is to ensure that any post-quantum preshared key contains at least 256 bits of entropy, this will provide 128 bits of post-quantum security, while providing security against conventional dictionary attacks. That provides security equivalent to Level 5 as defined in the NIST PQ Project Call For Proposals [NISTPQCFP]. Deriving a postquantum preshared key from a password, name, or other low-entropy source is not secure because of these known attacks. The highlighted sections is text that is new to the draft; this would replace the first paragraph of the Security Considerations section. And, I would agree with Valery; I also would prefer to avoid putting numbers that sound concrete; especially on something that is hard to measure (and "amount of entropy" is notoriously hard to measure - you can measure length, but that doesn't actually mean "guessability", which is what we're trying to get at). [1]: For those readers who might not be familiar with English Literation or pop culture, there is a classic English novel "Frankenstein", when a scientist (Dr Frankenstein) patches together parts from several corpses, and brings it to life (of course, it didn't go well); in later references to this original novel, the stitching of the several parts is obvious. The allusion "Frankentext" suggests parts of several works being clumsily stitched together. It is typically good advice to avoid cultural references when talking on an international mailing list; I just couldn't help myself this time.... From: Scott Fluhrer (sfluhrer) Sent: Friday, June 05, 2020 3:41 PM To: ipsec@ietf.org<mailto:ipsec@ietf.org> Subject: Last minute change to draft-ietf-ipsecme-qr-ikev2 The draft "Mixing Preshared Keys in IKEv2 for Post-quantum Security" was winding through the AUTH48 process, when at the last minute, I received an email from a researcher who thought they found a problem with low entropy PPKs (the preshared keys that the draft uses). While it turned out that what the found really wasn't a problem, such low entropy PPKs are a problem in general. To address this, I suggested to the RFC editors that we modify the first paragraph of the security considerations from: Original text: Quantum computers are able to perform Grover's algorithm [GROVER]; that effectively halves the size of a symmetric key. Because of this, the user SHOULD ensure that the post-quantum preshared key used has at least 256 bits of entropy, in order to provide 128 bits of post-quantum security. That provides security equivalent to Level 5 as defined in the NIST PQ Project Call For Proposals [NISTPQCFP]. Modified text: Quantum computers are able to perform Grover's algorithm [GROVER]; that effectively halves the size of a symmetric key. Because of this, the user SHOULD ensure that the post-quantum preshared key used has at least 256 bits of entropy, in order to provide 128 bits of post-quantum security. That provides security equivalent to Level 5 as defined in the NIST PQ Project Call For Proposals [NISTPQCFP]. An attacker who impersonates the server is able to validate guesses to the PPK. Because of this, low entropy PPK values MUST NOT be used. Additional text high-lighted. Because of the lateness of this change, Ben Kaduk (the area director) asked me to check with the list to make sure everyone is OK with this addition. Comments?
_______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
