So I was tapped a few minutes ago to head into the city to replace a piece of equipment at one of the NYC telecom hotels. Writing this on the train now, will post later I guess since this laptop can't talk to the phone.
Well, that's a misnomer actually -- the phone itself can make LJ posts, and the phone itself has an SSH client. And since both speak IR, I could beam this whole post over to the phone and then upload it.
But that's overkill, ne?
Anyway, I've looked into the SSH key thing I mentioned before. And I've decided it's absolutely stupid.
Basically, publishing the keys in NORMAL dns isn't enough. You have to be using the DNSSEC secured DNS extensions. What this means is every time I changed the gushi.org zone, I would have to generate a signature (nothing inherently hard about that, everything's scripted anyway). I would have to publish that signature in my DNS. And then, what's worse, is that everyone else, has to be using a DNS client that UNDERSTANDS the security enhancements, and passes on the "yes, this is secure" data to the end user. Worse still, each of those DNS servers has to accept, and TRUST my DNS public key. So if you're a user on a dynamic comcast IP (and presumably using the comcast DNS servers), Comcast would have to accept my key and include it into their system. AND, they think you should be running some encrypted protocol between yourself and comcast's DNS servers, like IPSEC.
Now, why the hell I can't just take my GeoTrust certificate that says "Yes, we've certified that this person runs gushi.org", and stuff THAT into my zonefile (this is how Sendmail, Apache, ProFTPd, Webmin, Usermin ALL work)...and then comcast would say "we believe in GeoTrust, and they say to trust you, therefore everything seems to be in order".
Of course, the system outlined above seems to be a replacement for caching the keys locally, which is even more stupid. All I'd like to see is something like this.
checking dns for prime.gushi.org...
key found in DNS...
the ssh key coming from prime.gushi.org, id aa.aa.aa.aa.aa.aa.aa is not known,
HOWEVER, it *does* match the key found in DNS, as retrieved from ns2.gushi.org
Would you like to continue connecting? (y/n)
From there, it would be business as usual. The key caches would still be used, instead of relying purely on DNS. SSH would still check the key cache, and would still bitch heavily if the connecting public key didn't match the one in the cache. Period. This would only serve as a method of distributing the key that makes more sense than "just type yes".
I suppose, optionally, that this kind of thing could be checked *every time*...but the cache would still be preferred.
Now, it's assumed that someone with enough brains to spoof a man-in-the-middle attack would also be able to spoof the DNS query that grabs my key (that's why the guys were talking about DNSSEC).
The other thing I'd love to see, as an optional "comment" field in the key, is a how-to-verify field.
The ssh key aa.aa.aa.aa.aa.aa.aa.aa is not known, however, the creator of this key has stated that this key may be verified in any or all of the following way(s):
NOTE: You should personally check as many of the following as you feel are necessary to verify that this id is authentic.
"see url: http://www.gushi.org/keyinfo.txt
"if in doubt, call Gushi at 1-866-LI-GUSHI, dial option 12"
"Key fingerprint should be sent out in the footer of signup e-mails"
"fingerprint is printed on the back of Gushi's business card"
Now, of course, those methods are easily compromisable too...but security is a layered thing, but it's assumed that if someone is running a man-in-the-middle attack against prime.gushi.org, that they won't be able to gafutz with ALL those methods.
Doing the first bit, the DNS lookup, could be tweaked with only patching to the SSH code...right now, the spec states:
A public key verified using this method MUST NOT be trusted if the
SSHFP resource record (RR) used for verification was not
authenticated by a trusted SIG RR.
Clients that do validate the DNSSEC signatures themselves SHOULD use
standard DNSSEC validation procedures.
Clients that do not validate the DNSSEC signatures themselves MUST
use a secure transport, e.g. TSIG , SIG(0)  or IPsec ,
between themselves and the entity performing the signature
Of course, the spec (http://www.snailbook.com/docs/dns-fingerprints.txt
) also states "Expires March 5, 2004" so I'm not sure how real this is. I think I could make a serious motion toward getting this made real.
The sourceforge SSH servers got whacked a while ago, and a lot of people wound up revealing their sourceforge ssh passwords to the thing. The hackers were then able to log into the sourceforge shell accounts, and use the STORED KEYS that people had there to jump to other places. People actually VERIFYING KEYS would help this a lot.
As for the second part, the key "extensions", those would probably lead to widespread breakage, and we'd probably have to wait for the widespread adoption of ssh3 (which I'm not even sure is a draft yet).