Slashdot Mirror

I decline your offer because you have no idea what you are talking about.

what we need is true end-to-end encryption and that will get us all the 'secure' we need.

First off, I don't mean to be an ass, you just seem to be ignorant. There is something called DNSSEC that not only exists, but is part of IPv6. Considering that you do not mention DNSSEC, and that both it and our current TLS implementations include "tapless and secure" "end-to-end" encryption facilities supports my first sentence...

DNSSEC isn't just for DNS, it could authenticate and encrypt email, or any other web traffic and can be a replacement for SSL. Please research it before replying to this comment.

Additionally, it doesn't matter how encrypted your connection is to what you see as yourbank.com if you can't verify that your are really connected to the place you think you are connected. Ergo: end-to-end encryption is not all the 'secure' we need, we also need authentication -- The fact that you did not mention authentication also supports my first statement. Now, if there is already a shared secret key between two parties then BOTH authentication and encryption can be performed easily.

Me: "I'm VortexCortex, here is some session salt: NWUyOGVkMWZlMTQw, and here is my encrypted message: "..."
Bank: "Hello VortexCortex, here is some session salt: MTkwMjM4MDE5ODIzM, and here is my encrypted reply: "..."

The shared secret key can be used along with the salts to create a key that decrypts the messages -- no fancy PKI needed... However, how do you first set up the account? With banks, you could visit them in person, but what about online retailers? You would have no pre-shared key, and this means they don't know who you are, and you can't verify who they are because neither have a pre-shared key.

Thus, we need some form of trusted public/private key infrastructure (hierarchical or Web of Trust, etc) in order to first validate an endpoint.

Finally -- WE CAN'T ENCRYPT EVERYTHING. It's not feasible to do this for cached content, high bandwidth video, live streaming, etc because encryption makes distributed content and/or deduplication impractical.

Unfortunately HTML and TLS (security) are designed independently of each-other and no one (but me?) thinks that HTML needs to know about security too... HTTP cookies can be marked as "secure only", why can't HTML tags have secure attributes?

The thing is: We don't need to encrypt something in order to trust it -- we can use hashing / digital fingerprints to ensure data integrity. Here's a post I made concerning the brain-damage that is the lack of security aware HTML. For the link-lazy, here's the pertinent part:

The BIGGEST retardation on the WEB is the fact that we have strong encryption and cryptographic signature technology in our browsers, and yet MIXED content is UNSAFE because (X)HTML standards don't declare facilities to specify fingerprints for the non-encrypted data that the encrypted page pulls in -- thus allowing for privacy of encrypted content, AND caching of plaintext content WITHOUT compromising integrity.
<img src="bkgnd.png" sig="SHA-1/hex;22172a80d89e99d250db62bf71031a23cbac4801" salt="HMAC/Base64;U2VjdXJpdHkgaXMgZWFzeS4K" /> Now apply this to the .js, .class, flash, .mp3, .avi, etc, and you get the point.

in short: You don't seem to know what you are talking about, but fret not, no one else does either or else we would have already solved this problem (because the answers are so apparent to those who do know what they are talking about).

TL;DR: I agree, the current direction the web is going is fine, but we need authentication an

Don't forget the basics before looking at alternatives. DNSSEC http://www.dnssec.net/

Since no one mentioned yet, http://www.dnssec.net/ is also a good information site.

DNSSEC was designed to protect the Internet from certain attacks, such as DNS cache poisoning [0]. It is a set of extensions to DNS, which provide: a) origin authentication of DNS data, b) data integrity, and c) authenticated denial of existence.

Taken from DNSSEC.net

All browsers would have each registrar's root CA certificates in their CA store. When a person registers a domain name, the registrar also gives them either an issuer certificate for that domain or a wild card certificate for that domain. The person could then either use the issuer certifcate to make more (www.example.com, store.example.com, etc.) or just use that wild card certificate (*.example.com).

Congratulations, you have just invented DNSSEC.

Next task: Get root registrars to actually publish and issue root certificates to the registrars.

After that, get browsers to support them.

And, since you're too lazy to post links to DNSSEC howtos (like this one), you're not helping and only name calling. The issue is that there are 15 RFCs with DNSSEC in the title and no clear idea where to get started.

But, hey, this is Slashdot, where any idiot can get a lame name like "BitZream", and post insult anonymously.

No worries; I will email Dan and talk to him offline about it.

36 RFCs over the course of 12 years for a not-even-deployed-yet standard really is quite excessive. I don't blame him for thinking it's going to be a monster...

The namedroppers list has, in the last 10 years I've been monitoring it, been a source of misinformation and frequently mismanaged.

Kaminsky's bug is a rehash of an old bug that non-BIND nameservers were already strong against.

If your sole source of information about DNS comes from the likes of Randy Bush, you sir are an embarrassment to network administrators everywhere.

1. According to the IETF, DNSSEC was started in 1993. That's far longer than a decade.

2. A controlled, toplevel deployment of DNSSEC to .SE knocked out a number of .SE sites. Look at this for more details.

3. If you honestly think there aren't install costs with replacing DNS with something else, you're a fucking idiot and not worth my time..

Argument by vigorous assertion? Please. This is common knowledge. The BIND group says this isn't important, and DNSSEC is almost there.

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.

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.

Most of that is covered by DNSSEC, as outlined in RFCs 4033, 4034, 4035, 4310, 4641, 5155.

IIRC it doesn't have any hooks for any sort of CA infrastructure, but given all that there is in DNSSEC, it wouldn't be hard to add it.

The problem is that DNSSEC is even farther from actual widespread real world use than is IPV6, for reasons ranging from conflict between various stakeholders to "real" problems like getting it deployed on all the various name servers in the world, getting them compatible with each other, and backward compatible with plain old DNS. There are some very poorly implemented DNS servers out there, and they are very likely to only get worse when a more complex system, such as DNSSEC, gets involved.

For more on DNSSEC, see http://www.dnssec.net/ or check the Wikipedia entry.

DNSSEC has gone through three (3) mutually incompatible specifications. The DNSSEC people are claiming that the last revision really really works, honest, gov, and that all that remains to be done is deploying it.

But they don't appear to be deploying it on their own servers.

A lot is happening with DNSSEC these days. It is being deployed in the ccTLD for Sweden: ".se" Check out

http://dnssec.nic.se/

Tutorial/howto: http://www.ripe.net/disi/dnssec_howto/

$ dig @bind.dnssec.se www.ripe.net +retry=1 +dnssec +multiline
and look for the "flags" to include "ad": ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1

http://www.dnssec-deployment.org/
  Threat Analysis Of The Domain Name System
    IETF RFC 3833 http://www.rfc-archive.org/getrfc.php?rfc=3833

Cache poisoning, in the wild:
      http://isc.sans.org/presentations/dnspoisoning.php
      http://www.dnssec-deployment.org/epi.htm

http://www.dnssec.net/

If it's all about trust, then you don't want to extend the TTL, you want to *shorten* it. That way if you're hit with a cache-poisioning attack, you get the correct record *faster*, instead of holding on to crap for weeks.

Uh, no. The TTL of a poison record is up to the attacker, not you. A poisoner will simply set the TTL to 99999999 in the poison record.

If you want trustable DNS, start advocating for DNSSEC.

Under Yahoo's new architecture, a system sending an e-mail message would embed a secure, private key in a message header. The receiving system would check the Internet's Domain Name System for the public key registered to the sending domain.

On the other hand, this significantly increases the resources needed to deliver and receive e-mail. Not only is more processing time needed, but significantly more bandwidth as well. Every single e-mail message, including NDR's and warning messages, would have an extra hundred bytes (guesstimate) for the key in the header. Plus the MTA's would need to do additional DNS queries in order to look-up the keys.
Sure it's a pretty small increase in resources on an individual scale. But when an ISP is processing 100,000 messages a day it adds up. Overall it means more e-mail would be delayed.

One could hope that the trade-off in extra bandwidth and CPU resources would balance out with significantly less spam. But Spammers have already shown their willingness to do anything illegal to get what they want. Breaking into servers to steal private keys would certainly not be above the ethics of spammer, nor beyond their technical abilities. Sure they may not be able to break into Yahoo's server, but Joe Sixpacks home-business server?

Here's the other big gotcha with this scheme... Assuming this is done at the level of the domain names and not just the MTAs, we could see a situation arise where users wouldn't be able to send e-mail out except with the domain name of their ISP provider. Right now I use RoadRunner's SMTP server to send all my e-mail but I'm not using my RR e-mailboxes (except to collect spam). Of course this is why spam is so easy to do in the first place... the SMTP server doesn't attempt to validate my username OR domain name.

Maybe the aim for "Domain Keys" is to allow the MTAs to verify each other's identities and won't rely strictly on the domain name. But would it hurt Yahoo! or AOL if users of their networks were locked-in to using just their e-mail addresses?

That is precisely the area that needs work done. It probably takes a new protocol to arrive at a distributed system that is nevertheless secure. In DNS-based RBL systems one could use zone signing to ensure that bogus zones/servers can't be introduced into the system. You can imagine authoritative updates being issued by some trusted bodies, e.g. ORBS, Spamcop etc, and targeted client queries to the distributed servers like "check this IP for me against your lists from x and y RBL". If the reply comes with a fresh signature from the originating RBL, you can surely trust it.

Your argument is an interesting one, but the problem is that DNS itself is insecure. That's the whole reason projects like DNSSEC exist. If we ever reach the point when we can guarantee that DNS queries are secure, then your proposal would be completely valid. Let's hope we get there someday :)