> -----Original Message-----
> From: Paul Wouters <p...@nohats.ca>
> Sent: Monday, February 3, 2025 3:07 PM
> To: Scott Fluhrer (sfluhrer) <sfluh...@cisco.com>
> Cc: ipsec@ietf.org
> Subject: Re: [IPsec] FW: New Version Notification for draft-sfluhrer-ipsecme-
> ikev2-mldsa-00.txt
>
> On Fri, 31 Jan 2025, Scott Fluhrer (sfluhrer) wrote:
>
> [ speaking as indidivual ]
>
> > I just noticed that IKE was missing a draft to how to support pure (ML-DSA
> only) PQ authentication, so I threw this together.
> >
> > Any comments are fine (and I expect them to range from "this is
> > completely stupid" to "this is mostly stupid, but it might be
> > salvageable")
>
> I think there are some very PQ generic parts of this document, and very little
> ML-DSA specific. I would prefer a generic document on how to do PQ AUTH.
> But also, ...
There are some ML-DSA parts:
- The acknowledgement that ML-DSA has prehashed parameter sets, and
that we are specifically not using them
- That we are using a fixed context string
- The note about deterministic vs hedged implementations (and that we
don't care)
But yes, most of it is not ML-DSA specific, but generic to any signature method
which is not 'straight-hash-and-sign'
>
> I am not sure what this document is documenting that is not already obvious
> from the existing RFCs? a PRF.
Well, based on the existing RFCs, there are multiple ways of doing this (and
hence we need to have something which says "this is the way for ML-DSA"). In
addition to the approach I suggested, we have RFC 8420 (EdDSA), which also
isn't 'straight-hash-and-sign'. Now, if the working group decides the RFC 8420
approach is the way to go, I have no problem with that.
My aim was to spell out an approach that would fit the cleanest into the
existing architecture and implementations. Now, if people who have existing
implementations disagree (and for example, say the RFC 8420 way of doing things
is better), I'll change things.
>
> I am not sure why SUPPORTED_AUTH_METHODS is mandatory. If sending a
> CERTREQ hash of the PQ Root CA, wouldn't all cipher information already
> been known if the peer accepts the same PQ Root CA?
I was looking for a standard way to declare 'I support ML-DSA-87';
SUPPORTED_AUTH_METHODS appear to be the standard way to tell that to the peer.
Now, if you're saying that the standard way is "if you specify the CERTREQ from
a specific root CA, the peer already knows that you support the public keys
that the root CA has signed", then fine, I can remove the text around
SUPPORTED_AUTH_METHODS.
> The normal case for
> IKE X.509 based authentication assumes the CA and EE algorithms are the
> same. So while you can use SUPPORTED_AUTH_METHODS to indicate
> something different (eg ML-DSA-44 for EE certs when CA uses ML-DSA-87?)
> this seems unlikely in practise (and I wouldn't mind making it impossible to
> do)
Actually, I don't think it improbable that some CAs may end up using FN-DSA
signatures (after FN-DSA is defined) for the root CAs (they're smaller, and CAs
don't care about side channel attacks), while the public keys be ML-DSA keys
(because end devices do care about side channel attacks); will doing a CERTREQ
for such a CA automatically imply support for FN-DSA and ML-DSA?
>
> I see that RFC 7427 kind of assumes flexibility of using
> SIGNATURE_HASH_ALGORITHMS instead of deducing it based on the SPKI.
>
> Do we need a new entry for Pseudorandom Function Transform IDs for SHA3
> to be able to signal using it with ML-DSA?
I do not believe so. The use of SHA3 (SHAKE, actually) is internal to ML-DSA,
and we don't need to specifically say that.
_______________________________________________
IPsec mailing list -- ipsec@ietf.org
To unsubscribe send an email to ipsec-le...@ietf.org
