Slashdot Mirror

The biggest problem I see with this attitude (not that I entirely disagree with it) is that it assumes NAT will go away in v6.

What's more likely, if IPv6 does catch on, is that NAT will be replaced by IPv4 to IPv6 tunnels.

But I seriously doubt this is going to happen. Redesigning everything from scratch is a software engineer's wet dream, but in the real world for a system to work it needs to be much more backward compatible than IPv6. It's like DJB said: "The IPv6 designers made a fundamental conceptual mistake: they designed the IPv6 address space as an alternative to the IPv4 address space, rather than an extension to the IPv4 address space."

Interesting that you bring up student unions. In Chicago, apparently it is politically incorrect to call them student unions. As a result, my University renamed our student unions from "Chicago Circle Center" and "Chicago Illini Union" to "Student Center East" and "Student Center West".

Needless to say, everyone ignores the official names.

Staying on topic, I would like to point you to DJB's page on this issue:

http://cr.yp.to/patents/tarzian.html

Apparently my University adopted a similar policy in 2003 and this prompted DJB to come up with patentable intellectual property for them: things like a "coin operated elevator" and a "soap saver dish". Beautiful.

Oh, god, I sound like a DJB fanboy... but he makes a good point here. It's not that I or anyone else can't figure it out, it's that I shouldn't have to figure it out. I should only have to learn how to start Apache once. Maybe it's cause I'm used to my Mac JustWorking(tm).

http://cr.yp.to/publicfile.html, publicfiloe, is not mentioned.

D.J. Bernstein's Poly1305-AES seems like an interesting alternative, it's in the public domain.

No.

Real crypto (they type the government uses to protect top secret data) is free:

• Public domain C/C++ AES code
• DJB also has a public-domain C and assembly AES code
• Dr. Gladman has some simple BSD licensed (usable in any commerical closed-source program) C/C++ and assembly implementations of AES
• There are some GPL implementations of AES available, for people who can handle the GPL being in their code. (GPL forces the release of source code)
• This Javascript page will help people writing AES in other languages

I have not RFA since the site is Slashdotted right now. However, I think there is legal precedent for code being a protected form of free speech. See DJB's page on the subject where he was able to, to some extent, override the ITAR export regulation arguing that code is speech.

I am opposed to people pirating media and making it available on the internet. However, I am more opposed to court decisions allowing people to make fair use of their copyrighted material. The software industry has survived piracy for decades; the media industry will survive also as long as people realize that pirating music and movies is wrong (which is why I flame idiots on Slashdot who think they have a God-given right to free movies and music).

I'd be interested to see more devices embedding 6to4 routing, so that IPv6 can be transparently added while not interfering with the user's normal use, while adding access to the IPv6 space without requring tunnels or seperate addressing to those already assigned. This kind of transparent, background rollout would begin to address the issues that djb identified with the move to IPv6. If i could benefit from IPv6 without disrupting my IPv4 communications and not having to set up routing and tunneling manually, I would find myself taking advantage of that ability wherever possible.

Some people think incremental steps like this will somehow help IPv6 rollout worldwide. I think that is a completely different problem, and very hard to solve. Any volunteers to solve the hard and difficult problem?

The best description I know about The Problem comes from Dan Bernstein, The IPv6 mess.

The IPv6 designers don't have a transition plan. They've taken some helpful steps, but they typically declare success (``IPv6 support'') when the real problem---making public IPv6 addresses work just as well as public IPv4 addresses---still hasn't been solved.

The whole Internet is reachable through IPv4, only a small portion of it is reachable through IPv6.

Dan J. Bernstein explains the problem perfectly well here as well as suggesting a solution.

D. J. Bernstein has a really nice page that explains why the current IPv6 transition plans are a joke. It's worth a read if you're interested in IPv6.

No, the vulnerability is very much specific to hyperthreading.

No it isn't.

Without hyperthreading, there would be no practical way to get sufficiently detailed information for an attack (not without physical access to the CPU to do DPA or something similar).

Yes there would. As shown for example here.

Cache observation attacks have been theorized as a possibility for quite a while, but this paper shows that hyperthreading has finally made it easy enough that it can actually be done.

DJB's paper shows that it can "actually be done", and he's using an Athlon, not a P4. This is a cache timing attack and they are as old as caches are.

The solution is not to disable HT or wail about how it's a "security hole"--because we know that the same attacks can be made on any system that either multitasks or has a cache too small for the lookup tables. It's to use high performance encryption algorithms that have neither data nor key dependencies, which means no table lookups. There are a number of them out there. AES just isn't one of them (it can be high performance, or it can be free of data and key dependencies, but thus far it doesn't appear that it can be both).

You simply are wrong- even the most tiny slice of time is meaningful- want a recent real-life example?

http://cr.yp.to/antiforgery/cachetiming-20050414.p df

As djb pointed out, cryptography can be made immune from timing attacks by implementing it using constant-time (not data-dependent) operations. Granted, doing without precomputed tables is very expensive, more so for some algorithms than others.

I'm really not convinced that they wouldn't have listened, or that waiting 2 or 3 months helps to have them listen.

Maybe posting your early ideas on crypto-related newsgroups would have helped in order to quickly get a paper about cache timings attacks so that people can protect their servers as soon as possible.

My guess is that this is going to be an application of a known (recent) result from djb, that hyperthreading can introduce some serious vectors for timing attacks. See this paper.

I've said it before, and I'll say it again, why isn't everyone using Djdns? I've set it up on my home network server running FreeBSD to provide dnscache for all my boxes within 192* and thus far it's working perfectly. From Djdns' security page, it says that it's impervious to DNS poisoning (an perhaps the hack that took down google?): "dnscache does not cache (or pass along) records outside the server's bailiwick; those records could be poisoned. Records for foo.dom, for example, are accepted only from the root servers, the dom servers, and the foo.dom servers." "dnscache is immune to cache poisoning." Djbdns While I don't think I'm in the clear because of this, I feel better protected from the (unwashed ;)) internet. Anyone care to comment, please do, as I've just started using this and want to know how effective it is. bo

DJ Bernstein Will Tell You Why

Among my favorite advice of his is to completely give up on the standard C library. Really, everybody should have done it a while ago. It's one of those things like the unix pipe model that was a good start, but now that it has hung around for 25 years, it needs an upgrade. How about everybody stop using the standard C library and switch to something like the Apache Portable Runtime?

Write bug-free code. I've mostly given up on the standard C library. Many of its facilities, particularly stdio, seem designed to encourage bugs. A big chunk of qmail is stolen from a basic C library that I've been developing for several years for a variety of applications. The stralloc concept and getln() make it very easy to avoid buffer overruns, memory leaks, and artificial line length limits.

daemontools and the free-er clone runit which both give you the advantages of a non-linear system startup process, automatic service restarting, no need to write daemon-ising code in each program etc. Each author also has common tools to use with these service supervision programs to ensure network-based daemons don't need to write network code: ucspi-tcp and ipsvd respectively.

Brave Deian owners can apt-get install runit-run which will start your system with /sbin/runit instead of init from then on; we tend to use it on top of the existing init scripts.

And the system that's had such a sensible service supervision system since the year dot? Windows NT and its service control manager. Of course you could argue a centrally-controlled daemon restarter is much more of a priority when you expect your daemons to crash more :-)

daemontools and the free-er clone runit which both give you the advantages of a non-linear system startup process, automatic service restarting, no need to write daemon-ising code in each program etc. Each author also has common tools to use with these service supervision programs to ensure network-based daemons don't need to write network code: ucspi-tcp and ipsvd respectively.

Brave Deian owners can apt-get install runit-run which will start your system with /sbin/runit instead of init from then on; we tend to use it on top of the existing init scripts.

And the system that's had such a sensible service supervision system since the year dot? Windows NT and its service control manager. Of course you could argue a centrally-controlled daemon restarter is much more of a priority when you expect your daemons to crash more :-)

How does launchd compare to something like daemontools?

Not the dependency handling, etc, but reliability, lightweight, guaranteed behavior in several circumstances, ease of use and configuration, etc., etc.? Is XML involved in any way? :-)

Just curious.

Switch to using FAM (File Activity Monitor) on both systems. It's a daemon implemented on top of kqueue (on *BSD) or dnotify/inotify (on Linux). It talks to instances on other machines to work properly across network filesystems. It also abstracts the underlying API for you. It just gives you a file handle to plug into your monitoring loop, and an API to call when it has input. No need to care if it's using kqueue, dnotify/inotify, or (in the worst-case scenario) a timed loop on the backend.

There's your practical answer. If you'd like to know why you can't directly see when a file handle grows with select/poll, read on.

The thing is that regular files and socket/pipes/character devices are treated in a fundamentally different way on Unix systems. Sockets have nonblocking IO and select/poll. Regular files have much less support - a separate, nasty async API on some systems, and inotify/dnotify on Linux/kqueue on BSD for notifications. (Something on IRIX...they built fam there, after all.) This doesn't make a lot of sense and people like DJB have argued that this doesn't have to be, but...well, that's still how it is.

kqueue is no exception. They've grouped a number of things into the same system call and made it more convenient to safely wait for several types of events at the same time, but you still can't treat them in the same way. On Linux the equivalent of kqueue is accomplished through:

• epoll
• dnotify/inotify signal handlers
• ptrace? I don't remember how you watch processes off-hand.
• more signals for async IO

The biggest pain there is handling signals and epoll stuff simultaneously in a correct manner. If you need to, I urge you to check out the documentation for my sigsafe library. It describes some things not to do plus a couple good ways: the self-pipe trick (a popular way if you're using select/poll/epoll) and my own sigsafe_* signal call wrappers.

This is a slugfest that only Gates, Darl, and RMS would love

I disagree. tdr and djb would love it too.

Thank you for the response! This explains quite a bit. So it's really the applications which are bad about interoperability. What could distributions do to fix this? It seems that

And for people insisting on rolling their own everything, I think D. J. Bernstein is the king of that, what with his daemontools and all. I suppose it's a good idea, though I can't say that with any authority... it just seems a bit odd that he's decided to add things to the root directory. To the root directory! What balls!

Anyway, this all seems like it's a problem that application developers simply don't use the tools provided for them to make their programs platform-independent. How would changing the platforms themselves fix the problem---at least, the one you were having?

--grendel drago

Thank you for the response! This explains quite a bit. So it's really the applications which are bad about interoperability. What could distributions do to fix this? It seems that

And for people insisting on rolling their own everything, I think D. J. Bernstein is the king of that, what with his daemontools and all. I suppose it's a good idea, though I can't say that with any authority... it just seems a bit odd that he's decided to add things to the root directory. To the root directory! What balls!

Anyway, this all seems like it's a problem that application developers simply don't use the tools provided for them to make their programs platform-independent. How would changing the platforms themselves fix the problem---at least, the one you were having?

--grendel drago

Since no one else has mentioned it yet, you might want to take a look at djbdns. I've used djbdns for a while now on my (very small) home network, and it works quite well. The aforementioned site includes all the info you need on how to set up and use djbdns in various situations, as well as info on how DNS works in general. Also, the site contains a lot of angry ranting about how BIND is full of security holes and the people who develop it are all evil liars.

Previous /. THREAD

Djbdns site with a ton of good information

I like it.

bo

qmail has a similar security guarantee. It was offered in 1997 and has never been claimed.

qmail has a similar security guarantee. It was offered in 1997 and has never been claimed.

While I don't think I'm in the clear because of this, I feel better protected from the (unwashed ;)) internet.

That seems fairly reasonable. I don't think you're really protected from poisoning, unless "poisoning" only applies to certain kinds of DNS spoofing. Specifically, first note the exceptions to the djbdns security guarantee (emphasis mine):

• Bugs outside of djbdns, such as OS bugs or browser bugs. (People could seize control of BIND 9.1 through an OpenSSL buffer overflow, but that was a bug in OpenSSL, not in BIND.)
• The vulnerability of DNS to forgery. (BIND's port reuse makes blind forgery much less expensive, but this is a quantitative difference, not a qualitative difference. The DNS architecture needs cryptographic protection.)
• Denial-of-service attacks. (BIND 9's fragility makes denial of service completely trivial; but an attacker can easily take down the Domain Name System without using any of BIND's bugs. The DNS architecture needs to be decentralized.)

Specifically, his forgery page points out that a spoofing attack based on the birthday paradox can still work... although probably tens of millions of packets are required. This page, which I think I got off slashdot before, uses the TCP sequence-number guessing tools to try to attack it. It's probably not quite as secure as djb estimates, but probably still in the millions. They don't seem to have actually run numbers for the randomized-port plus randomized-id, so it's unclear whether they actually attacked that thoroughly.

Hmm...the # sign in the second link doesn't seem to work...sorry...try this link instead.

In the interest of promoting discussion, there is a good definition of DNS poisoning here, and a longer explanation/rant regarding DNS poisoning here.

DJB's software is not free? I don't see any er requests for payment let alone the fact that the software is downloadable without charge.

Then there is the you can modify it and run it as you wish part. Without limitation too. Oh you mean you cannot redistribute it? That's hardly going to make it become non-free software.

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

While I don't think I'm in the clear because of this, I feel better protected from the (unwashed ;)) internet.

That seems fairly reasonable. I don't think you're really protected from poisoning, unless "poisoning" only applies to certain kinds of DNS spoofing. Specifically, first note the exceptions to the djbdns security guarantee:

• Bugs outside of djbdns, such as OS bugs or browser bugs. (People could seize control of BIND 9.1 through an OpenSSL buffer overflow, but that was a bug in OpenSSL, not in BIND.)
• The vulnerability of DNS to forgery. (BIND's port reuse makes blind forgery much less expensive, but this is a quantitative difference, not a qualitative difference. The DNS architecture needs cryptographic protection.)
• Denial-of-service attacks. (BIND 9's fragility makes denial of service completely trivial; but an attacker can easily take down the Domain Name System without using any of BIND's bugs. The DNS architecture needs to be decentralized.)

Specifically, his forgery page points out that a spoofing attack based on the birthday paradox can still work... although probably tens of millions of packets are required. This page, which I think I got off slashdot before, uses the TCP sequence-number guessing tools to try to attack it. It's probably not quite as secure as djb estimates, but probably still in the millions. They don't seem to have actually run numbers for the randomized-port plus randomized-id, so it's unclear whether they actually attacked that thoroughly.

Actually, BIND 9 is a complete rewrite of BIND and does not have the security issues that BIND 8 and 4 have. Basically, recent versions of BIND 8 and BIND 9 do create random DNS query IDs, which makes this kind of attack far more difficult (it would have been nice if DNS was designed with variable length query IDs back in 1983, but the Internet was a different place back then).

I really wish DJB advocates would realize that BIND 9 is not BIND 8 and below.

To DJB's credit, he has written The best article on DNS cache poisoning I have seen.

There are some things DNS implementors can do to protect against DNS cache poisoning. The best article about the subject is here.

Running dnscache which is much more intelligent about how it handles cacheable data than BIND is high on my recommendations list.

DJB has talked about it at least as far back as November 2001.
libresolv problems,talking about poissoning

DJB has talked about it at least as far back as November 2001.
libresolv problems,talking about poissoning

DJB has talked about it at least as far back as November 2001.
libresolv problems,talking about poissoning

• "dnscache does not cache (or pass along) records outside the server's bailiwick; those records could be poisoned. Records for foo.dom, for example, are accepted only from the root servers, the dom servers, and the foo.dom servers."

  "dnscache is immune to cache poisoning."

While I don't think I'm in the clear because of this, I feel better protected from the (unwashed ;)) internet. Anyone care to comment, please do, as I've just started using this and want to know how effective it is.

bo

Dan Bernstein is a proponent of this approach, as can be seen by looking at the approach taken in his programs such as Qmail.

Eliminate RSS from the mix, and essentially you are talking about something similar to IM2000.

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

The basic idea is to reverse the concept of how mail is handled today. If you want to send an email, you store it on your site until someone comes and picks it up from you. It is never delivered, all mail must be picked up. Instead of pulling your mail from a single Inbox, you pull your incoming mail from hundreds of repositories, depending on who is mailing you.

One advantage is that if someone wants to send out a million emails, it is up to THEM to store it, not you. Blacklisting becomes easier, as does whitelisting, etc.


And for you whiners who love bitching about how Dan Bernstein is behind it so it MUST be bad, please don't bother. That horse has been beaten to death hundreds of times before.

If I'm not mistaken, dsginter's point was not that we should create a new email system whose sole feature was backward-incompatibility, but that we should implement a new electronic mail infrastructure which is actually resistant to spam.

Numerous possibilities exist -- there's one I thought of, which, a few months after I posted it on my blog, Microsoft tried to patent, interestingly. It was that "Caller ID For Email" thing (which they've decided not to pursue, if I remember correctly). Now, I'm partial to Internet Mail 2000, a proposal for a system whose distinguishing feature is requiring that messages be stored on the sender's mail server -- this prevents spam not only by requiring spammers to use up space on their own servers if they wish to continue with their evildoings, but also by making a vaild return address a technological requirement, making spam laws more enforceable.

If this were to be implemented as Email 2.0, it would not be a waste of time to switch to it. The current electronic mail infrastructure was designed at a time when the only people using this Internet were academic institutes, researchers, and the US Government -- to put it simply, a friendlier Internet. You wouldn't expect the US Government or MIT or Tim Berners-Lee to send out unsolicited promotional/commercial email. But now that it's open to the public, less trust must be placed in random individuals.

Use maildir format. Of course, I'm not sure what kind of support exists in Windows clients for maildirs, but I would hope that by now they've started using it.

Bernstein has a pretty long discussion about it on his page

Unfortunately, the FHS doesn't work. slashpackage is an attempt to remedy the fundamental problem plaguing the FHS, and there is even a new quasi-distribution based entirely on slashpackage! The revolution has begun!

Unfortunately, the FHS doesn't work. slashpackage is an attempt to remedy the fundamental problem plaguing the FHS, and there is even a new quasi-distribution based entirely on slashpackage! The revolution has begun!

Unfortunately, the FHS doesn't work. slashpackage is an attempt to remedy the fundamental problem plaguing the FHS, and there is even a new quasi-distribution based entirely on slashpackage! The revolution has begun!

Unfortunately, the FHS doesn't work. slashpackage is an attempt to remedy the fundamental problem plaguing the FHS, and there is even a new quasi-distribution based entirely on slashpackage! The revolution has begun!