Slashdot Mirror

No, I agree with you. But it is the new trend because some people definitely prefer to see it over time rather than over a page. Color me confused as well.

But we have a text version as well, so never fear: https://www.dnssec-tools.org/wiki/index.php/Sign_Your_Zone

If ssh used DNSSEC to update the known hosts file without asking the user for confirmation, it would be a significant drop in security

Depends. In some environments, measures are taken to alleviate the problem of ssh requiring to go interactive to deal with key updates (can be induced by reinstalls or by things like fixing the debian host key generation problem a while back). Those measures frequently either compromise the secrecy of the host keys or provide known_hosts via a shared filesystem strategy that is likely to be less than secure. If DNSSEC works perfectly (i.e. data cryptographically validated on the local host), then it may displace some insecure workarounds commonly in place.

Nice, I didn't know about RFC 4255 before now. This is the kind of thing I had in mind, I didn't know it already existed.

Yes, already implemented in current OpenSSH. Been playing with it and it will provide enhanced trust if AD flag is set, so it won't help for locally authoritative data. I haven't tried it, but have been wanting to play with https://www.dnssec-tools.org/wiki/index.php/Ssh. I've been getting on a soapbox in the hopes some OpenSSH developer will take note of that.

I'd not trust it as an alternative to known hosts, but as a supplement it sounds like a good idea.

I'll admit that perhaps it shouldn't be by default, but it should be an option for places that torture the ssh config today in worse ways in order to simplify ssh administration at the cost of security.

you need to work on your reading comprehension skills.

DNSSEC exists plain and simple. it's already been deployed for a lot of domains and root nameservers. just because there are difficulties hampering its widespread adoption doesn't mean it doesn't exist. that's like saying IPv6 doesn't exist because it's still suffering from a lack of widespread adoption.

none of the factors preventing more widespread deployment are problems that need "solving." in fact, they're more social/political problems than they are technical problems. so the "solution" to these problems is simply to persuade/pressure/coerce DNS servers to adopt DNSSEC, which is what IETF is debating about.

1. backward-compatibility may be difficult to maintain, but this is a transitional problem, and it's not a real technical barrier to adoption at this point. BIND 9.3 (several older versions are compatible as well) officially supports DNSSEC, so does NSD, and Nominum's ANS and CNS. the fact of the matter is, there are tons of domains already using DNSSEC without issue.
2. the zone enumeration issue has already been solved with NSEC3 (RFC 5155) released in March--which you'd already know if you'd read the rest of that Wiki article.
3. this is a logistical problem that every new technology/protocol/standard faces. the main issue here is the last-mover advantage. nobody wants to be the first to adopt a new standard when there's no financial incentive to do so. but somebody has to go first. and at this point there is already a wide variety of software, prototype systems & tools available for implementing DNSSEC with little to no risk involved.
4. this is purely a political issue, and it has more to do with the U.S.'s monopolistic control over the DNS system than DNSSEC. perhaps if ICANN acted more impartially instead of getting in bed with Verisign and other commercial corporations we wouldn't have political BS hindering technological progress. in any case, this is an ICANN problem and could be solved by organizational reforms to make ICANN operate with more transparency and give other nations a voice in domain name management.
5. the perception of DNSSEC being too complex or difficult to adopt is just that--a problem with public perception. IETF is working on resolving this problem through education and training, which are on their deployment road map. there's a lot of good free resources out there to help ease others through this transitions and dispel false perceptions.

Just like HTTPS and PGP require keys to get you started with your "trust", so does DNSSEC. With HTTPS you have a set of root CAs that you trust to issue certificates to web sites. Browsers, in fact, distribute a fairly mind numbingly large number of CAs that they accept as authentic providers of SSL certs to be trusted. PGP requires that you boot-strap your own trust by finding keys of all your friends before they send you important data you need to authenticate.

DNSSEC is really no different. The only question is, what's your bootstrapping set of keys. The advantage of waiting for the root to get signed is that you might be able to have just a single set of keys to serve as your "trust anchors".

And, it's entirely possible, for example, that even if the root was signed you'd trust some subdomain's key with a higher level of trust. EG, example.com might trust it's own key more than .coms. Just as it's possible to come up with obtuse security requirement scenarios for any other cryptographic trust policy, you can do the same thing with DNSSEC.

And, even if the root was signed today .com, .org and .net aren't. So if you have example.com you're already missing a trust link because there is no way to get securely from the root to example.com with that nasty break in the middle. And it's equally unclear when .com is going to get signed just as it's unclear when the root is.

Security always comes down to: who do you trust to tell you who you can trust.

Sign your zones, and if your registrar won't accept keys from you, send them to a DLV registry while you wait for that.

People who are interested in signing their zones may want to read up on how things work at www.dnssec.net and take a look at the Sparta tools. It's really not difficult, and there is a lot of information out there.

oh, I think we may see a few

There is also the requisite sourceforge project with additional helpful tools: www.dnssec-tools.org