[TLS] Re: [EXTERNAL] Attestation and request for expediting the call for adoption of draft-reddy-tls-composite-mldsa

[Eric Rescorla <[e-mail]>]

On Mon, Apr 13, 2026 at 11:44 PM Scott Fluhrer (sfluhrer) <
[e-mail]> wrote:

> 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).
>

I think this is the right answer. From the TLS perspective the signature
algorithm is an opaque function, and so I think the text here mostly just
confuses people. Also, I think it's better to just define the composite
algorithm in one place.

-Ekr




>
> ------------------------------
> *From:* Eric Rescorla <[e-mail]>
> *Sent:* Monday, April 13, 2026 6:20 PM
> *To:* Andrei Popov <Andrei.Popov=[e-mail]>
> *Cc:* Muhammad Usama Sardar <[e-mail]>;
> [e-mail] <[e-mail]>;
> [e-mail] <
> [e-mail]>; [e-mail] <[e-mail]>
> *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 <Andrei.Popov=
> [e-mail]> 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 <[e-mail]>
> Sent: Monday, April 13, 2026 2:20 AM
> To: [e-mail]; [e-mail]
> Cc: [e-mail]
> 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 -- [e-mail]
> To unsubscribe send an email to [e-mail]
>
>