I'm guessing that SSL isn't used in the applications you name often for performance reasons. That's a shame - with better crypto the performance hit could be reduced to very little. For example, SSL session cacheing is unbelievably clumsy and painful. With better crypto you could build a session cache that lived entirely on the client side; the cached sessions would then last for days rather than hours, and so the server workload for supporting crypto would be hugely reduced.
SSH is distinct from SSL mainly for historical reasons. However SSL doesn't support password-based authentication. SSH does, but as far as I know doesn't support things like session cacheing at all. In addition SSH doesn't support modern password protocols like SRP, which is just ridiculous given their security benefits. You are right that a single protocol should subsume both roles.
As you say, ideally packet-level crypto a la IPSec would replace both; the trouble with this is that unlike transport-layer crypto, packet-layer crypto requires operating system support and so is much harder to get deployed. You'd need some real cleverness to make it all seamless, too: when you looked up the URL you'd have to get information about what sort of VPN to set up in order to get to the content, and there are some tricky issues with address space. I'm increasingly starting to think that secure networking is naturally source routed, and that's a change to the way people usually think about network programming. I'd be interested to know if there are any other inherent reasons to prefer transport-layer security.
I would expect the wire formats for secure connections and secure files to differ somewhat but have a lot in common.
Getting a public key for joe@domain.tld is a job for DNSSEC or similar, as discussed above. Given such a mechanism I'd certainly expect it to extend to everything you want a public key for, including OpenPGP-like applications; as I say, though, this is the edge of Zooko's triangle that interests me least at the moment. The authorities who are in a position to make things better in this space have strong short-term commercial motivation to profit from how crap they are. And I don't believe we could fix it by stepping up to replace Verisign, either, though it's been tried; ultimately we would put ourselves in a position where we were competing in the same space and with the same commercial pressures, but without their massive market dominance. The secure solution will be to empower users to cut out the middleman and directly make assertions about trust on keys.
![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png)
timeasmymeasure
no subject
Date: 2007-02-19 07:48 pm (UTC)SSH is distinct from SSL mainly for historical reasons. However SSL doesn't support password-based authentication. SSH does, but as far as I know doesn't support things like session cacheing at all. In addition SSH doesn't support modern password protocols like SRP, which is just ridiculous given their security benefits. You are right that a single protocol should subsume both roles.
As you say, ideally packet-level crypto a la IPSec would replace both; the trouble with this is that unlike transport-layer crypto, packet-layer crypto requires operating system support and so is much harder to get deployed. You'd need some real cleverness to make it all seamless, too: when you looked up the URL you'd have to get information about what sort of VPN to set up in order to get to the content, and there are some tricky issues with address space. I'm increasingly starting to think that secure networking is naturally source routed, and that's a change to the way people usually think about network programming. I'd be interested to know if there are any other inherent reasons to prefer transport-layer security.
I would expect the wire formats for secure connections and secure files to differ somewhat but have a lot in common.
Getting a public key for joe@domain.tld is a job for DNSSEC or similar, as discussed above. Given such a mechanism I'd certainly expect it to extend to everything you want a public key for, including OpenPGP-like applications; as I say, though, this is the edge of Zooko's triangle that interests me least at the moment. The authorities who are in a position to make things better in this space have strong short-term commercial motivation to profit from how crap they are. And I don't believe we could fix it by stepping up to replace Verisign, either, though it's been tried; ultimately we would put ourselves in a position where we were competing in the same space and with the same commercial pressures, but without their massive market dominance. The secure solution will be to empower users to cut out the middleman and directly make assertions about trust on keys.