Re: disable HPN in sshd for the -10 branch?
On Thu, May 26, 2022 at 12:34:49AM +, David Holland wrote: > On Tue, May 24, 2022 at 06:57:23AM -, Michael van Elst wrote: > > Also consider that people believe their data is safe in the current > > virtualized world, just because someone calls "encryption". > > Gung znxrf lbhe choyvpnyyl fgngrq bcvavba abg vzcbegnag? > V qba'g xabj nobhg lbh, ohg V cbfgrq vg bire na rapelcgrq frffvba, naq > gurfr qnlf n ybg bs gur genafcbeg vf rapelcgrq gbb. That's what I was talking about. -- Michael van Elst Internet: mlel...@serpens.de "A potential Snark may lurk in every tree."
Re: disable HPN in sshd for the -10 branch?
On Tue, May 24, 2022 at 06:57:23AM -, Michael van Elst wrote: > >(1) having an unencrypted option at all is one of the ways spooks like > >to weaken cryptosystems; it creates ways to force/cause people to use > >it when they didn't mean to. > > People have to be very clear in making that choice and they actually > use it for a reason. > > Consider the alternatives that are much weaker and don't protect > anything at all. > > Or consider the alternative to create separate tools that satisfy > the requirements that the HPN patch was created for. Will that be > better? It is better, yes, because it's much harder to engage an entirely different tool by trickery. > Also consider that people believe their data is safe in the current > virtualized world, just because someone calls "encryption". True, but that's not a reason to make the situation worse. > >(2) if you don't encrypt everything, you're telling anyone who's > >listening which data's important. > > Gung znxrf lbhe choyvpnyyl fgngrq bcvavba abg vzcbegnag? V qba'g xabj nobhg lbh, ohg V cbfgrq vg bire na rapelcgrq frffvba, naq gurfr qnlf n ybg bs gur genafcbeg vf rapelcgrq gbb. -- David A. Holland dholl...@netbsd.org
Re: disable HPN in sshd for the -10 branch?
On Mon, May 23, 2022 at 05:30:36PM -0700, John Nemeth wrote: > On May 3, 13:00, Greg Troxel wrote: > } mlel...@serpens.de (Michael van Elst) writes: > } > } > Part of the HPN patches is to optionally strip encryption (and now even > } > integrity checks) for the data transfer. Doesn't fit into what > } > the OpenSSH people want, not even as an option. > } > } I would say that doesn't really fit with what we want either, certainly > } without somebody really trying. It breaks the rule that using ssh can > } count on confidentiality and integrity and makes systems with ssh as a > } component harder to reason about. > > I would say it is something that should be available as an > option (likely a command line option). Historically, it was enabled via `-c none` before OpenSSH took it out.
Re: disable HPN in sshd for the -10 branch?
dholland-t...@netbsd.org (David Holland) writes: >(1) having an unencrypted option at all is one of the ways spooks like >to weaken cryptosystems; it creates ways to force/cause people to use >it when they didn't mean to. People have to be very clear in making that choice and they actually use it for a reason. Consider the alternatives that are much weaker and don't protect anything at all. Or consider the alternative to create separate tools that satisfy the requirements that the HPN patch was created for. Will that be better? Also consider that people believe their data is safe in the current virtualized world, just because someone calls "encryption". >(2) if you don't encrypt everything, you're telling anyone who's >listening which data's important. Gung znxrf lbhe choyvpnyyl fgngrq bcvavba abg vzcbegnag?
Re: disable HPN in sshd for the -10 branch?
jnem...@cue.bc.ca (John Nemeth) writes: > I would say it is something that should be available as an >option (likely a command line option). ssh/scp has pretty much >completely replaced rsh/rcp (other than for people that go out of >their way to use those); however, there are many things that get >copied around that are completely public where encrypting them for >data transfer is useless overhead. That said you likely still want >passwords encrypted and integrity checks. I'm trying to fix the HPN code, mostly by updating it to the latest version. The old code didn't handle buffer scaling, that part already got better, but there are more changes.
Re: disable HPN in sshd for the -10 branch?
On Mon, May 23, 2022 at 05:30:36PM -0700, John Nemeth wrote: > } I would say that doesn't really fit with what we want either, certainly > } without somebody really trying. It breaks the rule that using ssh can > } count on confidentiality and integrity and makes systems with ssh as a > } component harder to reason about. > > I would say it is something that should be available as an > option (likely a command line option). ssh/scp has pretty much > completely replaced rsh/rcp (other than for people that go out of > their way to use those); however, there are many things that get > copied around that are completely public where encrypting them for > data transfer is useless overhead. That said you likely still want > passwords encrypted and integrity checks. (1) having an unencrypted option at all is one of the ways spooks like to weaken cryptosystems; it creates ways to force/cause people to use it when they didn't mean to. (2) if you don't encrypt everything, you're telling anyone who's listening which data's important. IOW, I disagree entirely. -- David A. Holland dholl...@netbsd.org
Re: disable HPN in sshd for the -10 branch?
On May 3, 13:00, Greg Troxel wrote: } mlel...@serpens.de (Michael van Elst) writes: } } > Part of the HPN patches is to optionally strip encryption (and now even } > integrity checks) for the data transfer. Doesn't fit into what } > the OpenSSH people want, not even as an option. } } I would say that doesn't really fit with what we want either, certainly } without somebody really trying. It breaks the rule that using ssh can } count on confidentiality and integrity and makes systems with ssh as a } component harder to reason about. I would say it is something that should be available as an option (likely a command line option). ssh/scp has pretty much completely replaced rsh/rcp (other than for people that go out of their way to use those); however, there are many things that get copied around that are completely public where encrypting them for data transfer is useless overhead. That said you likely still want passwords encrypted and integrity checks. }-- End of excerpt from Greg Troxel
Re: disable HPN in sshd for the -10 branch?
g...@lexort.com (Greg Troxel) writes: >I would say that doesn't really fit with what we want either, certainly >without somebody really trying. It breaks the rule that using ssh can >count on confidentiality and integrity and makes systems with ssh as a >component harder to reason about. Still, it's what the HPN patch is about, trading some features for better performance, and the "confidentiality and integrity" stuff is purely optional.
Re: disable HPN in sshd for the -10 branch?
mlel...@serpens.de (Michael van Elst) writes: > Part of the HPN patches is to optionally strip encryption (and now even > integrity checks) for the data transfer. Doesn't fit into what > the OpenSSH people want, not even as an option. I would say that doesn't really fit with what we want either, certainly without somebody really trying. It breaks the rule that using ssh can count on confidentiality and integrity and makes systems with ssh as a component harder to reason about. signature.asc Description: PGP signature
Re: disable HPN in sshd for the -10 branch?
g...@lexort.com (Greg Troxel) writes: >I view HPN as not the standard approach; it hasn't been merged upstream >and PSC's agenda does not even seem to include merging any of it >upstream -- which I see as a huge clue. Looks more like upstream was never interested and PSC gave up. Part of the HPN patches is to optionally strip encryption (and now even integrity checks) for the data transfer. Doesn't fit into what the OpenSSH people want, not even as an option. The last version now renamed the binaries and (so far) you only have the patched sources on github, no patches against openssh-portable. This feels more like a fork. If we had a plain openssh-portable otherwise, I'd say remove the patch and provide a hpnssh package, but we probably want NetBSD adaptions then in the package too. >My quick reaction is that unless we are confident that the HPN patches: In the current state our in-tree version doesn't work correctly and often makes things slower. I should test the github version if that's a problem with our patch handling or with NetBSD itself.
Re: disable HPN in sshd for the -10 branch?
nia writes: > I've heard some reports that the HPN-SSH patches to sshd are > not quite working as well as expected, with some users getting > mildly worse results. They're apparently supposed to improve > performance: > > https://www.psc.edu/hpn-ssh-home/ > > With "HPNDisabled" in sshd_config I notice no particular difference > in sshd performance, but I don't have access to any particularly > amazingly large machines currently. I view HPN as not the standard approach; it hasn't been merged upstream and PSC's agenda does not even seem to include merging any of it upstream -- which I see as a huge clue. My quick reaction is that unless we are confident that the HPN patches: - make things better (or neutral) for almost everybody - have zero downsides then it is just as well to have them disabled by default in the config file. People with massively fast networks with long delays but no congestion generally know who they are. But it would be very interesting to hear test results from people both ways. signature.asc Description: PGP signature
