[lamps] Re: Mohamed Boucadair's Discuss on draft-ietf-lamps-pq-composite-sigs-15: (with DISCUSS and COMMENT)

[[e-mail]]

Hi Mike,

Thank you for the follow-up. I also checked https://author-tools.ietf.org/iddiff?url1=draft-ietf-lamps-pq-composite-sigs-15&url2=draft-ietf-lamps-pq-composite-sigs-18&difftype=--html

The changes look good to me. Please see inline for some few points.

I will clear my DISCUSS independent of whether you decide to make further changes.

Cheers,
Med

De : Mike Ounsworth <[e-mail]>
Envoyé : mercredi 8 avril 2026 10:12
À : BOUCADAIR Mohamed INNOV/NET <[e-mail]>
Cc : The IESG <[e-mail]>; [e-mail]; [e-mail]; [e-mail]; [e-mail]
Objet : Re: [lamps] Mohamed Boucadair's Discuss on draft-ietf-lamps-pq-composite-sigs-15: (with DISCUSS and COMMENT)


Hi Med,

Thank you for your very detailed review! You got well into the details of this complex draft!

And thank you also for the very detailed editorial PR: https://github.com/lamps-wg/draft-composite-sigs/pull/345

I have addressed many of your points in a PR here, which I will discuss with my co-authors before merging.
https://github.com/lamps-wg/draft-composite-sigs/pull/347
[Med] Thanks.


The points tat I did not make any changes for are discussed below:



> Section 2 says the following:
>   This specification assumes a seed-based keygen for ML-DSA.
>
> Maybe I'm misreading this, but is this saying that only the seed mode is
> supported? If so, isn't that a deviating from 9881 where expandedKey is allowed?

You are not misreading that. There was extensive debate in the WG on this point and the WG was very clear not to download the {seed, expanded, both} mess into composites. It is not uncommon for one RFC to profile another one; IE to take only a subset of the features from the other RFC. So I think it's "profiling 9881" not "deviating from 9881". Also note that since Composite-ML-DSA is a distinct algorithm from ML-DSA with distinct object identifiers and distinct key encodings anyway, it's only a spiritual difference at best.

[Med] Thank you for confirming that I was not hallucinating :-) Great to see this is an informed decision from the WG. So, all is set for me ... except maybe that I would prefer if this is stated clearing in the document, but I leave that to you to decide.

> ## Unless there is a need to deviate from RFC9794, I would suggest to rely on
> the terms/definitions in RFC9794 (and make that RFC as normative) and only
> define here new terms not listed in RFC9794.

First, RFC9794 is Informational, so a Normative ref will cause DOWNREF problems. And a Normative ref to a terminology doc seems weird.
[Med] It isn't weird as I expect 9794 to end in the downref at some point. Please note that having a doc in downref is not a disaster, it is just an admin thing.

The idea here was to copy in the definitions that are really important to the core understanding of this draft rather than making readers document-hop. I'll fix the one that does not match exactly. Good eyes!
[Med] I think the issue is fixed in your PR with "Some relevant definitions from {{RFC9794}} are copied here for easier reading" and aligning the definition. Thanks.

> # Given the side-channel implication, any reason why this isn't a MUST?
>
> CURRENT:
>    Note that in step 4 above, both component signature processes are
>    invoked, and no indication is given about which one failed.  This
>    SHOULD be done in a timing-invariant way to prevent side-channel
>    attackers from learning which component algorithm failed.

There are lots of cryptographic implementations in the world where a timing side-channel like this does not lead to any practical security issue; for example if you're using local TPM where you assume that an attacker does not have direct access. And more generally, full side-channel resistance is really really difficult to attain, especially in a software library. Most of the time, if the underlying component primitive aborts early, that itself is already a timing difference that you will not be able to mask at the composite layer. So turning this SHOULD into a MUST would make like 98% of implementations non-conformant. We actually debated in the WG going the other way and just removing this note entirely since it's a bit of an un-obtainable requirement, but in the end it stayed in as a SHOULD in case it ends up being helpful to someone.

[Med] Thanks for sharing the background.


> CURRENT:
>    *PROTOCOL BACKWARDS COMPATIBILITY*: A property whereby a new feature
>    can be added to a protocol without requiring any changes to the
>    protocol's specification and only minimal changes to its
>    implementations (such as adding new identifiers).
>
> Adding a new feature is a change per se!

I'm gonna disagree with that. I am going to argue that adding an extension to a point in a protocol that is designed to take future extensions is not "changing the protocol".
For example, the TLS 1.3 protocol is agnostic to the actual ciphers it uses, so RFC8998 is able to add the Chinese national ciphers to TLS 1.3 in exactly this way -- without even needing to consult the TLS WG in fact! That's protocol backwards compatibility working well!

[Med] OK


> ### Can we please update this definition to better reflect the intended
> property?

I have adjusted this slightly by adding this sentence. Is that better?

"Typically this means that the new feature fits within a defined
extension point of the protocol instead of requiring a structural
change to the protocol."

[Med] Thanks.


> ### Do we need this term at the first place? This is only mentioned once with
> self-contained context.



> CURRENT:
>    Note that while the overall construction of Composite ML-DSA is
>    similar to that of HashML-DSA, the ML-DSA component inside the
>    composite is "pure" ML-DSA; implementing this specification does not
>    require an implementation of HashML-DSA.
>
> Shouldn't this be more explicit that HashML-DSA is disallowed per the same
> rationale as in rfc9881#section-8.3?

So, RFC9881 is saying that while HashML-DSA has registered OIDs, and could structurally fit within X.509, RFC9881 is saying that that would not be considered valid X.509.

Here I don't think we need to do that with composites because if you swapped out the ML-DSA within a composite for HashML-DSA, you would end up with a different and incompatible algorithm that doesn't pass the test vectors.
There's a near-infinite set of algorithm combinations that are not specified in this document but someone could well do, like composites with Chinese or Russian ciphers, or with other PQ algs.
My personal opinion is that it would be weird for a document like this to have an opinion on things that are not specified in this document.

[Med] ACK


> # Section 3.1
>
> CURRENT:
>    Errors produced by the component KeyGen() routines MUST be forwarded
>    on to the calling application.
>
> I don't understand the use of "forwarded" in this context? Isn't the API call
> internal within a system?

I'm trying to conjure the idea of exception chaining. Like the composite implementation should not swallow the error, but if the inner API throws an error then the composite should throw the same error.

Would the word "MUST be propagated" be better? Maybe I should use more words? How about this?

NEW:
  If one of the component `KeyGen()` routines returns an error, then this error MUST be propagated by the `Composite-ML-DSA.KeyGen()` routine.
[Med] This is better, thanks.


> # Section 3.1.1: Modified process and implications
>
> CURRENT:
>    In cases where it is desirable to have a deterministic KeyGen of one
>    or both component keys from a seed, this process MAY be modified to
>    expose an interface of Composite-ML-DSA<OID>.KeyGen(seed) such that
>    one component algorithm is generated from the seed and the other from
>    random, or the input seed is cryptographically expanded to produce
>    seeds for both components.  Implementation details and security
>    analysis of such a modified key generation process is outside the
>    scope of this document.
>
> Shouldn't this need be highlighted in the SEC or OPS cons section so that
> appropriate analysis in done before making use of a modified process?

Yeah. You're making a valid point, but I'm not sure what we could say that's helpful. I mean, it's true for all RFCs that if you implement something different than what's in the RFC, then the security analysis may or may not apply. Do you have specific text in mind?

[Med] Moving this to a separate sub-section on the ops consideration section would give it more visibility for those who will deploy.

> ## Inherit ML-DSA Operational Considerations
>
> There are important considerations that are inherited by the composite design.
> Can we please add a note to increase awareness about considerations listed in
> rfc9881#section-8?

So, 8.1 and 8.2 don't apply because we're not inheriting the whole {seed, expanded, both} mess.
8.3 also doesn't apply because a HashML-DSA composite would be something different and incompatible with the things specified here, so I don't think we need to say anything about it at all.

So I actually don't think we are inheriting any of the operation considerations from RFC 9881; I think we have successfully profiled down how ML-DSA is used to make all three of those problems go away.

[Med] ACK.

> ## Hidden Operational Consideration
>
> Section 1.3:
>    Composite ML-DSA is NOT RECOMMENDED for use in
>    applications where it is has not been shown that EUF-CMA is
>    acceptable.
>
> This reco is IMO hidden in the introduction part. Given the importance of this
> reco for those who will deploy, I suggest we have this more visible as part of
> the OPS Considerations section.

This is the subject of the entire Security Consideration 9.2. Do we really need to duplicate it into an OPS Con?

Also please be aware that the EUF-CMA vs SUF-CMA thing is a political hand-grenade. It took us almost 2 months at the WG to agree on the EUF-CMA text that's in there currently. I personally have never come across a practical deployment where EUF-CMA is not acceptable (ie where SUF-CMA is required). So I personally don't think it is important, and I am not capable of writing the OPS Con you're asking for because I literally don't know what kind of deployment would need that. I'm really hesitant to re-open this can of worms.

[Med] No need to open then ;-) I'm fine with the explanation you provided.

On Tue, 31 Mar 2026 at 04:08, Mohamed Boucadair via Datatracker <[e-mail]<mailto:[e-mail]>> wrote:
Mohamed Boucadair has entered the following ballot position for
draft-ietf-lamps-pq-composite-sigs-15: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-lamps-pq-composite-sigs/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

Hi Mike, John, Massimiliano, Jan, and Scott,

Thank you for the effort put into this specification. The document reads well
... even for an OPS AD :-)

I trust that the test vectors, in particular, were checked by WG participants
other than the authors.

Please find below some comments below. I also flagged some nits and other minor
edits that I will send in a PR for authors convenience.

# ML-DSA is normative for composite ML-DSA

CURRENT:
   Composite ML-DSA is a Post-Quantum / Traditional hybrid signature
   scheme which combines ML-DSA as specified in [FIPS.204] and [RFC9881]

   ...

   As this specification uses ML-DSA as a component of all composite
   algorithms, all security considerations from [RFC9881] apply.

Please move RFC9881 from Informative to Normative.

## As I'm there, I'd like to check one related part:

Section 2 says the following:
  This specification assumes a seed-based keygen for ML-DSA.

Maybe I'm misreading this, but is this saying that only the seed mode is
supported? If so, isn't that a deviating from 9881 where expandedKey is allowed?

# Terminology: I'm adding this as a DISCUSS point as I think this is important
to ensure consistency among specs in this area

Section 2:
   This specification is consistent with the terminology defined in
   [RFC9794].  In addition, the following terminology is used throughout
   this specification:

I interpret this as the terms that follow are not listed in RFC9794 but are an
addition. However, it is not clear to me the rationale followed here. For
example,

## we do have this entry grabbed from RFC9794 with an explicit pointer to that
RFC:

   *COMPOSITE CRYPTOGRAPHIC ELEMENT*: [RFC9794] defines composites as: A
   cryptographic element that incorporates multiple component
   cryptographic elements of the same type in a multi-algorithm scheme.

The citation does not match exactly the entry as defined in 9794:

      A cryptographic element that incorporates multiple component
      cryptographic elements of the same type for use in a multi-
      algorithm scheme, such that the resulting composite cryptographic
      element is exposed as a singular interface of the same type as the
      component cryptographic elements.

## ... and this one which is already defined in RFC9794 but repeated here

   *POST-QUANTUM TRADITIONAL (PQ/T) HYBRID SCHEME*: A multi-algorithm
   scheme where at least one component algorithm is a post-quantum
   algorithm and at least one is a traditional algorithm.

## Unless there is a need to deviate from RFC9794, I would suggest to rely on
the terms/definitions in RFC9794 (and make that RFC as normative) and only
define here new terms not listed in RFC9794.

# Given the side-channel implication, any reason why this isn't a MUST?

CURRENT:
   Note that in step 4 above, both component signature processes are
   invoked, and no indication is given about which one failed.  This
   SHOULD be done in a timing-invariant way to prevent side-channel
   attackers from learning which component algorithm failed.


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

# Abstract: regional requirement, not an absolute one

OLD:
   These combinations are tailored to meet regulatory
   guidelines.

NEW:
   These combinations are tailored to meet regulatory
   Guidelines in certain regions.

# Backward compatibility

## Usual

CURRENT:
   *APPLICATION BACKWARDS COMPATIBILITY*: The usual definition of
   backwards compatibility, meaning whether an upgraded and non-upgraded
   application can successfully establish communication.

### If this is usual definition, then do we need to have a dedicated entry for
it here?

### I suggest

NEW:
   *APPLICATION BACKWARDS COMPATIBILITY*: A property indicating whether an
   upgraded and non-upgraded application can successfully establish
   communication.

## Section 10.2 has the following:

   The term "application backwards compatibility" is used here to mean
   that existing systems as they are deployed today can interoperate
   with the upgraded systems of the future.

Why the definition is repeated here? is there any difference between the intent
here and the relevant entry in Section 1.1?

Unless there is subtlety there, I suggest to delete that text as it is
redundant with the terminology section.

## I don't parse the following:

CURRENT:
   *PROTOCOL BACKWARDS COMPATIBILITY*: A property whereby a new feature
   can be added to a protocol without requiring any changes to the
   protocol's specification and only minimal changes to its
   implementations (such as adding new identifiers).

Adding a new feature is a change per se!

### Can we please update this definition to better reflect the intended
property?

### Do we need this term at the first place? This is only mentioned once with
self-contained context.

## Internal inconsistency

Section 1:
   Backwards compatibility in the sense of upgraded systems continuing
   to interoperate with legacy systems is not directly covered in this
   specification, but is the subject of Section 10.2.

I'm having troubles to digest the intent of this sentence as it conveys
conflicting messages (at least for me).

## If the intent is to say that backward compatibility is not ensured then
maybe reword to, e.g.:

NEW:
   Backwards compatibility in the sense of upgraded systems continuing
   to interoperate with legacy systems is not directly covered in this
   specification. Refer to Section 10.2 for more details.

# Notations

Can we please add "->" to the list of notations?

# Section 2.1: Broken reference

CURRENT:
   Given this design of Composite ML-DSA, it is possible to split the
   pre-hashing step out from the signature generation process -- see
   {#impl-cons-external-ph} for further discussion and sample
   algorithms.

# Section 2.1: HashML-DSA

CURRENT:
   Note that while the overall construction of Composite ML-DSA is
   similar to that of HashML-DSA, the ML-DSA component inside the
   composite is "pure" ML-DSA; implementing this specification does not
   require an implementation of HashML-DSA.

Shouldn't this be more explicit that HashML-DSA is disallowed per the same
rationale as in rfc9881#section-8.3?

# Section 3.1

CURRENT:
   Errors produced by the component KeyGen() routines MUST be forwarded
   on to the calling application.

I don't understand the use of "forwarded" in this context? Isn't the API call
internal within a system?

Maybe s/forwarded on/communicated?

# Section 3.1.1: Modified process and implications

CURRENT:
   In cases where it is desirable to have a deterministic KeyGen of one
   or both component keys from a seed, this process MAY be modified to
   expose an interface of Composite-ML-DSA<OID>.KeyGen(seed) such that
   one component algorithm is generated from the seed and the other from
   random, or the input seed is cryptographically expanded to produce
   seeds for both components.  Implementation details and security
   analysis of such a modified key generation process is outside the
   scope of this document.

Shouldn't this need be highlighted in the SEC or OPS cons section so that
appropriate analysis in done before making use of a modified process?

# Section 4: Table 1

Can we please add a pointer to Section 4 of FIPS.204 to indicate the source of
that table?

# Section 6: Obvious

CURRENT:
   Labels are represented here as ASCII strings, but implementers MUST
   convert them to byte strings using the obvious ASCII conversions
   prior to concatenating them with other byte values as described in
   Section 2.2.

do we need to keep "obvious" here? If it was, then why calling it out :-)

# Section 6: Key sizes

CURRENT:
   For all RSA key types and sizes, the exponent is RECOMMENDED to be
   65537.  Implementations MAY support only 65537 and reject other
   exponent values.  Legacy RSA implementations that use other values
   for the exponent MAY be used within a composite, but need to be
   careful when interoperating with other implementations.

Given the interoperability issues there, I suggest to add relevant operational
considerations under the OPS Cons section to cover at least the following:

* Implems need to expose which sizes they support
* Implems need to offer a configuration knob to control the size.

# Section 10: Operational Considerations

## I suggest to rename "Implementation Considerations" to "Operational
Considerations" as that section is more about operational guidance. This would
be also consistent with the approach in 9881.

## Inherit ML-DSA Operational Considerations

There are important considerations that are inherited by the composite design.
Can we please add a note to increase awareness about considerations listed in
rfc9881#section-8?

## Hidden Operational Consideration

Section 1.3:
   Composite ML-DSA is NOT RECOMMENDED for use in
   applications where it is has not been shown that EUF-CMA is
   acceptable.

This reco is IMO hidden in the introduction part. Given the importance of this
reco for those who will deploy, I suggest we have this more visible as part of
the OPS Considerations section.

Hope this helps.

Cheers,
Med



_______________________________________________
Spasm mailing list -- [e-mail]<mailto:[e-mail]>
To unsubscribe send an email to [e-mail]<mailto:[e-mail]>
____________________________________________________________________________________________________________
Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.