Hi Scott,
Good starting draft. I would support adoption if there was a call sometime
later.
I agree on using Pure mode, adding a context string (of little value
admittedly) and hashing the signer octets.
There needs to be a mention of fragmentation which will occur for sure for
these messages (not that it will be a problem). And a rough mention of the
sizes they will be with ML-DSA which will be much higher than ECDSA, but does
not really matter for this use-case.
And I also suggest to add text will like other drafts that recommends that the
size of the hash function needs to be at least double the security level of the
ML-DSA parameter. The CMS drafts have text like that. And should you add a
mandatory-to-implement for the hash function, like SHA2 that is prevalent?
Should the signature sign more that than IKE_SA_INIT signed octets if the key
exchange includes additional KEs in IKE_INTERMEDIATE messages for ML-KEM-768 or
1024?
Rgs,
Panos
-----Original Message-----
From: Scott Fluhrer (sfluhrer) <sfluhrer=40cisco....@dmarc.ietf.org>
Sent: Monday, February 3, 2025 4:13 PM
To: Paul Wouters <p...@nohats.ca>
Cc: ipsec@ietf.org
Subject: [EXTERNAL] [IPsec] Re: FW: New Version Notification for
draft-sfluhrer-ipsecme-ikev2-mldsa-00.txt
CAUTION: This email originated from outside of the organization. Do not click
links or open attachments unless you can confirm the sender and know the
content is safe.
> -----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
_______________________________________________
IPsec mailing list -- ipsec@ietf.org
To unsubscribe send an email to ipsec-le...@ietf.org
