Hi Scott,
Scott Fluhrer wrote:
* Transition – I believe (and do correct me if I’m wrong) that in IKE each
side just sends over its certificate and auth payload and assumes that the peer
knows how to handle them. We need to do something better if we need for
updated sites to work with nonupgraded ones. One thing that’s in TLS 1.2 is
the client provides a list of “which signatures I understand” (the
signature_algorithms extension in the client hello). In TLS 1.3, they extended
it to include a list of “which signatures can appear in a cert chain”. Using
something similar in IKEv2 would appear to be one way to address the issue (of
course, the details would need to be worked out – what’s in TLS might not be
exactly what we need). Or, does anyone else have other ideas?
Yes, this seems very good to discuss. I assume this has also been a problem in
the past for systems upgrading from PSK to RSA to ECDSA. Seems like there is
already an adopted draft that allows announcing supported authentication
methods.
https://datatracker.ietf.org/doc/draft-ietf-ipsecme-ikev2-auth-announce/
TLS 1.3 even has two extensions:
“The "signature_algorithms_cert" extension applies to signatures in
certificates, and the "signature_algorithms" extension, which originally
appeared in TLS 1.2, applies to signatures in CertificateVerify messages.
“If no "signature_algorithms_cert" extension is present, then the
"signature_algorithms" extension also applies to signatures appearing in
certificates.”
I don’t know how well that would map to IKEv2. Would ML-DSA be part of
authentication method 14 (RFC 7427)?
* Scott Fluhrer wrote:
* Multiple authentication – there may be a desire to depend on multiple
signature algorithms – that is, authentication would be secure unless both RSA
and Dilithium are broken. If we decide that this is something we want to
support (and we may or may not decide to), there are several ways to do it
(having both algorithms in a single certificate, or use multiple independent
certificates, or even more generally, provide for multiple IKEv2 authentication
methods in parallel). This is of some controversy in the lamps working group,
it might be good to hash out what makes sense for IKE.
I am personally not sure multiple signatures is needed for end-entity
certificates with short life times. My understading is that the controversy in
lamps was about hybrid keys and signatures in a singe certificate chain. I was
not active in that discussion, but talking to some of my PKI people they do not
like hybrid algorithms in certificates very much and would rather use two
separate chains.
My feeling is that IPSECME should register ML-DSA in one standards track RFC.
If people want multiple authentication, that can be done in a separate RFC just
like RFC 9242, RFC 9370, and draft-kampanakis-ml-kem-ikev2 are independent.
Cheers,
John Preuß Mattsson
From: Scott Fluhrer (sfluhrer) <[email protected]>
Date: Sunday, 3 March 2024 at 18:40
To: John Mattsson <[email protected]>, [email protected] <[email protected]>
Subject: RE: Review of draft-kampanakis-ml-kem-ikev2-02
I agree that it sounds like a good time to start work on postquantum IKEv2
authentication. In addition to the lamps draft you cite, my list of items that
need to be done (or at least considered) include:
* Specifying the code points in the auth payload to mean “dilithium
signature” (and I believe we need three for the three dilithium parameter
sets); that’s the easy part.
* While the draft FIPS 204 does not mention it, NIST has publicly pondered
modifying the signature API to include a diversification string (e.g. is this a
signature to authenticate IKEv2 vs one to authenticate TLS, for example), a
flag whether this is a ‘prehash’ signature or not (that is, one where we hash
the message and then sign the hash), and if it is, what hash function did we
use. While it is not certain whether the final FIPS 204 will include them (I
expect that it will), it might be good to consider which options we select
should it include them.
* Transition – I believe (and do correct me if I’m wrong) that in IKE each
side just sends over its certificate and auth payload and assumes that the peer
knows how to handle them. We need to do something better if we need for
updated sites to work with nonupgraded ones. One thing that’s in TLS 1.2 is
the client provides a list of “which signatures I understand” (the
signature_algorithms extension in the client hello). In TLS 1.3, they extended
it to include a list of “which signatures can appear in a cert chain”. Using
something similar in IKEv2 would appear to be one way to address the issue (of
course, the details would need to be worked out – what’s in TLS might not be
exactly what we need). Or, does anyone else have other ideas?
* Multiple authentication – there may be a desire to depend on multiple
signature algorithms – that is, authentication would be secure unless both RSA
and Dilithium are broken. If we decide that this is something we want to
support (and we may or may not decide to), there are several ways to do it
(having both algorithms in a single certificate, or use multiple independent
certificates, or even more generally, provide for multiple IKEv2 authentication
methods in parallel). This is of some controversy in the lamps working group,
it might be good to hash out what makes sense for IKE.
From: IPsec <[email protected]> On Behalf Of John Mattsson
Sent: Sunday, March 3, 2024 3:35 AM
To: [email protected]
Subject: [IPsec] Review of draft-kampanakis-ml-kem-ikev2-02
Review of draft-kampanakis-ml-kem-ikev2-02
Hi,
I think IPSECME should adopt this draft asap. This should definitely be a
standards track RFC.
I really like that IKEv2 register KEMs as separate code points and not hybrid
code points like in TLS 1.3. I think the hybrid code points in TLS 1.3 might
end up being a mess. It is also a good long-term solution, as long-term, people
might want to use only a quantum-resistant KEM such as ML-KEM.
We would also like to be able to use ML-DSA for authentication in IKEv2. Is
there any draft-xxx-ml-dsa-ikev2, otherwise it should be written asap. I am
happy to help.
https://datatracker.ietf.org/doc/draft-ietf-lamps-dilithium-certificates/
Comments of the draft:
- “Post-quantum”
I think the draft should remove “post-quantum” and only use the term
“quantum-resistant”, this aligns with draft-ietf-lamps-dilithium-certificates,
draft-gazdag-x509-slhdsa, and CNSA 2.0. “Post-quantum” is quite a strange term
as ML-KEM needs to be deployed way before CRQCs are built.
- “As post-quantum keys are usually larger than common network Maximum
Transport Units (MTU)“
“usually” depends on your sample of algorithms and security categories. As the
ciphertext is not a key, I think it would be good to talk about encapsulation
keys and ciphertexts, which aligns with FIPS 203. The encapsulation keys and
ciphertexts in ML-KEM-512 and ML-KEM-768 are smaller than the typical Internet
MTU. Also, it is the packet size carrying the encapsulation key or ciphertext
that matters, not just the key ciphertext sizes themselves.
- “ML-KEM-768 and ML-KEM-1024 public keys and ciphertexts can exceed typical
network MTUs (1500 bytes).
ML-KEM-768 encapsulation keys and ciphertexts are smaller than 1500 bytes. The
word "can" is weird as the sizes are fixed. Should probably talk about packets.
- “Thus, ML-KEM-1024 Key Exchange Method identifier TBD37 SHOULD only be used
in IKE_INTERMEDIATE exchanges. It SHOULD NOT be used in IKE_FOLLOWUP_KE
messages until there is a separate document which defines how such exchanges
are split in several messages.”
I think this should be rewritten to say that ML-KEM-1024 should only be used in
IKE_SA_INIT when it is known that the network MTU is large. There is no reason
to discourage use of ML-KEM-1024 in networks that use 9000 bytes ethernet jumbo
frames.
- “which generates a public key 'pk' and a secret key 'sk'.”
I think the document should align with FIPS 203, which calls them encapsulation
key and decapsulation key.
- “Otherwise keep a normative reference of [FIPS203].”
I think FIPS203 should be the normative reference no matter what.
- " which will not have material performance impact on IKEv2/IPsec tunnels
which usually stay up for long periods of time."
Not sure that long-lived tunnels are so relevant as best practice is to rekey
with PFS based on both time and data (ANSSI says 1 hour or 100 GB).
https://cyber.gouv.fr/sites/default/files/2015/09/NT_IPsec_EN.pdf<https://protect2.fireeye.com/v1/url?k=31323334-501d5122-313273af-454445555731-95d074f1e17afe43&q=1&e=30ba9ee6-2c65-4802-93bf-168b293e474c&u=https%3A%2F%2Fcyber.gouv.fr%2Fsites%2Fdefault%2Ffiles%2F2015%2F09%2FNT_IPsec_EN.pdf>
I think the document should stress how fast ML-KEM is. On a single core AMD
Ryzen 5 5560U [17], a mobile CPU from 2021, the cryptographic operations in
ML-KEM takes 12 μs for the initiator and 8 μs for the responder. The key
generation can be pre-computed, reducing the time required for real-time
cryptographic operations to 6 μs for the initiator and 8 μs for the responder.
https://bench.cr.yp.to/results-kem.html<https://protect2.fireeye.com/v1/url?k=31323334-501d5122-313273af-454445555731-84e6e00fe0aa2d3c&q=1&e=30ba9ee6-2c65-4802-93bf-168b293e474c&u=https%3A%2F%2Fbench.cr.yp.to%2Fresults-kem.html>
- “Consider adding ML-KEM-512 which would fit in one packet.”
I strongly think this document should just register all variant in FIPS 203.
NIST latest assessment is that “the most plausible values for the practical
security of Kyber512 against known attacks are significantly higher than that
of AES128”. Ericsson agrees with that assessment and so do Sophie Schmieg
(Google).
https://csrc.nist.gov/csrc/media/Projects/post-quantum-cryptography/documents/faq/Kyber-512-FAQ.pdf
https://keymaterial.net/2023/11/18/kyber512s-security-level/<https://protect2.fireeye.com/v1/url?k=31323334-501d5122-313273af-454445555731-932138c3cd478641&q=1&e=30ba9ee6-2c65-4802-93bf-168b293e474c&u=https%3A%2F%2Fkeymaterial.net%2F2023%2F11%2F18%2Fkyber512s-security-level%2F>
- “The ML-KEM-768 public key is 1184 bytes”
I think it would be good with a table that shows the encapsulation key and
ciphertext sizes for ML-KEM-512, ML-KEM-768, and ML-KEM-1024.
- “Although ML-KEM is IND-CCA2 secure, reusing the same ML-KEM keypair does not
offer forward secrecy.”
I strongly think IPsec should continue to use the term "perfect forward
secrecy", this aligns with RFC 4949, RFC 7296 and most government documents
talking about ephemeral key exchange in IKEv2. The TLS 1.3 use of "forward
secrecy" for both ephemeral key exchange and symmetric ratcheting has had the
unfortunate result that people think they get the same security properties from
both, which is absolutely not the case.
- “The initiator should generate a new ML-KEM keypair with every ML-KEM key
exchange.”
I think this should be a MUST. On a single core AMD Ryzen 5 5560U [17], a
mobile CPU from 2021, key generation with ML-KEM-512 takes the initiator 6
microsecond. Reuse was needed with the very slow FFDH key exchange on old CPUs
of the past. Forbidding reuse significantly simplifies the security analysis.
Cheers,
John Preuß Mattsson
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
