> After a CRQC, doesn't this mean that an active on-path attacker (meddler in > the middle) also has this information...
Yes a CRQC attacker could get the identities, certs and traffic selectors which I think is not detrimental. They would not get any of the data after rekeying the Child SA with ML-KEM. Otherwise, it is tough to address the bootstrapping problem of any new mechanism and maintain backwards compatibility. In way it is the same in TLS 1.2 since adding a new option which does not break legacy makes this new option downgradable too. I think we need a deep discussion the WG about the approach. I would like one that solves the problem but does not change the protocol. And then change the protocol to address downgrades altogether. -----Original Message----- From: Michael Richardson <[email protected]> Sent: Wednesday, May 21, 2025 4:21 PM To: Kampanakis, Panos <[email protected]> Cc: Christopher Patton <[email protected]>; Valery Smyslov <[email protected]>; [email protected] Subject: RE: [EXTERNAL] [IPsec] Re: Binding properties of draft-ietf-ipsecme-ikev2-mlkem-00 Kampanakis, Panos <[email protected]> wrote: > I fleshed out the details of this approach a bit in > https://github.com/csosto-pk/pq-mlkem-ikev2/issues/5#issuecomment-2896485221 > Basically you don’t do IKE_INTERMEDIATE at all, you do all classical > and immediately rekey the SA and the Child SA (if already negotiated) > with IKE_FOLLOWUP_KE which means that your SKEYSEED and SKEYMAT and all The initiator must know that it's going to do this, so it SHOULD avoid keying the child SA. If it's keyed, it might get used, and I think we'd want to avoid that. > other keys that protect data are quantum-resistant. We do all that > because at the time of IKE_FOLLOWUP_KE we have the full identity of the > peer and thus can enforce the config that says “I expect Peer X to be > upgraded and thus must use ML-KEM”. Note the messages and rekeys etc > are already supported in RFC9370, we are not doing anything exotic. We After a CRQC, doesn't this mean that an active on-path attacker (meddler in the middle) also has this information... -- Michael Richardson <[email protected]> . o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide _______________________________________________ IPsec mailing list -- [email protected] To unsubscribe send an email to [email protected]
