[Ssh] Re: Deprecation of Compression - Scope

[Dick Brooks <[e-mail]>]

Bobby,

 

The chairs have requested that I cease all further discussion about support for Zero Trust in the ssh protocol.

 

I will oblige the chairs request, but I will be very surprised if others aren’t running up against this issue with the US Government contracts that require Zero Trust implementation.

 

 

Thanks,

 

Dick Brooks

 

 

From: Metz, Bobby via Ssh <[e-mail]> 
Sent: Friday, October 16, 2026 2:44 PM
To: Mouse <[e-mail]>; [e-mail]
Subject: [Ssh] Re: Deprecation of Compression - Scope

 

"Dick Brooks" <[e-mail] <mailto:[e-mail]> > writes:

 

>  I believe the team should consider supporting a Zero Trust MFA solution using zero trust identifiers (SHA-256 hash values) as the first check plus authentication options

 

Do you mean ONLY as a first check?  If yes, how would that improve upon an authentication module which integrates with a ZTNA solution, i.e. similar to a legacy MFA one?

 

> This airport analogy describes the concept I'm suggesting

 

I read your airport analogy, but I view the TSA and gate checks as independent authentications and not ZT or MFA.  Even with all the facial scanning, I don't see gate attendants validating anything beyond the token in my hand/phone.  Not to mention that two authenticated individuals may still find themselves assigned the same seat on the plane but I guess that's more of an authorization issue.

 

Bobby

 

From: Mouse <[e-mail] <mailto:[e-mail]> >
Date: Friday, October 16, 2026 at 11:09 AM
To: [e-mail] <mailto:[e-mail]>  <[e-mail] <mailto:[e-mail]> >
Subject: [Ssh] Re: Deprecation of Compression - Scope

This Message Is From an Untrusted Sender

You have not previously corresponded with this sender.

 <https://us-phishalarm-ewt.proofpoint.com/EWT/v1/CdLFVIQ!5qamZPGKbUMu0QOnA0sXn1lt2VLn2DD7-lEQT_qZsHJCD0K1gw3HwoV9PF1qcFiQ_CgZikTflr9GRLwhL_Tn1F6n0-VnHJdKE22Y2Q$> Report Suspicious

 

> Should ssh support authentication-only options?
 
Well, as nisse noted, it already does, in the form of `none' algorithms
(which have to be supported anyway for pre-kex communication, though
nothing says they have to be user-requestable for post-kex
communication).
 
There are even a comparatively few use cases that don't care about any
kind of leaks and would be fine with rsh, if it were still a thing.
I'm not aware of any implementation that supports what I might loosely
call a `none' kex, a dummy kex that doesn't actually do any crypto, but
the use cases that would be fine with rsh might want even that.
 
But none of that requires any protocol changes.  Not even a `none' kex;
that just requires someone to define and implement it, even if it's
called [e-mail] <mailto:[e-mail]>  or some such instead of none.
 
Of course, giving users rope always risks their using it. :-/  Like
nisse, I would hope that it would take significant levels of
reconfiguration for it to be easy to get `none' crypto.  Come to think
of it, maybe I should do that in moussh - it currently takes nothing
more than passing "none" to the usual "pick crypto" options, but then,
I tend in the YAFIYGI direction.
 
/~\ The ASCII                                                           Mouse
\ / Ribbon Campaign
 X  Against HTML                    [e-mail] <mailto:[e-mail]> 
/ \ Email!       7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B
_______________________________________________
Ssh mailing list -- [e-mail] <mailto:[e-mail]> 
To unsubscribe send an email to [e-mail] <mailto:[e-mail]> 
  _____  


This communication is the property of Lumen Technologies and may contain confidential or privileged information. Unauthorized use of this communication is strictly prohibited and may be unlawful. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy all copies of the communication and any attachments.