Usama (and all),
I am no chair, but an observer offering a perspective. I know the topic is hot
now, but I’m hoping that this dwindles flame rather than increases it.
Your main technical complaint if I’m not mistaken is that a document that is
intended for ml-dsa only should reference a hybrid approach.
I don’t know that this is an accurate approach none of the rest of the document
references hybrids in any way. Just as when ECDSA was added to TLS (RFC 5246)
there was no reference to any “hybrid” approach (I.e. no, let’s do ECDSA + RSA
just in case).
I do think the point of this RFC is simply to register some new code points for
the use of ml-dsa standalone (which if there’s no agreement that it can’t be
standalone I don’t know how we could possibly agree on a hybrid).
Algorithms thus far have never had to be combined, except for worries which
people have.
Let me paint a mental picture, if I need to have composite algorithm x, and
algorithm x is comprised of algorithms y and z, then I first need standalone
implementations of algorithms y and z before I can have algorithm x. So why in
the world would we not have algorithms y and z both be a part of the protocol
before having algorithm x added? It feels completely backwards.
Yes, have the ml-dsa standalone. Create an I-D with your suggestions on the
signature schemes we would want to add to the registry. And there (hopefully)
the lamps document can be finalized and rather than referencing an I-D you can
reference both the standlone ml-dsa, and the lamps pq-composite RFC, and
discuss why someone would want a composite rather than a standalone algorithm.
Thank you,
Ryan Appel
> On May 6, 2026, at 5:35 AM, Stephen Farrell <[email protected]> wrote:
>
>
> Hiya,
>
>> On 06/05/2026 11:31, Peter C wrote:
>> I don’t think you can point at an informative section motivating
>> the use of hybrid ML-DSA in one draft and claim that it blocks
>> the use of non-hybrid ML-DSA everywhere else, particularly
>> when there is already a published RFC for non-hybrid ML-DSA
>> from the same working group with the same use case [1].
>
> We (the IETF as a whole) are indeed all over the place
> when it comes to documenting PQ things;-(
>
> I feel sorry for people who have to try figure out what
> to implement and deploy.
>
> S.
>
> _______________________________________________
> TLS mailing list -- [email protected]
> To unsubscribe send an email to [email protected]
> <OpenPGP_signature.asc>
_______________________________________________
TLS mailing list -- [email protected]
To unsubscribe send an email to [email protected]
