[Ssh] Re: PQ signatures - where do we want to end up?

[Ryan Appel <[e-mail]>]

Personally,

I see the value both ways. 

I personally like the separation down to the context level of the signature, because in order to validate you have to have the same context string. 

I think there’s lots of moving parts to SSH that if not incorporated from the get-go makes it harder to add later. 

I wish there were domain separation from all signature applications. It’s kind of funny that it’s existed in key exchange (ffdhe groups between Ike and TLS as an example) for a period of time, but signature applications haven’t taken the same separation. 

Because there hasn’t been this separation in years past with any of the other signature algorithms and because the TLS and IPSEC groups have also not done any context strings for domain separation in their ML-DSA proposals, it makes me weary to add it to ML-DSA alone for SSH. It seems that the context has been generally been taken care of in higher levels of the protocols application of the signature scheme. For example, (again referencing TLS)  RFC 8446 section 4.4.3 has a context string for the server signature that is used within any signature as part of the message input to be signed, which would make adding the same context in the context string of ML-DSA redundant. 

If we want domain separation between signatures within SSH, it should probably be at a higher level, which would introduce a breaking change within the SSH protocol itself. 

Thank you,
    Ryan Appel

> On May 11, 2026, at 7:06 PM, Damien Miller <[e-mail]> wrote:
> 
> On Mon, 11 May 2026, Niels Möller wrote:
> 
>> Damien Miller <[e-mail]> writes:
>> 
>>> 3. Use context-dependent strings, e.g. "SSH-USERAUTH", "SSH-HOSTAUTH"
>> 
>> [...]
>> 
>>> There is a security benefit to be had here though: in the case where
>>> signing is being performed by some separate entity, say a HSM or
>>> privilege-separated key signing oracle, then it becomes very easy to
>>> verifiably restrict it to making only signature operations of a
>>> particular type without having to teach it to directly inspect the
>>> data being signed.
>> 
>> One place where this implies new complexity is in the ssh-agent
>> protocol. I'd like to be able to use the ssh-agent protocol both for ssh
>> publickey login (where the context would always be "SSH-USERAUTH"), and
>> for other purposes. Ideally, it would be nice to pass pubkey + context
>> to the SSH_AGENTC_SIGN_REQUEST (and then the agent might accept some
>> contexts and refuse others).
> 
> This is a very good point. Fitting this into the agent protocol would
> require either an additional message or an extension to the existing
> SSH_AGENTC_SIGN_REQUEST message. (You'd think the author of the agent
> draft would have thought of this first).
> 
> -d_______________________________________________
> Ssh mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]