Slashdot Mirror

"What she said" or +1 Insightful

dnscache (the relevant part of djbdns) is pretty smart, and pretty paranoid, and when things like this come up, DJB deserves a good round of "I told you so."

The problem here is that some people don't understand how anyone expects to attack these banking sites without also replicating their SSL certificates for secure login. The issue is that most banking sites and others with secure logins don't have a signed page for the login but for the target page of the login, and most browsers don't indicate that the submission of a given login form goes to a secure server or not (until after clicking, and only IF the user hasn't disabled that notice).

No bank is going to get a cert from RapidSSL or the like. (At least, I hope not--given the security practices I've seen at banks, I'd be surprised if they didn't

This is, supposedly, what EV certificates provide, apart from a fat new revenue stream for selling those expensive bits (quick, someone explain why wildcard certs cost a single damned penny more than single-domain certs) and making anyone who can't afford them into second-class citizens.

There is, however, an attack which goes around that; as Dan Bernstein proposed in 1999, if you set up your fake server for hugebank.com, and have it serve up redirects to your newly registered (and certified!) hugebank.secure-banking.dom site, then the user will see a validated site that they got to by typing in their bank's address or following an email link.

Given that my current bank requires me to accept javascript served from akamai.net in order for me to pay bills, and other banks use plenty of weird domains for user interaction (see pages 11--13), I don't believe that this would set off any alarms.

I complained to my bank back in August about the site requiring javascript from untrusted domains--I didn't even get to complaining about their use of various domain names. Unfortunately, there's no better alternative where I live, and they seem completely uninterested in responding to me.

It's a bit depressing how nobody takes the security implications of the internet seriously, and acts surprised when they're reminded of them.

Email is not secure. Using SSL for your POP/SMTP/IMAP connections secures your login to the server, but the mail itself is still transmitted in the clear. And people act surprised when you tell them that people can and likely do scan their email?

Then again, given that our financial institutions actively train their users to ignore security indicators (a very exploitable situation), we shouldn't be surprised at that sort of nonsense.

I noticed the following in the article:

It got worse. Most Internet commerce transactions are encrypted. The encryption is provided by companies like VeriSign. Online vendors visit the VeriSign site and buy the encryption; customers can then be confident that their transactions are secure.

But not anymore. Kaminsky's exploit would allow an attacker to redirect VeriSign's Web traffic to an exact functioning replica of the VeriSign site.

I was going to write about how clearly the built-in CA certs in the user's browser would throw up a flag and note that the cert wasn't actually signed by the folks at Verisign or whatever... but then I realized that, hey, given the abysmal state of security compliance, it's probable that nobody would even notice.

And an article on cache poisoning that doesn't even mention that Dan Bernstein had foreseen and fixed the lack of source-port randomization while pointing out that it's still only a stopgap seven years earlier is an article that should have been edited a bit more thoroughly. Kaminsky made the attack much more dangerous, but the possibility should never have existed in the first place.

In a more ideal world, we'd all exchange encrypted and signed email and access any site that involved a login using valid SSL certificates and secure-only cookies. But we're not there.

It's a bit depressing how nobody takes the security implications of the internet seriously, and acts surprised when they're reminded of them.

Email is not secure. Using SSL for your POP/SMTP/IMAP connections secures your login to the server, but the mail itself is still transmitted in the clear. And people act surprised when you tell them that people can and likely do scan their email?

Then again, given that our financial institutions actively train their users to ignore security indicators (a very exploitable situation), we shouldn't be surprised at that sort of nonsense.

I noticed the following in the article:

It got worse. Most Internet commerce transactions are encrypted. The encryption is provided by companies like VeriSign. Online vendors visit the VeriSign site and buy the encryption; customers can then be confident that their transactions are secure.

But not anymore. Kaminsky's exploit would allow an attacker to redirect VeriSign's Web traffic to an exact functioning replica of the VeriSign site.

I was going to write about how clearly the built-in CA certs in the user's browser would throw up a flag and note that the cert wasn't actually signed by the folks at Verisign or whatever... but then I realized that, hey, given the abysmal state of security compliance, it's probable that nobody would even notice.

And an article on cache poisoning that doesn't even mention that Dan Bernstein had foreseen and fixed the lack of source-port randomization while pointing out that it's still only a stopgap seven years earlier is an article that should have been edited a bit more thoroughly. Kaminsky made the attack much more dangerous, but the possibility should never have existed in the first place.

In a more ideal world, we'd all exchange encrypted and signed email and access any site that involved a login using valid SSL certificates and secure-only cookies. But we're not there.

1. Have you looked at BIND's implementation of DNSSEC? It's thousands of lines of code alone.
2. See #1.
3. RFC4033: DNSSEC (deliberately) doesn't provide confidentiality; RFC 4033: DNSSEC does not protect against denial of service attacks.
4. The bind people claim that BIND9 was written by "a whole new set of people" but at least thirteen of the developers have been identified to work on both.
5. I'm leaving this one alone.
6. CA certificates were planned for an earlier incarnation of DNSSEC
7. I don't think this requires clarification, but this pdf indicates that the IETF started DNSSEC in 1993.

Do you actually check? Or do you just call people trolls who you don't agree with?

It's a weird article. I'm not exactly certain what information was actually conveyed or what Paul Mockapetris was actually saying and I know Paul. (scratches head).

Poeple need to adopt DNSSEC. Yeah ok, whatever. A few poeple think this is giving too much power to verisign (again) and Dan Bernstein has other ideas and isn't fond of DNSSEC.

http://cr.yp.to/djbdns/forgery.html

"All you really need is a single source of trust. Right now we have 2: the root nameservers and the root SSL certificate authorities."

Well, but...

The "root servers" isn't one thing. It's 13 things. And the F server is actually a number of machines. Any one that gets compromised blows it for everything.

Another reason to run your own root zone, obtained from somebody who cryptographically signed it. Bernstein points out usenet would be a good mechanism for this.

This isn't supposed to be possible. SYN cookies are supposed to contain at least 24 bits worth of entropy...

24 bits of entropy is insignificant. WEP used a 24 bit IV, and we know how well that worked out for them.

For something to be computationally infeasible, it needs to have 80 bits of entropy or more.

Sockstress computes and stores so-called client-side SYN cookies

This isn't supposed to be possible. SYN cookies are supposed to contain at least 24 bits worth of entropy, produced by running a server-side secret through a one-way hashing function. You can easily obtain a SYN cookie by performing the initial SYN with the server. A SYN+ACK comes back which contains the SYN cookie (as the initial sequence number). The cookie so received is unique per TCP connection (IP address and port numbers at both ends), and valid only for a limited time. The server side does not maintain any state information until the cookie is returned in the client's ACK.

If they are actually computing SYN cookies on the client side, it's evidence of a weak SYN cookie implementation. Computation of the cookie should be infeasible without access to the server-side secret. Of course, this may be a case of sloppy reporting. As usual, we aren't given all the details of this earth-shattering vulnerability. We are simply left to guess whether these folks (and those that report on them) know what they're talking about or not.

They could be guessing cookies, and that would explain the "it will hurt intermediate systems" excuse they used for not demonstrating it, since they'd need to flood the peer TCP with millions of randomly-guessed initial sequence numbers. Incidentally, if this is a TCP SYN-flood attack of this sort, the "after effects" they mention have to do with the fact that all the TCP connections must time out naturally -- a process which might take several minutes per connection, depending on the configuration of the listening server application. The process is naturally limited by bandwidth and the size of the TCP state table: you have to be able to send successful fake ACKs fast enough to fill the TCP state table. All the usual mitigations for TCP SYN floods apply, such as increasing the state table size and reducing the timeout for open but idle connections.

It's not at all clear that this is any worse than the kind of DDoS attack that a typical botnet can unleash. In that case, you get thousands of perfectly real TCP connections from multiple addresses almost simultaneously. So maybe this attack doesn't require a botnet, but I don't see that it's a big new threat (as I've described it).

There's nothing wrong with FTP

FTP is insecure for anything other than retrieval of public information (i.e. anonymous downloads). And for downloads, HTTP is far more efficient as it only requires one request/response. FTP requires five.

There's nothing wrong with FTP

FTP is insecure for anything other than retrieval of public information (i.e. anonymous downloads). And for downloads, HTTP is far more efficient as it only requires one request/response. FTP requires five.

It seems despite past tensions between Wietse Venema and Daniel J. Bernstein (the author of qmail), they agree on the approach to solving spam. Bernstein proposed a similar system called Internet Mail 2000 (Wikipedia entry).

It seems despite past tensions between Wietse Venema and Daniel J. Bernstein (the author of qmail), they agree on the approach to solving spam. Bernstein proposed a similar system called Internet Mail 2000 (Wikipedia entry).

Are you seriously arguing that one could enter a contract by the act of downloading a program without even clicking any OK in the process?

This is precisely how the GPL works: by distributing, you have agreed to the license granting you the right to distribute.

By *distributing*, which is copyright holder's exclusive right. Downloading is not distributing. Even if we ignore the detail that copying for your personal use is excluded from copyright holder's rights, I would argue that when someone puts a file up for download, they're thereby giving permission to download it, and any conditions on that must be agreed on beforehand.

If the download button contains terms of service, or declares that "by clicking 'Download' you agree to the {following|linked|above|incorporated by reference} terms, then that's how it works.

*IF* it so declares - although even that is debatable, what kind of agreement can really be entered that way. But many download sites do nothing like that.

1. Warranty is imputed by statute. You must disclaim implied warranties or they are assumed to be present.

Here there is apparently a radical difference between American and European law. Here it is well established that a one-sided declaration can not reduce consumer's statutory rights, only add to them. Statutory warranties cannot be disclaimed; even attempting to do so could be considered fraudulent. Some statutory rights cannot even be removed by contract (law explicitly declares such contracts void).

2. Limitation of liability is for the copyright owner, not the user. Without caps, limits, or other mechanisms, you are open to a wide range of damages, and juries tend to return sizable awards.

Here I won't be liable to what someone does with my stuff unless I've claimed it does something it doesn't, and in no case can I avoid liability by disclaiming it. And juries don't award anything, that's another American oddity.

3. Litigation agreements, e.g., choice of law, is a civil procedure issue, not a substantive issue.

Choice of law? Surely there are sufficient default rules (and indeed trying to change them is very limited). Certainly that is in itself not important for me to worry if I put a program up for download.

4. Patent licenses are irrespective of noncommercial use.

HUH? A patent is nothing but exclusive right of commercial exploitation of an invention. Patents do not apply to non-commercial use at all. At least not by European patent convention, but I doubt even USA can be *that* different.

if you put a file up for download without requiring an explicit contract beforehand

Yes, but this scenario almost never occurs. Any given website has terms of use

Nowhere near all of them. Indeed generally only American ones, and ones by big corporations seem to, as far as I can see. And not even all Americans, see, e.g., Daniel Bernstein

.

Bingo. That's why I never understood DJB's similar little rant. You can't grow the address space and expect backward compatibility, because there's no way for a legacy node (router or host) to preserve the additional address bits (I suppose if you've got bits in another field that are always preserved and not used for anything important, you could use those. But we haven't, so that's the end of that particular story.)

Actually, there is no way to give up your copyright, either. At least, no easy way. That's why public domain licenses exist. You still own the copyright, but license it with no strings attached.

This is simply not true (at least in the U.S.). Please do not spread this misinformation.

First, there is an easy way to renounce your copyright and place a work in the public domain. You simply declare that that work is in the public domain; e.g., by a statement saying "This work is in the public domain."

But don't just take my word for it:

It is well settled that rights gained under the Copyright Act may be abandoned. But abandonment of a right must be manifested by some overt act indicating an intention to abandon that right. See Hampton v. Paramount Pictures Corp., 279 F.2d 100, 104 (9th Cir. 1960). Micro-Star v. Formgen Inc., 154 F.3d 1107 (9th Cir. 1998).

FYI, that is from Judge Kozinski's decision, not just some random judge.

The reason people claim it's impossible to do this is because they are afraid that someone, having placed something in the public domain, might come back and claim copyright to it, and that a court might uphold it. That may very well be an issue, but it certainly doesn't prevent you from renouncing your copyright - it simply means that some people might still refrain from using it.

Secondly, there's no such thing as a "public domain license." The very idea of the public domain means that the work is free for anyone to use in any way, without any license. You're obviously referring to copyright licenses like Creative Commons, which seek to provide an expansive, non-exclusive license along with a work. In these cases, you do still retain copyright, but this is not the same thing as the public domain.

For more information, visit http://cr.yp.to/publicdomain.html.

At least that's what this guy does. I know, he's a pain the ass. You know, he's been right every time so far.

how come the same vulnerability is present on other DNS servers as well ?

It isn't. djbdns for example, is not affected. I don't think maradns is affected either.

Do they all use the same code from BIND for this particular 'feature' ?

Very likely.

BIND has a very permissive license; most other DNS servers exist to facilitate lock-in with a particular vendor's stack, or to push some enhanced feature set, so they'd be considered foolish if they didn't copy BIND's source code where they could.

If this is indeed not a protocol flaw,

Well, I'm not sure it is unfair to call this a protocol flaw. Maybe a design flaw.

BIND has resisted port randomization because "the RFC said so"- never mind that they wrote the RFC, and that no clients bother checking. Because it stopped spoofing attacks ten years ago, and it stops them today, most DNS servers- including those derived from BIND- do this.

BIND also uses these very complicated credibility rules for determining if it can override existing cache-knowledge. This can presumably save one or two queries per dot, but surely it would be safer to only cache answers to questions that were asked. That is, by the way, what djbdns does.

Most DNS spoofing attacks can also be solved by solving most blind spoofing attacks. There's a little reluctance to do so, because it makes things like DNSSEC largely obsolete for their intended audience. As a result, we see a lot of chest thumping and stomping in the temper tantrum. You can tell when you're about to get into one because they start by saying "If we just switched to DNSSEC by now, we wouldn't be having this problem."

Of course, since BGP peers now route-filter everywhere on the internet (they didn't used to!), mandatory source filtering is a completely possible and realistic way to stop this and other similar problems...

With no server side support you would have to transfer the entire contents of the file every time you you wanted to view the encrypted file.

Erm... why? I don't have to read the entire contents of my encrypted partition every time I want to seek somewhere in it.

Then if it isn't what you want, it would transfer all back.

WTF?

This kind of makes me question your understanding of computers beyond "This is a mouse."

It's called copying. I download the file to view it, which is copying it -- if I didn't want it, I do not then have to re-upload the entire file -- it will still be on the server, because I copied it, not moved or deleted.

That's probably not what you meant, but the way it's worded, it sure as hell looks like it.

With plain FTP, it just gives you the header name so you can see the file is there in much the same way as ls or dir displays a directory listing.

Right.

If you want to view the contents, you have to download it

FTP supports resuming a download. Even if it doesn't support specifying that you only need some tiny chunk of it, you can always close the connection (canceling the download) once that amount has been transferred.

So no, you don't have to download the entire file.

Same with HTTP -- only moreso; I believe you can request a specific byte range of a file.

you can create a secure connection, have the server decrypt the files as needed

Both of which assume you trust the server -- because the server now has unfettered access to your files.

I don't know about you, but I'm a little more paranoid. I'd rather the server not be able to get at my files.

render the contents in a viewer that transmits only the characters your looking at, at a time.

Ok, first off, that is a retarded idea, if you're actually talking about characters (as in, chunks of a text file). Text is small enough, and compresses well enough, that it makes more sense just to send the whole file. It'll use more bandwidth, but it will perform much better, because you won't need a roundtrip to page down.

I'll grant that it does make more sense for low-latency, low-bandwidth scenarios. But I can't think of such a scenario -- the only place where that bandwidth might matter is dialup, which tends to have a high latency, mostly because it has so little bandwidth that any other, simultaneous activity will saturate the connection and slow everything down.

Second, as stated above, there's absolutely no reason you can't do this with encrypted files stored via FTP.

You can even use server side support to open large archives or zipped files and present individual files within them.

And you know what? You can use client-side support to do that, too!

For a really impressive example, take HTTPFS -- you can mount an ISO over HTTP, and it's actually fast enough to browse files and such.

The only place where this would matter is for things like tarballs -- in which case, you're forcing the server to read the entire archive from disk (probably decrypting it in the process) before sending pieces of it back.

For an archive of any size where it'd make sense to do this, it probably makes much more sense to unpack the archive, or repack it as something like Zip, which is seekable -- and either situation puts us back to Square 1, where encrypted files over FTP can do the same thing.

Now, given the question that was asked, I'm assuming it's massively easier for him to add client-side support for this than server-side support. Given what I've just explained above, you can get almost all the same features with client-side supports, and the only ones that would really benefit from server-side support (that you've mentioned) are a bad idea anyway.

I did think about it, and I don't see your point.

You seem to think that a NAT doesn't help security in the least and that a firewall is the be-all, end-all of security.

Fact is, when you say a NAT is not an alternative for a firewall you are just showing that you haven't thought it through yourself. NATs add security. That their security isn't perfect doesn't mean it isn't worthwhile. That it doesn't match a firewall exactly doesn't mean it isn't worthwhile. That they mean that I have 1 IP address for the 3 - 12 devices in my house is a win. IPv6 doesn't give me anything that my IPv4 NAT doesn't except extra work that I don't need.

The most time I'll waste on IPv6 is posting to slashdot. IPv6 offers me nothing, it is stupid (yes, you love to hate him, but again he's right), and that's it.

IMHO.

djb, love him or hate him, called this out years ago...

http://cr.yp.to/djbdns/ipv6mess.html

Lack of IPv4 embedding in IPv6 has to rank as one of the dumbest decisions of all time. It reminds me of that "anti-spam proposal evaluation worksheet" that floats around in the comments here from time to time.

Your plan fails because it:
[X] Demands immediate and total cooperation from everyone at once.

Oh, but you are. Here's a comment from 2001 clearly stating the class of attacks against which source port randomization works as a mitigating factor. The attack vector was known, the solution known... but not implemented, except by DJB.

Are you seriously suggesting that no hacker ever found out about that particular trick until Kaminsky made such a fuss about it?

Here's what DJB said about this:

Last week's surveys by the DNSSEC developers ("SecSpider") have found a
grand total of 99 signed dot-com names out of the 70 million dot-com
names on the Internet.

Am I the only person amazed by this? We've had fifteen years of
forgeries, fifteen years of concentrated work on DNSSEC, and we can't
even get simple cryptographic signatures deployed. What an embarrassment
for cryptography!

Jos Backus writes:
http://cr.yp.to/djbdns/forgery.html states:
"My top priority for djbdns is to support nym-based security."

Hmmm. This reminds me that some web-page updates are overdue; it's time
for me to announce the results of the attacks that the entire Internet
will be panicking about in 2015. :-)

When I wrote that web page several years ago, I focused on deployment
difficulties (which are obviously a huge issue) and delegating security
to poorly managed central Internet servers (which is a big issue for
high-security sites). But there are other reasons, maybe more important
reasons long term, to be dissatisfied with DNSSEC, motivating the
development of DNSSEC2 and DNSSEC3:

* RFC 4033, Section 4: "DNSSEC provides no protection against denial
of service attacks." In fact, DNSSEC makes denial of service even
easier than it was before.

The basic problem is that DNSSEC signs _records_ but provides no
protection for _packets_. After several packets a DNSSEC cache can
see that it doesn't have the expected signatures and that there
must have been forgeries, but the cache simply fails at that point;
it doesn't have any way to find the right data.

With DNSSEC2, every response packet has an immediately and
efficiently verifiable high-security cryptographic signature.
Forged packets are simply discarded.

* RFC 4033, Section 4: "DNSSEC is not designed to provide
confidentiality." DNSSEC doesn't even try to encrypt packets.

In fact, DNSSEC makes private DNS data _much_ easier for attackers
to see than before, because it exposes a huge amount of information
through "NSEC," and creates interoperability failures if NSEC is
disabled. The latest "NSEC3" adds even more complications but does
essentially nothing to repair the privacy leaks; NSEC3 might be
successful at its marketing goal of stopping European privacy
regulators but it will almost never be successful at the security
goal of stopping attackers.

With DNSSEC3, every request and response packet has high-security
encryption and authentication. Both DNSSEC2 and DNSSEC3 completely
avoid the "NSEC" privacy leaks.

* Although the DNSSEC protocol allows some conservative cryptographic
options that won't be broken in the near future, what DNSSEC users
are actually being told to deploy---to partially compensate for
serious speed problems in DNSSEC---is something that big companies
and botnet operators can _already_ break, namely 1024-bit RSA.

We're still years away from a _public_ announcement of a successful
1024-bit RSA factorization, but I think that telling people to

You aren't misinterpreting -- from Dan Kaminsky's blog:

After evaluating several options, one approach was clear -- and, I must admit, somewhat embarassing to Paul [Vixie, primary architect of BIND].

DJB was right. All those years ago, Dan J. Bernstein was right: Source Port Randomization should be standard on every name server in production use.

There is a fantastic quote that guides a lot of the work I do: Luck is the residue of design. Dan Bernstein is a notably lucky programmer, and that's no accident. The professor lives and breathes systems engineering in a way that my hackish code aspires to one day experience. DJB got âoeluckyâ here â" he ended up defending himself against an attack he almost certainly never encountered.

Note the weasel words here, that DJB got lucky and ended up defending against an attack he never encountered. Even while crediting him for being right, Kaminsky won't admit that Bernstein anticipated these attacks several years ago, documented them clearly, and designed djbdns to deal with them as best the broken protocol allows.

In all of Kaminsky's self-congratulatory hype about finding the bug and coordinating the patch effort, he never once suggests the obvious -- that people at least consider using the most secure DNS software available by switching to djbdns.

Steve Friedl is better at crediting Bernstein -- way down near the bottom of the excellent An Illustrated Guide to the Kaminsky DNS Vulnerability Friedl says this:

DJB Was Right

One nameserver is notable for having gotten both the query-id and source-port randomness right from the start: DJBDNS by the legendary Daniel J. Bernstein.

Though long a lightning rod for controversy, he's clearly walked the walk on security: there's never been a security vulnerability in DJBDNS.

The notion that Bernstein drives people crazy and has been a lightning rod for controversy stems from his appropriately harsh and blunt assessments of poorly designed software, particularly Sendmail and BIND. But Bernstein's critics are essentially admitting that for them, correctness is less important than not having one's feelings hurt.

djb drives people crazy (particularly the BIND folks), but he's someone to listen to - is it the case, as I understand from reading through these docs, that in 2001, djb's dnscache performed the port randomization that everyone's been scrambling to deploy over the past several weeks for other implementations, including BIND?

Or am I mis-interpreting here?

You are correct. djbdns was "not vulnerable" (in the same sense that BIND is "not vulnerable" now) to this attack.

As you mentioned, he can be abrasive, but he's definitely contributed some valuable things. See SYN cookies as another djb-contributed and widely-deployed solution to a problem.

Here's something DJB posted to his mailing list on Thursday. Don't know if I'm allowed to post this here but what the heck:

http://cr.yp.to/djbdns/forgery.html has, for several years, stated the results of exactly this attack:

      The dnscache program uses a cryptographic generator for the ID and
      query port to make them extremely difficult to predict. However,

      * an attacker who makes a few billion random guesses is likely to
          succeed at least once;
      * tens of millions of guesses are adequate with a colliding attack;

etc. The same page also states bilateral and unilateral workarounds that would raise the number of guesses to "practically impossible"; but then focuses on the real problem, namely that "attackers with access to the network would still be able to forge DNS responses."

I suppose I should be happy to see public awareness almost catching up to the nastiest DNS attacks I considered in 1999. However, people are deluding themselves if they think they're protected by the current series of patches. UIC is issuing a press release today on this topic; see below.

---D. J. Bernstein, Professor, Mathematics, Statistics, and Computer Science, University of Illinois at Chicago

DNS still vulnerable, Bernstein says

CHICAGO, Thursday 7 August 2008 - Do you bank over the Internet? If so,
beware: recent Internet patches don't stop determined attackers.

Network administrators have been rushing to deploy DNS source-port randomization patches in response to an attack announced by security researcher Dan Kaminsky last month. But the inventor of source-port randomization said today that new security solutions are needed to protect the Internet infrastructure.

"Anyone who knows what he's doing can easily steal your email and insert fake web pages into your browser, even after you've patched," said cryptographer Daniel J. Bernstein, a professor in the Center for Research and Instruction in Technologies for Electronic Security (RITES) at the University of Illinois at Chicago.

Bernstein's DJBDNS software introduced source-port randomization in
1999 and is now estimated to have tens of millions of users. Bernstein released the DJBDNS copyright at the end of last year.

Kaminsky said at the Black Hat conference yesterday that 120,000,000 Internet users were now protected by patches using Bernstein's randomization idea. But Bernstein criticized this idea, saying that it was "at best a speed bump for blind attackers" and "an extremely poor substitute for proper cryptographic protection."

DNSSEC, a cryptographic version of DNS, has been in development since
1993 but is still not operational. Bernstein said that DNSSEC offers "a surprisingly low level of security" while causing severe problems for DNS reliability and performance.

"We need to stop wasting time on breakable patches," Bernstein said. He called for development of DNSSEC alternatives that quickly and securely reject every forged DNS packet.

Press contact: Daniel J. Bernstein

For those that haven't seen it, djb threw up some information regarding this problem and various options a few years ago.

http://cr.yp.to/djbdns/forgery.html

I went and had a look at the thread (dated from Jul 30 2001) referenced in the excerpt at djb's site (follow the posting link in the URL above). As far as I can tell, Jim Reid was pooh-poohing the usefulness of port randomization, the approach used as an emergency backstop against Kaminsky's attach just over seven years later. To be fair, Reid was doing so in the context of advocating for Secure DNS.

djb drives people crazy (particularly the BIND folks), but he's someone to listen to - is it the case, as I understand from reading through these docs, that in 2001, djb's dnscache performed the port randomization that everyone's been scrambling to deploy over the past several weeks for other implementations, including BIND?

Or am I mis-interpreting here?

Or it may mean delegating nameservers by IP address rather than domain name so that resolvers will no longer need to accept potentially-malicious glue records.

Good post. Forgive me for focusing in on this one point and nitpicking it.. ;)

0. Glue used to have a specific meaning: records configured in a parent to help delegate a zone. You (and many people reporting on the current flaws) seem additionally to use it to refer to "additional answers" in DNS replies. While such answers often are glue records, they're not quite the same thing. Least, it didn't use to be. Perhaps the meaning has moved on, but I'll use "glue" in the stricter sense.

1. That's essentially already the case, for in-zone delegations (ie delegating example.com to a name in example.com. like ns.example.com.). The authorative server must be configured with glue, and it must return that glue in the additional answer section for anyone to be able to query ns.example.com.

(Interestingly, DJB has long had a page arguing that "out-of-bailiwick" delegations are bad, amongst other things).

2. Resolvers mustn't treat glue from the delegator as authorative anyway. Resolvers are only supposed to believe additional answers that are in-bailiwick (ie you'll only believe an additional record for/in example.com. if it came from a DNS server you know to be authorative for example.com., e.g. cause you just queried it for a name in example.com.)

3. The problem here is not inherent to glue/additional, but in knowing whether a reply is authorative or not. The only good way to fix this is to secure the DNS chain of trust, either through near-ubiqutious deployment of IPSec+PKI for DNS servers (ha!) or a PKI inside DNS.

For those that haven't seen it, djb threw up some information regarding this problem and various options a few years ago.

http://cr.yp.to/djbdns/forgery.html

Don't want to get owned? Run your own dnscache. http://cr.yp.to/djbdns.html

I really wonder if you're incapable or just unwilling to understand. You have lost this argument long ago because you're not making a point!

Well, but if you so want I will iterate again:

There is no "frequent mishandling" in the "non-root management of daemons" in either daemontools or djbdns. Please quote your "significant security issues" with that because to my knowledge there have been no security issues with djbdns ever. Also please define your term "mishandling"?

Remember, one of the design goals for djbdns was to provide a more secure alternative to the horror that is BIND. According to its security track record it succeeded so far.

Furthermore djbdns is considered by many to be *much* more managable and configurable than BIND. Just compare the configuration mess in BIND (especially the awkward zones format) to the data-format in tinydns that I quoted in my earlier mail. Ultimately this boils down to taste and preference but in no case is it a point to be made against djbdns - much rather one to be made against BIND. Just ask some people who have used both (I have).

Documentation? Again?
Djbdns comes with an exhaustive manual and a truckload of community documentation.

So what remains of your argument? The packaging. We can agree on that but that has nothing to do with security and is probably not the driving factor when choosing an DNS impl.

PS: Work on your reading comprehension. The post you replied to was not mine and the statement "better than bind" that you pulled out of context clearly compared the two on the basis of security problems and bugs, in the same friggin' sentence! That seems like a reasonable assertion to make when comparing djbdns (zero bugs, zero security issues) to BIND (an emberassing number of bugs and security issues), don't you think?

I responded to your original post, included below:

> Use djbdns which is immune to this attack. Dan Bernstein actually described this in 2002 http://cr.yp.to/djbdns/res-disaster.html [cr.yp.to]
>
> djbdns is not prefect but has been better than BIND which had it large share of bugs and security problems.

While djbdns is immune to this attack (good for Dan!), 'better than BIND' has to include a lot more than merely security. It has to include managability, configurability, documentation, packaging, etc. And djbdns reliance on daemontools creates an additional set of issues, including some significant security ones due to the non-root management of daemons and its frequent mishandling.

Ehm, I see you have an axe to grind with djb or how come you spill this unrelated rant, completely ignoring my question? None of your points are security related. In fact, some of them (malloc, "odd layout") are due to him striving for better security. Oh, and lack of documentation... Have you even looked at http://cr.yp.to/ - ever?

Anyways, I'm writing you off as a troll now. Maybe you think it's some kind of geek-chique to rant against djb these days but please, at least get a basic understanding first.

Slashdot ate my url.

http://cr.yp.to/djbdns/dnscache.html

You're right though, my statement was overly broad.

Sorry, but you sound like you have no idea what you're talking about.
Read the qmail security guarantee (bullet 4 under "Why is qmail secure?") to get back on topic.

Sorry, I guess I should have been more explicit. I have seen the claims that BIND v9 was a major rewrite. What I haven't seen are (1) claims that BIND 8 was a major rewrite, or (2) evidence that BIND v9 wasn't a major rewrite. Those are both new claims to me.

That's all right. It should have been parsed as:

• That's from the guy who lied about BIND 8
• That's from the guy who (made) BIND 9 a complete rewrite

BIND 9 was a major rewrite, but not that a major rewrite is a good thing. Completely rewriting your code base is generally considered bad. A majority of BIND 4 and BIND 8 vulnerabilities could have been fixed by mandating chroot, no-root, port randomization, and separate cache+content servers.

BIND 4 was a mere 10,255 lines, but BIND 8 is over 58,288 lines. Of course, it's more fun to simply load it into git and compare the two versions of the named directory- the patch is 20,548 lines changed alone.

BIND8 wasn't insecure because of "design flaws", or because "it was too complicated", or because "it was written in a different time by different people", but because it was written by people who frankly weren't very good programmers.

Paul is a very smart guy, but a lot of the problems with BIND are simple overengineering and complexity issues.

As for my own investigation, I know, looking at the security advisory history for BIND, there have continued to be a steady stream of vulnerabilities due to implementation errors found in BIND 4 and 8, but very little due to implementation errors in BIND 9. (I'm considering CERT VU#800113 and similar to be design errors, which a rewrite wouldn't fix.)

Except, other nameservers don't have the vulnerability.

The ADDITIONAL-section processing has been the root cause of almost all poisoning attacks. DNS caches that don't have additional-section processing have always been immune.

I'm somewhat willing to forgive the BIND people for certain things, but an outright lie would be another matter entirely.

I'm not. The BIND group has made a number of enormous design errors over the years that have been defended by hubris and ego. I don't trust them at all.

• 2001.01.29 23:25:06, Paul Vixie*, on bsdi-users: ``See BIND9. Written by a new team, sharing no code with BIND8. Two years in the preparation. 6+ months of testing. ... BIND9 is a complete rewrite by completely different (read: better) people.'' (In fact, the team was not ``completely different.'')
• 2001.02.04 06:32:01, Paul Vixie*, on bind-members: ``We've spent more than $2.5M on BIND9, which is a complete rewrite, and which took a dozen senior or supersenior DNS software experts over two years to complete.''
• Finally, at least Michael Graff worked on both BIND 8 and BIND 9

Ignore for a moment that the claim was wrong, and just bask in the stupidity of the claim that the super senior DNS software experts had never written a name server before (because they didn't work on BIND 4 or BIND 8).

I'm not a djb fanboy but I have to counter one of your points:

the 'daemontools' package he uses to run his software is extremely dangerous in most environments because it hands off control of daemons to non-root users

How is handing off control of daemons to non-root users dangerous?
Djb goes a long way in terms of separation of concerns here, qmail for example runs with no less than seven different userids. Attacking Dan's software for a lack of security is a bit like preaching to the pope. Have you looked at his security track record recently?

I do agree with your other points, though, especially with the awkward packaging and the (past) licensing problems. I have recently converted from qmail to postfix because I got tired of the patching and so far I'm not missing anything.

It's a different story with dnscache/tinydns, though. I have still not found a viable replacement for these. It's not just the immunity to this recent exploit here, it's the whole design. Yes, dealing with daemontools is annoying at best. But dealing with the bind zones-format would be so much worse! The tinydns data format is a strike of genius. Until someone comes up with something comparable or just clones the format you'll have to pry djbdns from my cold, dead fingers...

1. Licence

2. With possibly the exception of qmail, you can put everything anywhere you like. The /service path location is only hardcoded in svscan, for instance, and the other weird paths such as /command are only used in the install scripts, which you probably don't want to use anyway.

3. I wish there was a credible alternative to djbdns. I only know of PowerDNS, haven't had time to try it yet, what about the others? Bind is a non-starter for me, just like sendmail (but Postfix is ok).

Use djbdns which is immune to this attack. Dan Bernstein actually described this in 2002 http://cr.yp.to/djbdns/res-disaster.html

djbdns is not prefect but has been better than BIND which had it large share of bugs and security problems.

Unfortunately, as Vixie admits, DNSSEC has intractable problems and is... well, let's be generous and say "pushed too quickly through the standards process". (See http://cr.yp.to./djbdns/forgery.html; in particular, Vixie's observation 'We are still doing basic research on what kind of data model will work for dns security. After three or four times of saying "NOW we've got it, THIS TIME for sure" there's finally some humility in the picture... "wonder if THIS'll work?" ...' [this was _after_ several DNSSEC RFCs were approved and intended to be implemented were shown to be utter crap.])

Encouraging people to use DNSSEC is just about as useful as encouraging people to use HOSTS.TXT. OK, I exaggerate a bit, but it's simply not going to solve the problem, is going to expose zones to arbitrary enumeration (remember, The Internet community discouraged answering AXFR requests from the Internet at large presumably for a reason), and is going to introduce much larger computational demands of DNS servers that implement it.

(Here's a thought: most of this forgery comes from my ability to guess your DNS cache / resolver's query port and request ID. Come IPv6, we could surely add 48+ bits of entropy to the process by having DNS servers listen on a prefix of addresses. Much simpler, if gross.)

Not exactly.

This flaw was well known in 1990. Paul Vixie has been dragging his feet for almost twenty years with crack-potted shit like "additional credibility rules" and extra complexity.

How to fix this bug trivially was well known over ten years ago and still the ISC has been refusing to secure its users because they want to push DNS-SEC- a security system based on a trust hierarchy that doesn't exist, whose implementation has never worked, and will never work because Paul is a fucking idiot who cares more about his own ego than just admitting he was wrong and learning to live with it.

Look even now:

Second, take Secure DNS seriously, even though there are intractable problems in its business and governance model

He can't help himself. He's a douchebag, and I hope he just leaves the Internet business forever. We'd all be much better for it.

Here's a description of pretty much the same attack, with pretty much the same solution recommended, back in 2001: http://cr.yp.to/djbdns/forgery-cost.txt

I'm sure the half-dozen people who are actually using IPv6 right now are terribly devastated by that.

Wait, no, there's not even that excuse. There's a patched version--since djbdns is now public domain, you can just grab Debian's dbndns package, which includes IPv6 support.

It's possible that there is more to this than what I have divined from the 'uber-secret-vendor-only' disclosure but this seems to be little more than traditional cache poisoning with random-number-generator (RNG) prediction. Both of these situations have been well known and documented within the security community for a number of years.

Cache poisoning was predicted long ago by Dan Bernstein (as mentioned by a previous poster or two)[1]. (Nobody listens to me either, DJB.) The combination of this and RNG prediction was wrapped up nicely by Joe Stewart in his 2002 (I think) paper [2]. Joe used Michal Zalewski's free TCP/IP sequence number prediction software [3] to visualize random number generator attacks on DNS responses from various resolvers. The paper is well worth a look if you made it through the last sentence and are still reading this one.

Incidentally, Paul Vixie (BIND author,) posted a potential fix to this (or a surprisingly similar) problem to the Namedroppers mailing list at the end of February [4]. Time will tell whether the two events are connected.

This whole saga appears to be another case of 'marketing department run amok' but we'll have to wait for the BlackHat presentation to find out if all of this is just regurgitated previously ignored security advice.

[1] http://cr.yp.to/djbdns/dns_random.html
[2] http://www.lurhq.com/dnscache.pdf
[3] http://razor.bindview.com/publish/papers/tcpseq/vseq.tgz (currently down)
[4] http://www.ops.ietf.org/lists/namedroppers/namedroppers.2008/msg00378.html

http://cr.yp.to/distributors.html

As of December, the software is in the public domain. No licensing issues. If you would like to take on a distribution that has been patched, please feel free.

DJBDNS actually IS superior. It is lighter weight and more secure. And it has addressed this issue as best you can for more than 5 years.

... because djb recognized the vulnerability. it's even documented as such: http://cr.yp.to/djbdns/dns_random.html

http://cr.yp.to/export.html

No. Its not trivial to block SYn flods (which is what this was), but its not magic either: http://cr.yp.to/syncookies.html / http://en.wikipedia.org/wiki/SYN_cookies

the few Freedom wrinkles in the license.

You might be interested in D.J.Bernstein's Internet Mail 2000 concept for sender-stored email.

http://cr.yp.to/im2000.html

You are djb and I claim my $1000.

Internet Mail 2000