Slashdot Mirror

If you haven't seen this yet you might want to read it: http://cr.yp.to/djbdns/ipv6mess.html

"unless something dramatic changes in factoring" Something like using ATI and NVIDIA GPU's to accelerate factoring? something dramatic like that? http://eecm.cr.yp.to/pc109-20090901.pdf If you take the latest in CPU/Multi GPU configurations; and build around the idea of operating them for this purpose, i think RSA-1024 could be cracked in a similar amount of time. Far less than 10 or 5 years. Their paper doesn't make any references at all to GPU accelerated factoring, it's not even on their radar. http://fastra2.ua.ac.be/

Unfortunately, most ECC is patent encumbered.

Well, djb wrote a particular algorithm, Curve25519, that's in the public domain.

(Yeah, yeah, save your comments about djb's personality. Like it or not, the guy's a crypto and security genius.)

http://cr.yp.to/ ignores the meaning as well :) But its a cool domain to own.

Caching resolver, not server. Anyhow, why on earth would you do such a thing? The only reason to use Google's resolver is to save yourself the effort of configuring your own. Once you've installed the software, you may as well let it do the work.

I run dnscache on every PC I have or administer that isn't stuck on Windows.

I'm sure there are some people in the computer security world who you admire. So ask yourself, what would these people do if they had discovered the exploits? What would Phil Zimmermann, or DJB do? Some of these people were unhappy with the current situation, and took their own road and created some good, secure software.

Also, maybe your code isn't as good as you claim. Or maybe it mostly uses known exploits. It's time for a reality check. You should try to find some peers, and discuss it with them to determine how dangerous your product really is.

While you're explaining, can you tell us why DNSSEC makes the size of the DNS zones "unwieldy"?

DJB held an interesting keynote at USENIX WOOT this year, on some of the unintended side-effects of DNSSEC. Here are the slides: http://cr.yp.to/talks/2009.08.10/slides.pdf.

The biggest issue he found was that the a single, small DNS request triggers a huge DNSSEC response with lots of digital signatures (each one of which is at least 1024 bits...). Since the requests are sent over UDP, they can be spoofed. End result? a HUGE DOS amplification effect.

What about Internet Mail 2000?

The Spammer needs to hold all the emails on their own email server until the client email program decides to download it. Email which is never collected will take up storage on their server and they can't fly by night since if they disconnect the server then the email will never be delivered.

There isn't any working implementation AFAIK but you did say "proposed replacement".

You had the balls to sue the United States Government. http://export.cr.yp.to/

Dan Bernstein has chimed in on this before:

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

He is basically dead right.

The people who came up with IPv6 seemed to be too ivory tower: they forgot about
the reality on the ground. Few ISPs are even thinking about IPv6.

-paul

I considered using djbdns until I stumbled across his inflammatory and borderline-fanatic attitude against BIND. What the hell, man? It's just a DNS server. Get over it.

Come on people, still using BIND? Why don't you use djbdns? It's easier to use and has a guarnatee!!!

Come on people, still using BIND? Why don't you use djbdns? It's easier to use and has a guarnatee!!!

Come on people, still using BIND? Why don't you use djbdns? It's easier to use and has a guarnatee!!!

It is now.

This vulnerability also gives the three people running DJB DNS a much needed opportunity for some smugness.

Somewhere I think djb is managing to both smile and raise his eyebrows simultaneously.

Depending on what you call a revision, Bernstein just revised CubeHash. A few days ago he posted a parameter tweak that significantly increases performance at the cost of some security. You can read about his tweak on his website at: http://cubehash.cr.yp.to/submission/tweak.pdf

Coming up on celebrity death match we have Dan Kaminsky vs. Dan J. Bernstein. Let's stay tuned. In all honesty I tend to agree with the notion that SSL is joke and hence DNS based on SSL is just as bad. SSL suffers from many flaws that most people are either don't know or choose to remain ignorant too based on the popular notion that SSL is safe. SSL relies on you trusting a third party as being secure when it only takes one corrupt employee to violate the sanctity of a PKI private key. Verisign, the globally trusted "omnipotent" master of SSL dropped the ball hard a year to 18 months ago when their subsidiary RapidSSL had their md5 private key broken, this coming from an SSL provider who was (and probably will remain to be) globally trusted by all browsers. This means the broken key can be used to generate SSL certificates for any domain you choose and knowing from my personal experience those certs were not revoked and fresh and updated installs of FF3 and IE8 still accept them. Not only can an employee be corrupted and an SSL provider who is trusted fall prey to cryptographic hash collision but a certificate provider can still be compromised and their are enough providers out there trusted by almost all common browsers that surely one of them must be vulnerable to being cracked and having the private key taken. Additionally DJB pointed out ( http://cr.yp.to/djbdns/bugtraq/19991114052453-12962-qmail@cr-yp-to ) that by using a spoof and having it redirect to a similarly named http host with a proper valid certificate, the average user and even some of the more advanced users can likely be conned into trusting a site based on valid SSL certificates when the site is run by a hacker so, credit to Dan Kaminsky where it's due, this was a brilliant discovery to say the least and I thought so when I read it a year ago but DNSSEC is as much fools gold as SSL always has been.

No, but he did get tons of publicity for a design bug that has been known about since the early 2000s. http://cr.yp.to/djbdns/forgery.html

Here's the entire code for Bind 10:

wget http://cr.yp.to/djbdns/djbdns-1.05.tar.gz

Also take a look at the excellent stralloc which is also part of libowfat.

He could switch to OpenDNS...er...never mind....

$ cat /etc/resolv.conf
nameserver 208.67.222.222
nameserver 208.67.220.220

$ host opendnssucksabigone.com
opendnssucksabigone.com has address 208.69.32.132
Host opendnssucksabigone.com not found: 3(NXDOMAIN)

$ host 208.69.32.132
132.32.69.208.in-addr.arpa domain name pointer hit-nxdomain.opendns.com.

Whoops!

OpenDNS and the ISPs that use them always f*cks up my shell sessions when I mistype a hostname, since it goes straight to their server and instead of receiving a SERVFAIL or NXDOMAIN.

Alternative? Run your own DNS cache/resolver

I suspect many people don't have a choice. Of the two broadband providers who serve me, all three do this. The local cable company (Charter) turned it on. When their tech support proved unable to even understand my complaint, let alone fix it, I bailed. Months later the new company (TDS Telecom) started doing it. At least their tech support understood me, but they were unable to turn it off. Sure, I can use OpenDNS, or pinch DNS service from elsewhere, but providing functional DNS is a reasonable baseline of service. Welcome to the race to bottom of quality, thanks to the "free" market.

I've been very happy running my own local, caching DNS server. It communicates directly with the root DNS servers, no middleman required. It's also noticably faster for normal Web browsing because there is less latency when a lookup must be performed and effectively zero latency when a result has already been cached. I've been doing this for years and years, before anyone (to my knowledge anyway) decided that hijacking DNS queries was ever a desirable business practice (it isn't).

What follows is my opinion, though it's an informed one. The only thing I'd strongly recommend is to avoid using BIND. It has a terrible security history, comparable to that of Sendmail, which is fitting since both hail from an era before the Internet was considered a hostile network. The recent rewrite of BIND doesn't seem to have done much to change that. I used to use djbdns but I've switched to maradns and have been extremely satisfied with it. It's small, lean, secure, and generally it does everything I want it to do and nothing that I don't want it to do.

When ISPs overstep their bounds and start hijacking traffic when I have neither asked them to do so nor want them to do so, my answer is simple. Please pardon how I put this, but to them I say "fuck that" and run my own. I'd recommend this approach to anybody, and not just because I believe that relative independence is a virtue.

I'm not sure which part you're referring to, but as with many others, I didn't care, I use djbdns, not bind.

Just a question, but what's wrong with hacks? :) I love a good hack.

More importantly, what on earth is hackish about trigger files?

Also, I don't use cron for such jobs, I use daemontools.

At one point Internet Mail 2000 looked like a nice idea. Quick summary: sender basically "publishes" the outgoing email on their server (or their ISPs server), and sends a ping to the recipient saying where it is.

This has the advantage, for spam tracking, that you have to have a valid IP address for the sender, which can easily be checked against blacklists. ISPs that detect a spam-run in progress can just drop all the spam from their server, and only recipients that have been really quick on the ball about responding to the pings will get the spam. Also, if a spam filter can make a decision based on the contents on the ping, the whole message doesn't have to be retrieved.

Looked at another way, it's basically just publishing a private blog entry and sending a notification ..

FreeBSD has no problem running Linux binaries, linux binary compatibility has been there for years, I used it to run linux binaries that hadn't yet been ported to FBSD yet in 97, I still run several Linux binaries on my FBSD servers.

Does this actually work 100%? How?

And, yes, I understand you can do syscall emulation. But what about what happens behind the interfaces. For instance I find it hard to believe that TCP_CORK/mremap/epoll/etc. "works" when FreeBSD has refused (decided not to, whatever) to natively support it for years now. AFAIK FBSD doesn't have splice()/tee()/etc. either ... do they hack some of this in userspace?

But even that seems like the easy stuff, what does FBSD do when I open("/proc/*") and start parsing stuff? What about closing sockets that are only referenced in the poll() call of another thread? Anything that hits the drivers "deeply" like X, pulseaudio, etc. seems like it'd be impossible to support. SELinux is just not going to work, probably dito. somewhat releated stuff like the audit interface / netlink (maybe that classifies as "deep" driver knowledge though).

Then there's the really crazy stuff where you have the same interfaces natively but they operate subtley differently in weird corner cases, DJB has a page on some stuff, but I doubt anyone sane enough to have commit privs. knows all of these (if anyone at all does).

The last two systems I've built for myself have used ECC memory, because I feel the same way about it that you do. I've found that ASUS motherboards, at least for 64 bit AMD CPUs, always support ECC, and few others (Tyan is one that does) do. If the manufacturer doesn't specifically state that they support ECC, they almost certainly don't. (There was even a case years ago where a manufacturer that claimed that they did support ECC, namely Abit, didn't!) So you could get a situation where you have an ECC-supporting memory controller (on an AMD chip), and ECC ram, but the motherboard they're plugged into isn't designed to allow it. It sounds stupid, and it is: a lot of these manufacturers are really stupid. Earlier in the comments for this story someone mentioned how they'll sometimes automatically overclock the memory or CPU under load, or set the clock speed of "overclockable" memory high without adjusting its voltage to the correct settings for that speed.

I've only ever built with AMD, so that's all the advice that I can give for now, aside from mentioning that the new i7 CPU from Intel doesn't support ECC at all. So avoid that one.

Since nobody's mentioned it yet:

More recent versions of Red Hat come with EDAC (formerly known as bluesmoke) enabled and will throw parity errors to the syslog ...

http://bluesmoke.sf.net/
http://buttersideup.com/edacwiki/Main_Page

Its predecessor, Linux-ECC, also has a plug by DJB for its use with some decent details:

http://cr.yp.to/hardware/ecc.html
http://www.anime.net/~goemon/linux-ecc/

How many of you are running domains like this? It's not something I need to bother patching for.

When I first discovered this bug and started to think of how to exploit it, I was very hesitant of whether it would actually qualify for exactly this reason.

However, just because most djbdns installations aren't setup this way doesn't mean it can't affect a lot of users. I'm specifically thinking of services like FreeDNS (freedns.afraid.org).

Now, FreeDNS uses BIND instead of djbdns, but they allowed me to register burlap.afraid.org and set it up with arbitrary DNS records transferred from AXFR. If they were running tinydns/axfrdns, I could have used this bug to poison the A records for ns[1234].afraid.org, and then taken over all 250,000 domains they host.

EveryDNS does use djbdns, and I was able to trigger this bug on their servers, but because I couldn't register burlap.everydns.net, I couldn't actually trick any DNS caches with it. If they did allow me to register that domain, however, I could have taken over all 280,000 domains they host.

I seem to recall other sites that used to allow you to register free third-level domain names, but can't recall any off-hand. If they used djbdns and allowed AXFR slaving, they would be at risk.

There are also a handful of third party DNS providers that use tinydns/axfrdns. DJB lists on his djbdns blurb page "directNIC, MyDomain/NamesDirect, Interland, Dotster, Easyspace, Namezero, Netfirms, and Rackspace Managed Hosting". I did confirm that some of these run tinydns/axfrdns, but I have not looked to see if any of them allow you to register subdomains of their own. If they did, you would be able to take over all of their customers' domains.

So I don't expect a lot of users are at risk to need to install this patch. However, the users that do are more likely to put hundreds of thousands of domain names at risk if they don't.

-- Matthew

Terminate them with ',' (comma):
http://cr.yp.to/proto/netstrings.txt

Just read wiki and the following paper (2002): http://cr.yp.to/djbdns/forgery.html
Two most secure implementations of DNS servers Djbdns and MaraDNS are not even bother to implement this until they see (1) a stable, sensible DNSSEC protocol and (2) a detailed, concrete, credible plan for central DNSSEC deployment.

MD6 by Rivest and Skein by Schneier et. al. seem to be getting a lot of attention, but another celebrity cryptographer, Dan J. Bernstein, also has a hash in this race, called "CubeHash."

DJB continued his tradition of offering cash rewards for people to find security problems with his code, giving out (so far) monthly prizes of 100 Euros to the most interesting cryptanalysis of CubeHash.

So far, the primary criticism of CubeHash is that it's slow, running some 10 to 20 times slower than many of the others in the competition. Dan brushes off this criticism by stating on his site: "for most applications of hash functions, speed simply doesn't matter."

To be honest, when compared efforts like MD6 and Skein, with their mathematic proofs of security, VHDL and other in-hardware reference implementations, and their amazing optimizations in both speed and efficiency (Skein can process half a GByte of data per second on modern hardware, and consumes only 100 bytes) -- entries like CubeHash seem to have that longshot underdog appeal, like a New Zealand soccer World Cup team.

"slash" would be a fun TLD. "x" alone would be too. One of the fun domain names I never forget is cr.yp.to made possible by the "to" ccTLD.

I can see major companies buying their own names as TLDs to create domains like "ftp.dev.intel" or "update.office.ms"

I started to RTFA when something caught my eye: "his discovery of a significant DNS flaw -- known as the Kaminsky Bug"

Except Kaminsky wasn't the original discoverer of this bug (or the workaround). Dr. Bernstein is. Dr. Bernstein discusses hte Kaminsky bug here; that page has been around since about late 2000.

For the record, I am no fan of DJB. I feel he has acted unprofessional and childlike at time; his response to an announcement of my DNS server on Bugtraq being just one example of his inappropriate behavior. But, personal differences aside, I recognize he's a genius and that he's the original discoverer of this particular DNS issue.

(I also wish DJB would own up to the remote denial of service bug DjbDNS has, but that's another issue)

In my opinion, the transition to port 587 is nearly pointless. I already use authentication on port 25 to identify customers.

And according to one of the only people I'd trust on SMTP issues, "the SUBMIT specification has several fundamental flaws that make compliance practically impossible. I advise against all use of port 587" -- djb.

Not that djbdns is absolutely bulletproof but Dan Bernstein spoke about this for dnssec awhile back:
http://cr.yp.to/djbdns/forgery.html

For such a use, data loss isn't a big deal; your cache directories blow up, you re-create them, and restart your cache server. I had a similar setup first with Linux/Murder^H^HReiserFS, then with NetBSD/LFS. If the fs where the cache spools were stored got screwed up, I'd just re-make the filesystem.

Softupdates maintains synchronous operation, while giving the illusion of async. Anything that wasn't written before the machine went down is just gone. And an unclean shutdown still requires an fsck after reboot. FreeBSD allows for backgrounding this.

Journalling keeps track of what has actually been put on the disk. It's still not secure for things like mail (this is true of Postfix, too), but it's a lot better for general use.

*ANY* physical change to IPV4 breaks IPV4. Given that assumption, we may as well start from scratch, and go back to square 1 when designing IPV6.

Well, that's not really true (both of those). IPv6 addresses are their own namespace, and can't communicate with IPv4 addresses automatically. Think of how FAT got long filenames ... or how DNS grew extra TLDs like .info ... or how MX and SRV records in DNS started showing up, although using regular A records for mail and other services still works.

If you extend IPv4 in a clever way, rather than rewriting the whole thing and coming up with a new address space, you can increase adoption because people don't have to get everything upgraded end-to-end to make your system work.

Here's an example of such a scheme. Let's call it IPv4+. I'm going to say that it uses 64 bit addreses (but only because that's convenient). The first 32 bits are an existing IPv4 address, and if you own a single IPv4 address you own all 2^32 IPv4+ addresses that start with the IPv4 address. Allocation works as normal, etc. Maybe for good measure we'll take an IPv4 class A (1.x.x.x?) and reserve it _just_ for IPv4+ allocation.

So the first thing that happens is that everyone who uses NATs already has a convenient address. If my home IP address is 18.242.0.29, and my desktop behind the NAT is 192.168.0.2, then if I want a public IPv4+ address I can just use 18.242.0.29.192.168.0.2.

The next thing that happens is, if I want to reach that machine from a part of the Internet that only supports IPv4, I can tunnel IPv4+ inside IPv4. (I can even use an existing standard like RFC 1853) or something. The routers that don't need to be upgraded just see the outer header that says to send it to 18.242.0.29, and they use existing BGP or whatever and send it on its way. Once it gets to 18.242.0.29, which does support IPv4+, it figures out how to reach 18.242.0.29.192.168.0.2. Note that none of the backbone needed to be upgraded: I just need client and server support for IPv4+. End-to-end, if you look at it like an IPv4 packet, it gets routed correctly by the existing Internet.

So, there are two benefits of this strategy. First is that you use an existing naming scheme (IANA assigned IPv4 addresses) and build on top of it. The second is that you use an existing protocol and build on top of it, and only the machines that care about IPv4+ address space need to upgrade to IPv4+.

IPv6 does neither of these. Dan Bernstein condemns IPv6 much more scathingly than I can, having been part of the IPv6 discussions, but he basically agrees with me.

You can with clockspeed/taiclock. http://cr.yp.to/clockspeed.html

IIRC clockspeed/taiclock are good at handling leap seconds vs. NTPD: http://cr.yp.to/prot/utctai.html

See here under 'What's the problem?'

Implementations are interesting if they use new techniques.

Ehhhh, perhaps in other cases. Compact Javascript and G4 assembly however aren't examples of a cryptographers particular prowess.

Meh, it's a quals paper. Should be sort of interesting, though... I'm not aware of anyone using a vector permute unit to do subfield arithmetic in constant time before.

The identity schemes are published in FOCS and Asiacrypt.

Well that's helpful.

Oh, you actually want to read them? I thought you just wanted me to prove my cred. They're posted on my website.

Implementations are interesting if they use new techniques.

Ehhhh, perhaps in other cases. Compact Javascript and G4 assembly however aren't examples of a cryptographers particular prowess.

The identity schemes are published in FOCS and Asiacrypt.

Well that's helpful.

I personally find djbdns easier to use and less error prone than BIND for most stuff ( http://cr.yp.to/djbdns/blurb/easeofuse.html ).

If you want to manipulate DNS records with perl, the djbdns format is much simpler than BIND's.

Yes it is different from BIND, but different can also be better.

Postfix's main.cf is different from sendmail.cf but much simpler(yes I know about m4, but honestly is it really simpler than Postfix? ).

The ISC have a long track record for producing hard to manage stuff with security problems.

It's no surprise that DNSSEC is a bad design (it's a good way for corporations like Network Solutions/Verisign to extract more money from people tho).

http://www.dnscurve.org/dnssec.html

I did

You need to work on your reading comprehension then.

DJBDNS supports all RR types, by way of generic RR support. See near the bottom of this page for details.

There is a series of patches that produce friendly syntax for tinydns-data, a single component of DJBDNS. This isn't valuable to large sites who don't source with tinydns-data's built-in format.

Too bad it does support AAAA records and SRV records.

No it doesn't. The official release, version 1.05 on his site, doesn't support serving AAAA records and contains no mention of SRV at all. Go ahead: download and grep for it. There are patch unofficial versions that do all sorts of things, but by that standard any software supports just about anything.

After the smashing success of Internet Mail 2000 he would be a fool not to!

Ah, the IPv6 Mess.

Glue distrust isn't that big of a deal.

Well, technically, glue trust is a big deal. It enables corruption of existing domains. That's a big deal. I think your point is that there are other, overshadowing problems. That may be the case; I am only familiar with this aspect of how DNS poisoning is a big deal. What specific problems arise from being able to add arbitrary subdomains in a browser context?

And, no offense to DJB, but port randomization is not by itself a sufficient response to the birthday attack. Come on, we've known not to have simultaneous outstanding requests for the same name for the last six years.

Port randomization helps. I don't think there's any offense to be had on DJB's part; port randomization was never said to be sufficient. Defense in depth means doing what you can where you can, "practical mitigation". DJB advised port randomization (and non-colliding queries) at least seven years ago. The CERT advisory came out a year later.