I've been slowly working to replace algorithms I rely on with PQC
resistant algorithms. strongSwan 6.0.0 contained optional ML-KEM
support, which we didn't enable (likely because it's an obscure looking
flag).

I've patched strongSwan to build the ml plugin, which I added to
libstrongswan-extra-plugins, as is our convention. Attached is a
debdiff.

I've built this on trixie and sid, and have tested[1] this for my personal
site-to-site VPN configuration. It looks good so far - from -list-sas:

```
   AES_GCM_16-256/PRF_HMAC_SHA2_384/ECP_384/KE1_ML_KEM_1024
   established 296s ago, rekeying in 12729s
```

And the output of list-algs:

```
$ swanctl --list-algs | grep -i KEM
   ML_KEM_512[openssl]
   ML_KEM_768[openssl]
   ML_KEM_1024[openssl]
```

Thanks for maintaining strongSwan


[1]: specifically, i'm using
      proposals = aes256gcm16-prfsha384-prfsha512-ecp384-ke1_mlkem1024
      with success.

control: severity -1 important

Hi Paul,

thanks for the bug and the patch.

I've not yet enabled the PQC algorithms support not particularly because it's
an obscure flag but rather because of the maturity of that support (we have
had experimental algorithms in strongSwan since quite a while).

I'm definitely in favor of enabling those, and have them settled for Forky but
I'm not entirely sure yet which ones to enable and where (which package) to
put them. I especially need to check if it's possible to setup and maybe
enforce hybridation.

I'll not just apply your patch asap but I'll keep it in mind in the following
months (feel free to bug me about it if I don't follow up soon enough) while
thinking about it along with upstream.

Thanks again for the reminder and the patch!

Regards,

Hi Paul,

I assume this is the output with sid as it clearly shows the ml plugin
is not necessary because ML-KEM is provided by the openssl plugin via
OpenSSL.  This is supported since strongSwan 6.0.2 and OpenSSL 3.5.0.
Since trixie ships 6.0.1, enabling the ml plugin could be an option.
Another would be to backport the patch that added support for ML-KEM in
the openssl plugin [1], as trixie ships OpenSSL 3.5.5.

Regards,
Tobias

[1]
https://github.com/strongswan/strongswan/commit/b914333ab4fdbef0c1ff251fb481ebbcc34e31b2

Hi Paul,

I assume this is the output with sid as it clearly shows the ml plugin
is not necessary because ML-KEM is provided by the openssl plugin via
OpenSSL.  This is supported since strongSwan 6.0.2 and OpenSSL 3.5.0.
Since trixie ships 6.0.1, enabling the ml plugin could be an option.
Another would be to backport the patch that added support for ML-KEM in
the openssl plugin [1], as trixie ships OpenSSL 3.5.5.

Regards,
Tobias

[1]
https://github.com/strongswan/strongswan/commit/b914333ab4fdbef0c1ff251fb481ebbcc34e31b2

Heyya, Tobias -- thanks for taking a look!

It was not - which is now unnerving me. This was two stable systems
talking using the strongSwan version from sid that I built on stable.

Attached is the buildinfo from pbuilder

Very cool. I was misreading that output; I thought it had to do with the
underlying ml.so's backend -- but looking back it's WAY more obvious
that it's the plugin providing it. Nice. Thank you!

So, in theory, if I "just" rebuilt the version from sid (or just ran
sid!) I should already see this algorithm without my patch here, since
this module isn't even used. Cool. I'll give that a try later today and
mark this bug as fixed by the right strongSwan version (6.0.2)

I'll leave that up to corsac, both options there have some impugned
work, I will say, a third option that would "scratch my itch" is to have
a backport -- the package "as-is" in sid does backport cleanly --
less work than a full stable point release, it'll be around for users
who need it fairly easily, and taget forky (as he mentioned in his last
email he was shooting for)

Thank you very much, Tobias and corsac! appreciate you both!

   paultag

Ah, now I actually remember seeing the release notes and thinking that I
didn't have to do anything - neat -.

About hybridation, the French national cybersecurity agency published
(https://messervices.cyber.gouv.fr/documents-guides/transition_post_quantique_ipsec.pdf
in French only, sorry) a support document. It seems to indicate strongSwan 
- already supports draft RFC 9370 for hybrid key-exchange but I'm not sure if
I need to enable something in the package
- doesn't have support for hybrid signature authentication because there's
simply no standard on it.

Is that correct?

Yeah, I guess backporting might make sense here.

Regards,

Yes, since 6.0.0, multiple key exchanges according to RFC 9370 may be
configured.  Any supported key exchange algorithm can be used for that
and it doesn't require any special build options.  However, to use
ML-KEM, you additionally need a plugin that provides it.  Before 6.0.2,
the openssl plugin only supported it via AWS-LC, so the ml plugin could
be built as it has no third-party dependencies.  Alternatively, the
patch that added support for ML-KEM via OpenSSL 3.5.0+ to the openssl
plugin may be backported.

Regarding the signatures, ML-DSA is currently not supported as the draft
for IKEv2 is not yet fully stable and there are also some issues with
third-party libraries (the ASN.1 encoding for private keys has changed
and not all libraries support the proper encoding yet).  There is a
branch in our repository, and another for hybrid signature schemes, but
not sure yet when those will be ready for release.

Regards,
Tobias

fixed -1 6.0.2-1
thanks

Apologies for the noise! I've marked this bug as fixed by 6.0.2-1 -
happy to have this bug be -done'd if things are tidy, depending on your
intent, corsac.

More words below:

Sure enough!

 From a sid system, running the package in sid:

```
$ swanctl --list-algs | grep ML
   ML_KEM_512[openssl]
   ML_KEM_768[openssl]
   ML_KEM_1024[openssl]
```

Well, there it is! ML-KEM is already good on strongSwan 0.6.2+ -- my
fault. I saw stable had the same major/minor and didn't bother checking
to see what state sid was in after doing a search for
libstrongswan-ml.so. I should have tried it out in side.

This means, as Tobias points out, that my rebuild worked not because
of my patch, but merely due to the build of current strongSwan on
stable.

It also means this attached patch should likely _not_ be applied in sid.
It gets us nothing. Thank you very much, Tobias.

Yeah. It's been pretty tough RFC-wise for IPSec + PQC for a while. I
think OpenBSD iked landed sntrup761x25519 recently (mostly pulled from
OpenSSH's implementation, I was told), which is also not formalized
in an RFC AFAIK[citation needed].

My server(s) that are running IPSec are stable, so I am still interested
in this change for stable, but I don't want to do anything at your
expense. I'm content to put this in a local repo for myself, but it
would make me feel good to help update this for others too.

I'd be happy to send backports to stable-backports if you're OK with it
-- I can offer to help maintain it for the rest of stable's lifetime and
any related noise (bug triage for stable-backport bugs, etc).

I'd also be happy to talk with you and the RT if I can be any help and
there's interest in a stable update. I realize this is likely the most
work if they're not interested in sid's source going to stable, since if
my attached patch doesn't work as-is on stable sources, I think (as was
indicated on an older bug), we may need to, as Tobias says, cherry-pick
the ML-KEM OpenSSL patchset and apply that, which seems ... touchy.

fondly,
   paultag

No, it's not.  There is an expired independent draft that defines this
combination for SSH [1].  But not only are such hybrids that don't rely
on RFC 9370 not specified for IKEv2 (as they could be impossible to use
because of IP fragmentation).  Since NTRU Prime "lost" against Kyber in
the NIST ML-KEM competition, it probably got pretty difficult to define
that combination even for TLS (which otherwise will soon get similar
hybrid key exchanges [2]).  For IKEv2, NTRU Prime would have to be added
as separate KE method.  In that regard it's similar to FrodoKEM, but for
that there actually is an active draft [3] due to the standardization
process via ISO.

By the way, it looks like they added that in May 2021 already [4], so
that was two years before RFC 9370 was published and nearly three and a
half years before identifiers for ML-KEM were pre-allocated (the ML-KEM
draft should finally be released as RFC soon [5]).

Regards,
Tobias

[1] https://datatracker.ietf.org/doc/html/draft-josefsson-ntruprime-ssh
[2] https://datatracker.ietf.org/doc/draft-ietf-tls-ecdhe-mlkem/
[3]
https://datatracker.ietf.org/doc/html/draft-ietf-ipsecme-hybrid-kem-ikev2-frodo
[4]
https://github.com/openiked/openiked-portable/commit/3a60108db9ebfcdadc75537cab3d94e93fb627db
[5] https://datatracker.ietf.org/doc/draft-ietf-ipsecme-ikev2-mlkem/