Hi, Chris and all, Generally, the new text from Chris sounds good but it may be not rigorously correct. Namely, as mentioned in one of my previous emails, there are two subtle issues here:
1) An algorithm is weak or strong, it should be according to the view point of the attacker, not that of users or specification designers (us). 2) A CRQC should be main reason to lead such downgrade attacks, but not the only possible reason. In fact, any flawed algorithm could be selected as the "weak" KE or KEM by the attacker, if the attacker can break this algorithm online even this is regarded as strong in normal sense. Now, let me give an example to explain what I mean. --------- Example in the IKEv2 using only traditional KE, say, DH. Say, as an IoT device, the Initiator I can run both DH1 and DH2, but device I prefers to run DH1 for saving energy. Here, DH1 is weaker than DH2 in security, according to RFC sepecification. However, in some way, an attacker finds a flaw in DH2 (flaw due to algorithm, implementation, or any other reasons) so that the attacker can break DH2 online. In an instance of IKEv2, I proposes to run (DH1, DH2) with DH1 as its priority, and the responder R supports both DH1 and DH2, and its policy is to follow the proposal from the initiator. So, in a normal case, they should finish the IKEv2 by running DH1. However, if the downgrading attacker A is present, A will be able to lead that I and R will finally run DH2, as DH2 is beneficial to R, though DH2 is stronger than DH1, in the view points of users and specification designers. So, the consequence is: A stronger algorthim DH2 is selected according to the attacker's preference by mounting an downgrading attack. --------- So, my first specific suggestion is: in the following text, it may need to stress that "the weakest key exchange" SHOULD be explained in the view point of attacker, not in that of the IKEv2 users or specification designers. < "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."> --------- My 2nd specific suggestion or comment is that the following "The simplest way" may be not enforceable or not work to prevent downgrading attacks, without mention assumimg that one side know the algorithm configuration of the other side. <"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"> Here are the reasons. a) For some conservative organizations, hybrid KEMs can be their security policy. So, "The simplest way" is not enforceable in such organizations. b) "The weakest key exchange" can be a KEM as well, due to any possible reason. Say, if the attacker A can break ML-KEM 768 online due to some flaw A just identified, but A can break neither DH1 or DH2. However, if I and R follow the above "the simplest way" to prevent downgrading attacks and they know that both sides support ML-KEM 768, they shall just run ML-KEM 768 by disabling all DH algorithms. Then, "the simplest way" to prevent downgrading attacks will just help the attacker mounting such a downgrading attack. Note: In this case, actually, the attacker can be just a passive eavesdropper. So, "the simplest way" may be not really simple to prevent downdrading attacks. ----- Of course, the IKEv2 (or any security protocol) can still be insecure when the users select a flawed algorithm (either a traditional DH or a PQ KEM). However, such sequence is supposed to be known or told when the IKEv2 is designed and/or employed. It should not be unkown when designed, but later is exposed due to unexpected attacks. Or speaking in the view points of the initiator and the responder, the KE algroithm selected should be that one with highest priority according to their proposals and policies, but should not be a result affected by attackers. So, I do believe that the dowbgrading attacks SHOULD be prevented when IKEv2 is designed or updated. Cheers, Guilin 发件人：Kampanakis, Panos <[email protected]<mailto:[email protected]>> 收件人：Christopher Patton <[email protected]<mailto:[email protected]>> 抄 送：ipsec <[email protected]<mailto:[email protected]>> 时 间：2025-07-30 23:43:45 主 题：[IPsec] Re: draft-ietf-ipsecme-ikev2-mlkem downgrade text (was Re: draft-smyslov-ipsecme-ikev2-downgrade-prevention) Hi Chris, I work old school on this one (xml, no markdown). I uploaded -01 for clarity. The diff is herehttps://author-tools.ietf.org/iddiff?url1=draft-ietf-ipsecme-ikev2-mlkem-00&url2=draft-ietf-ipsecme-ikev2-mlkem-01&difftype=--html I like your text """ 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 """ I will wordsmith a little. From: Christopher Patton <[email protected]<mailto:[email protected]>> Sent: Wednesday, July 30, 2025 10:00 AM To: Kampanakis, Panos <[email protected]<mailto:[email protected]>> Cc: Scott Fluhrer (sfluhrer) <[email protected]<mailto:[email protected]>>; ipsec <[email protected]<mailto:[email protected]>> Subject: RE: [EXTERNAL] [IPsec] Re: draft-smyslov-ipsecme-ikev2-downgrade-prevention CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe. 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 herehttps://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]
