[TLS] Re: [EXT] Re: Complaint to chairs regarding false claim of consensus to issue an RFC for draft-ietf-tls-mldsa

[Ryan Appel <[e-mail]>]

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 <[e-mail]> 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 -- [e-mail]
> To unsubscribe send an email to [e-mail]
> <OpenPGP_signature.asc>