[Ssh] Re: Supporting pure ML-DSA as hostkey and authkey

["Scott Fluhrer (sfluhrer)" <[e-mail]>]

I would agree; the actual message signed by SSH would appear to be unusable in any other context.  And, I also agree that if the working group feels otherwise, a nontrivial context string (e.g. "SSH") would be reasonable.

On the other hand, if we look at the use of ML-DSA within composite signatures (https://datatracker.ietf.org/doc/draft-ietf-lamps-pq-composite-sigs/ ), it indeed includes a nonempty context string to the lower-level ML-DSA implementation.  Hence, nonempty ML-DSA context strings are not unknown.
________________________________
From: Appel, Ryan <ryan.appel=[e-mail]>
Sent: Tuesday, April 28, 2026 11:07 AM
To: Damien Miller <[e-mail]>; Watson Ladd <[e-mail]>
Cc: [e-mail] <[e-mail]>
Subject: [Ssh] Re: Supporting pure ML-DSA as hostkey and authkey

I don’t want to speak on behalf of Mr. Fluhrer, but as far as I’ve seen, no other proposed IETF adoption of ML-DSA (IPsec, TLS) has used the context string, this is generally because there’s other context around the signature for its use.

The ssh protocol similarly constructed with different messages for user authentication vs host authentication.

If the request for the use of the context string within ml-dsa to be used as a domain separator however, it’s worth discussion.


Thank you,



Ryan Appel, MS, BCS



________________________________
From: Damien Miller <[e-mail]>
Sent: Monday, April 27, 2026 6:38:18 PM
To: Watson Ladd <[e-mail]>
Cc: [e-mail] <[e-mail]>
Subject: [Ssh] Re: Supporting pure ML-DSA as hostkey and authkey

On Mon, 27 Apr 2026, Watson Ladd wrote:

> > FWIW I have a test implementation of hybrid ML-DSA 65 / Ed25519 for
> > OpenSSH using the draft-ietf-lamps-pq-composite-sigs construction
> > and was planning on writing it up as an I-D is anyone is interested.
> >
> > https://urldefense.com/v3/__https://github.com/djmdjm/openssh-portable-wip/pull/11__;!!I2XIyG2ANlwasLbx!TC-fu3R8CGFyUVVAR2W_in1gLjJoX-0qbEYaVlv2VHH3F8MakdlwM2zbvKHAIJ8MXpl6osknuZVr$
>
> I don't want to drag us down the composite rabbit hole but short PQ
> timelines and the nature of authentication make me less interested.

Basing this on an document that is in the RFC editor queue as opposed
to one of the other myriad constructions was an attempt to step over
the rabbit hole as much as possible.

IMO, the increased urgency for deployment of PQ sig algs (I have seen
requests for by-default deployment in 2028) *heightens* the
desirability of a hybrid construction. I was more comfortable with
pure ML-DSA when it was a 2030s thing on the basis that we'd have
more time for algorithmic and implementation scrutiny.

-d

_______________________________________________
Ssh mailing list -- [e-mail]
To unsubscribe send an email to [e-mail]
________________________________
This message, and any attachment(s), is for the intended recipient(s) only, may contain information that is privileged, confidential and/or proprietary and subject to important terms and conditions available at http://www.bankofamerica.com/electronic-disclaimer. If you are not the intended recipient, please delete this message. For more information about how Bank of America protects your privacy, including specific rights that may apply, please visit the following pages: https://business.bofa.com/en-us/content/global-privacy-notices.html (which includes global privacy notices) and https://www.bankofamerica.com/security-center/privacy-overview/ (which includes US State specific privacy notices such as the http://www.bankofamerica.com/ccpa-notice)