> 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 <mcr+i...@sandelman.ca>
Sent: Wednesday, May 21, 2025 4:21 PM
To: Kampanakis, Panos <kpa...@amazon.com>
Cc: Christopher Patton <cpat...@cloudflare.com>; Valery Smyslov
<smyslov.i...@gmail.com>; ipsec@ietf.org
Subject: RE: [EXTERNAL] [IPsec] Re: Binding properties of
draft-ietf-ipsecme-ikev2-mlkem-00
Kampanakis, Panos <kpanos=40amazon....@dmarc.ietf.org> 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 <mcr+i...@sandelman.ca> . o O ( IPv6 IøT consulting )
Sandelman Software Works Inc, Ottawa and Worldwide
_______________________________________________
IPsec mailing list -- ipsec@ietf.org
To unsubscribe send an email to ipsec-le...@ietf.org
