Panos, +1 on the new draft not blocking draft-ietf-ipsecme-ikev2-mlkem. I now > mention draft-smyslov-ipsecme-ikev2-downgrade-prevention informatively in > draft-ietf-ipsecme-ikev2-mlkem as a long term solution and bring up the > downgrade and its practical applicability. And mention a workaround of > creating a Child SA only after an ML-KEM Followup-KE. > > > > Scott, > > I could use a review of the new text. It is here > https://mailarchive.ietf.org/arch/msg/ipsec/qhbfyW0cE3uv9gXBF4RIVW6OXq0/ >
I'm happy to review as well, but it would be nice to see this text in context. Would you mind putting up a PR on the repo? Note: as of writing, I don't see any mention of downgrades in the markdown file: https://github.com/csosto-pk/pq-mlkem-ikev2/blob/main/draft-kampanakis-ml-kem-ikev2.md I do however see it here, in the XML file for -01: https://github.com/csosto-pk/pq-mlkem-ikev2/blob/main/draft-ietf-ipsecme-ikev2-mlkem-01.xml#L148-L149 Which file should we be looking at? In any case, I think the draft should address the attack in the following way. In Security Considerations, I think we should have a very high level description of the attack (no more than a few sentences) and an informative reference to Section 5.2 of https://eprint.iacr.org/2016/072. We should then suggest some simple mitigations. As a non IKE expert, I can't assess whether your suggested mitigation ("creating a CHild SA only after an ML-KEM Followup-KE") is sufficient. Hopefully others will chime in there. In any case, we should also suggest the simplest mitigation, which is to disable classical-only key exchanges whenever possible. Here's some text we might iterate on: """ IKE v2 is susceptible to downgrade attacks [IKEv2-DOWNGRADE] in which the peers are forced to negotiate the weakest key exchange method supported by both. In particular, if both peers support some sequence of key exchanges that involve only classical algorithms, an active, on-path attacker with a CRQC may be able to convince the peers to use it even if they both support ML-KEM. The simplest way to mitigate these attacks is to disable support for classical-only sequences of key exchanges whenever possible. If the responder knows out-of-band that the initiator supports ML-KEM, then it SHOULD reject any proposal that doesn't include an ML-KEM key exchange. Likewise, if the initiator knows out-of-band that the responder supports ML-KEM, it SHOULD abort the protocol if the responder selects a proposal that doesn't include ML-KEM. """ Caveats/questions: - Here "[IKEv2-DOWNGRADE]" should be a reference to https://eprint.iacr.org/2016/072. (Note this paper also appeared at IEEE Security and Privacy in 2016.) It could also refer to draft-smyslov-ipsecme-ikev2-downgrade-prevention, but again, I don't think this is necessary. - The draft defines support for multiple parameter sets. Perhaps the normative text should take into consideration the parameters targeted by the application. (In theory, a CRQC may one day break weak ML-KEM parameters, which is why we have -768 and -1024.) That is, instead of saying "if the peer is known to support ML-KEM", it might say "if the peer is known to support ML-KEM with at the required security level". - I'm using the term "sequence of key exchanges" to refer to an initial key exchange followed by some number of intermediate exchanges as specified in RFC 9370. Is there a more succinct term for this? Chris P.
_______________________________________________ IPsec mailing list -- [email protected] To unsubscribe send an email to [email protected]
