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

["Appel, Ryan" <[e-mail]>]

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



From: Thom Wiggers <[e-mail]>
Sent: Tuesday, April 28, 2026 5:25 AM
To: Damien Miller <[e-mail]>
Cc: Watson Ladd <[e-mail]>; [e-mail]
Subject: [Ssh] Re: Supporting pure ML-DSA as hostkey and authkey

Hi all,


Op 28 apr 2026, om 01:08 heeft Damien Miller <[e-mail]<mailto:[e-mail]>> het volgende geschreven:

One thing that I think deserves some consideration for integrating
ML-DSA (and hybrids based on it) into SSH is the user of the context
parameter. Currently draft-sfluhrer-ssh-mldsa and my implementation
use the empty context string, but there might be some benefit to
using a context that relates to the role of the signature in the
SSH protocol, e.g. using "SSH-USERAUTH-PUBKEY" for public key
user authentication signatures, "SSH-HOST" for hostkey signatures
in KEX replies, etc.

It is my belief as a protocol analysis guy that we should be using these context strings more. There was a nice paper [0] & talk at the MLS wg last year where some people were able to do some attacks on MLS precisely because the same signing key was used in different contexts, which were not context-separated.

IIRC, the authors urged everybody to start using these context strings — unfortunately, it seemed that for a lot of (classic) signature implementations this part of the spec was not implemented (not sure if there was a good reason for that).

Cheers,

Thom

[0] https://ia.cr/2024/799<https://urldefense.com/v3/__https:/ia.cr/2024/799__;!!I2XIyG2ANlwasLbx!WEuF9QoMv_TPidcQyPAZRkdcctUp-PcugJX8vLMToIec9UCitMq0pB7Dj4gXe9Nl2R-UTA_gcTJJSc64QQ$>
RWC slides https://iacr.org/submit/files/slides/2025/rwc/rwc2025/73/73_slides.pdf<https://urldefense.com/v3/__https:/iacr.org/submit/files/slides/2025/rwc/rwc2025/73/73_slides.pdf__;!!I2XIyG2ANlwasLbx!WEuF9QoMv_TPidcQyPAZRkdcctUp-PcugJX8vLMToIec9UCitMq0pB7Dj4gXe9Nl2R-UTA_gcTIUg6HnLg$>
EC slides https://iacr.org/submit/files/slides/2025/eurocrypt/eurocrypt2025/425/425_slides.pdf<https://urldefense.com/v3/__https:/iacr.org/submit/files/slides/2025/eurocrypt/eurocrypt2025/425/425_slides.pdf__;!!I2XIyG2ANlwasLbx!WEuF9QoMv_TPidcQyPAZRkdcctUp-PcugJX8vLMToIec9UCitMq0pB7Dj4gXe9Nl2R-UTA_gcTLxY4gjLQ$>

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