Obviously, this could have been phrased better.
What TLS signs is, in fact, exactly what it signs with any other signature
algorithm (RSA, ECDSA, etc), except that the "hash function" is implicit
(rather than being explicitly defined in the SignatureScheme code point). So,
as far as TLS is concerned, it looks like any other signature algorithm.
Now, if we go into how that signature algorithm works, it does some preliminary
hashing, including some data that indicates the precise combination of PQ and
conventional components we're using. I could go on and talk about why we do
that (rather than the obvious "just hand the message being signed to both RSA
and ML-DSA to sign"), but I don't expect you care.
Obviously, if an intelligent reader (such as you) finds it confusing, the text
needs to be reworked. I'll need to discuss it with my coauthors; my first
impulse would be to remove the second paragraph ("In composite ML-DSA
schemes...") entirely, and instead refer the reader to the composite PKI draft
(soon to be RFC, we hope) if they care about the details (which TLS
implementors shouldn't have to).
________________________________
From: Eric Rescorla <[email protected]>
Sent: Monday, April 13, 2026 6:20 PM
To: Andrei Popov <[email protected]>
Cc: Muhammad Usama Sardar <[email protected]>;
[email protected] <[email protected]>;
[email protected]
<[email protected]>; [email protected] <[email protected]>
Subject: Re: [TLS] Re: [EXTERNAL] Attestation and request for expediting the
call for adoption of draft-reddy-tls-composite-mldsa
Document: draft-reddy-tls-composite-mldsa-09.txt
Unlike traditional TLS signature schemes such as RSA or ECDSA, TLS
does not apply or select a hash function when using Composite ML-DSA.
Composite ML-DSA is treated as an opaque signature algorithm, similar
to Ed25519 and Ed448, which are specified in TLS 1.3 as "PureEdDSA"
algorithms (Section 4.2.3 of [RFC8446]). Any hash functions used as
part of the composite signature construction are fully determined by
the composite algorithm associated with the negotiated TLS
SignatureScheme and are internal to the Composite ML-DSA algorithm.
In composite ML-DSA schemes, the trailing portion of the
SignatureScheme name identifies the traditional signature algorithm
used as part of the composite construction. This identification is
for algorithm selection and interoperability purposes only and does
not imply any TLS-level processing of the traditional component.
What is this text trying to say? It seems like you're saying you're not
signing the same value as TLS normally does, containing the transcript
hash, but that doesn't seem to be the case.
When a composite ML-DSA signature scheme defined in this document is
negotiated, the TLS 1.3 CertificateVerify signing input constructed
as specified in Section 4.4.3 of [RFC8446] is signed using the
negotiated composite ML-DSA SignatureScheme, as specified in
[I-D.ietf-lamps-pq-composite-sigs].
I also don't understand what it means to say
Unlike traditional TLS signature schemes such as RSA or ECDSA, TLS
does not apply or select a hash function when using Composite ML-DSA.
And then to have the hash algorithms defined as part of the scheme;
that sure seems like you're selecting a hash algorithm.
How is this different from (say) ECDSA.
S 3.
TLS 1.3 removed support for RSASSA-PKCS1-v1_5 [RFC8017] in
CertificateVerify messages, opting for RSASSA-PSS instead.
Similarly, this document restricts the use of the composite signature
algorithms mldsa44_rsa2048_pkcs15_sha256,
mldsa65_rsa3072_pkcs15_sha512, and mldsa65_rsa4096_pkcs15_sha512
algorithms to the "signature_algorithms_cert" extension. These
composite signature algorithms MUST NOT be used with the
"signature_algorithms" extension. These values refer solely to
signatures which appear in certificates (see Section 4.4.2.2 of
[RFC8446]) and are not defined for use in signed TLS handshake
messages.
Is there any evidence that there will ever be composite signatures
with PKCS#1.5, even in certificates?
S 4.
* Is compatible with traditional digital signatures recommended in
TLS 1.3, ensuring interoperability and ease of adoption within the
TLS ecosystem.
How is this interoperable? As far as the implementation is concerned,
this is a new algorithm, no?
-Ekr
On Mon, Apr 13, 2026 at 10:02 AM Andrei Popov
<[email protected]<mailto:[email protected]>>
wrote:
+1. I would support adoption of draft-reddy-tls-composite-mldsa; would like to
implement in the Windows TLS/PKI stacks.
Cheers,
Andrei
-----Original Message-----
From: Muhammad Usama Sardar
<[email protected]<mailto:[email protected]>>
Sent: Monday, April 13, 2026 2:20 AM
To: [email protected]<mailto:[email protected]>;
[email protected]<mailto:[email protected]>
Cc: [email protected]<mailto:[email protected]>
Subject: [EXTERNAL] [TLS] Attestation and request for expediting the call for
adoption of draft-reddy-tls-composite-mldsa
Dear Deirdre, Joe, and Sean,
I would like to attest to this work and request you to please expedite the call
for adoption of the subject draft.
Thank you.
---
Hi authors,
Thank you for the great work. Please let me know whatever I can do in my
capacity in order to make it adoption-ready.
One request I have is to revisit the selection criteria (sec. 4) and may try to
shortlist and reduce the number of algorithms. I believe so many algorithms may
lead to fragmentation. Thank you.
Best regards,
-Usama
_______________________________________________
TLS mailing list -- [email protected]<mailto:[email protected]>
To unsubscribe send an email to [email protected]<mailto:[email protected]>
_______________________________________________
TLS mailing list -- [email protected]
To unsubscribe send an email to [email protected]
