Earlier quoted context omitted.
* Deploying DNSSEC is obviously not trivial, as doing so has taken some of the largest companies on the Internet fully off the Internet for multiple hours, within the last year, so much so that it has become a running joke when companies have prolonged outages to suggest that DNSSEC is the culprit. * There are still resolvers that can't handle Ed25519 * Being able to use Ed25519 was never the ops problem with getting…
My favorite thing about normal ssh keys is the way it does not come with the obnoxious assumption that if I don’t rent my cert from some rent-seeker, it is super scary and invalid. And yet it gives me both identity verification and encryption. I get the reasons we got there for HTTPS due to how unsophisticated the least experienced users are, but I am glad this idea here won’t catch on in real life, because we don’t…
SSH3: SSHv2 using HTTP/3 and QUIC
201–206 of 206 posts
Re: SSH3: SSHv2 using HTTP/3 and QUIC
#202Earlier quoted context omitted.
Do you want to maintain a state machine for each QUIC-SSH session 1-N pairing? Or worse, M-N pairing?
Why not have 1:1 relationship between QUIC connection IDs and open SSH sessions?
Re: SSH3: SSHv2 using HTTP/3 and QUIC
#203Earlier quoted context omitted.
> Who does new protocols these days? My business brain understands why, but my engineer’s heart laments.
QUIC is damn good though! Its minimal header has a very tiny overhead, and the protocol gives us so much for free. What’s to lament? The userspace impl?
I meant, I wish there were more application-layer protocols (like a new IRC, NNTP, rather than say Matrix or ActivityPub which is just JSON shunting over HTTP), the rest of the OSI stack gives us plenty of choice already :)
Re: SSH3: SSHv2 using HTTP/3 and QUIC
#204This seems bad? - SSH3 is a bad name: this isn't a successor to SSHv2 and will only cause confusion - The authors don't seem to understand that SSHv2 predates all of their chosen technologies, and provides "robust and time-tested mechanisms" they claim to be adding - How is "hiding your server behind a secret link" a feature? This is, at best, security through obscurity, which can be layered on any network protocol (…
I'd agree with you. The readme calls out "Significantly faster session establishment" and goes into greater detail later on. > Establishing a new session with SSHv2 can take 5 to 7 network round-trip times, which can easily be noticed by the user. SSH3 only needs 3 round-trip times. The keystroke latency in a running session is unchanged. I, for one, can say that sometimes session establishment can take a little whil…
so if you want to execute uptime on a remote machine, the session will only be open for a few ms, and those extra RTT are a problem. (Yes, I know about openssh controlmaster...)
Re: SSH3: SSHv2 using HTTP/3 and QUIC
#205Earlier quoted context omitted.
My favorite thing about normal ssh keys is the way it does not come with the obnoxious assumption that if I don’t rent my cert from some rent-seeker, it is super scary and invalid. And yet it gives me both identity verification and encryption. I get the reasons we got there for HTTPS due to how unsophisticated the least experienced users are, but I am glad this idea here won’t catch on in real life, because we don’t…
TLS certificates are free. Unsigned certificates are super scary and invalid. SSH and TLS do not work with the same threat model; first-contacts with SSH servers are comparatively rare (if they aren't, you should be worried about your SSH threat model, too).
A cert signed by your own CA isn't scary. You can trust and install your own CA, and unless you're an idiot and publish your private key you're not harming your security profile one bit, but like I said, I understand how we got here because if it were easy and not presented as scary, naive users would be tricked into installing new CAs every day. It's just annoying how it has (in practice) imposed this external prerequisite to use TLS encryption itself, which I think is pretty obviously the reason it took like 15 years for SSL to become ubiquitous.
Re: SSH3: SSHv2 using HTTP/3 and QUIC
#206This is cool, but calling that SSH3 is not appropriate. It's an independent project, not a new version of the SSH protocol. Sure, it's "SSH3" and not "SSHv3". Still, introducing a confusion with something that could be an official protocol is not nice.
I'm surprised no one's opened an issue on their repo and that no brigade has opined with lots of comments and emojis...