bert hubert finally blogs comments

"Calculating the chance of spoofing an agile source port randomised resolver" by Lennie

Sun, 17 Aug 2008 15:46:13 +0200

Getting them to apply patches is hard ? I still see a lot of queries on our authoritive servers with a source-port of 53. Even a large dutch access-provider.

"Some thoughts on the recent DNS vulnerability" by SIGLAZY

Thu, 17 Jul 2008 09:13:56 +0200

About DNSSEC, oh well, this is another "good solution to the wrong problem". (DNSSEC uses DNS protocol to propagate keys through DNS caches && DNS caches are vulnerables to cache poisoning = DNS keys may be forged ...) and If DJB was not listened at _on this specific point_ it is not only because he has a big social interface problem but also because IETF DNS-EXT WG people were... how to say? deaf or stupid.

"Some thoughts on the recent DNS vulnerability" by grin

Thu, 10 Jul 2008 13:45:20 +0200

But it should be noted that djb is a real PITA, so if there's something he try to push it's very probable that people try to avoid it. And him. Don't get me wrong: this is all about behaviour and not about his programming abilities at all.

About DNSSEC, oh well, would be nice to have seen it finalised and implemented.

"Some thoughts on the recent DNS vulnerability" by bert hubert

Thu, 10 Jul 2008 13:15:09 +0200

Roy - many of the points you raise are valid. But if people would have implemented this years ago, we would be having a totally different discussion right now. And I sincerely hope that this vulnerability opens people's eyes and that we can fix DNS to be secure enough.

"Some thoughts on the recent DNS vulnerability" by NB

Thu, 10 Jul 2008 13:09:20 +0200

Hey Roy, in case you missed it, Paul Vixie said on the NANOG mailing list that he has known about this attack since 1995.

Also, DNSSEC has been six months away from completion for over a decade by now, hasn't it? If I had to choose a word to describe Bert Hubert's choice regarding PowerDNS and DNSSEC, it'd be "prudent" (rather than your "negligent").

The "serious terminology fixes" that were necessary to change in the I-D are all fine and dandy but you have to look at the slightly bigger picture. This standards track started out with alumni of the DNS world claiming that the I-D was unnecessary. The explicit reference in CERT's advisory conclusively proved the opposite.

"Some thoughts on the recent DNS vulnerability" by Roy Arends

Thu, 10 Jul 2008 11:23:00 +0200

What I resent in this blog/rant is the passive aggressiveness. "funny way of presenting things" "secret industry cabal". "the parties involved aren't to be lauded for their current fix. Far from it".
The current fix is the absolute best these parties could do at the moment. They have been told to fix it, and they fixed it.

"it has been known since 1999 that all nameservers were vulnerable for issues like the one we are facing now".
Just because Dan Bernstein implemented it, doesn't mean Dan Bernstein knew about this specific flaw.

"Let me repeat this. Wise people already saw this one coming 9 years ago, and had a fix in place"
Let me just say that this fix doesn't really help in the long run. Wise people would have implemented DNSSEC, or some other applied crypto to the DNS years ago. Most parties involved have done that, except for you and Dan Bernstein. So this is completely off the wall.

"but some months ago I noticed particularly strenuous resistance in the standardization of the so called forgery resilience draft, and after some prodding it became clear it was felt my draft was in danger..."
Paranoid rambling in need of several layers of tin foil. The draft was in need of some serious terminology fixes. Some folks helped out trying to get the text straightened out, especially since they knew what was about to be announced. They helped get the text standardized, and certainly did not try to stall things. IIRC, this draft was actually RUSHED and PUSHED to get a WGLC out sooner, rather than later, because of this issue.

"Dan Bernstein has been ignored since 1999 when he said something should be done. I've been ignored since 2006. The IETF standardisation languished for two years."
Both have ignored applied crypto in DNS (not just DNSSEC, basically any solution that _really_ fixes this issue). Since you know about this specific flaw, you know that the additional bits of randomness doesn't fix the problem in the long run. Moore's law. Bandwidth gets wider and cheaper, processing packets get faster and faster. The randomness in DNS messages including port randomization is fixed. What is your long term solution? Have you implemented one? Have you even thought of one? Have you helped developed one?

I think this post has it all just about wrong.

"Some thoughts on the recent DNS vulnerability" by Stéphane Bortzmeyer

Thu, 10 Jul 2008 10:44:31 +0200

If Dan Bernstein was not listened at _on this specific point_ (he made a lot of other claims on many subjects and a good part of them are wrong), it is not only because people were deaf or stupid but also because Dan Bernstein has... how to say? A big social interface problem.

"Some thoughts on the recent DNS vulnerability" by bc

Thu, 10 Jul 2008 10:41:49 +0200

Well perhaps this is a sign that the IETF standards process is broken, do you perhaps have any suggestions on how this can be improved.

"Some thoughts on the recent DNS vulnerability" by unknown

Thu, 10 Jul 2008 07:23:11 +0200

I have a theory on what it is that Dan Kaminsky may have discovered that is broken with DNS (it was already _so_ broken, what else could be wrong?!) Basically it has to do with ICMP packets (spoofed ICMP unreachables sent in response to DNS packets the attacker can't see, but can guess - thanks to non-random port selection). The biggest problem with spoofing DNS at the moment is that you need to silence the real nameservers in order to get your fake replies in. For an ICMP response to be valid, it must contain the IP header of the packet it is a reponse too, but it also must contain 64bits of the data payload. The reason for requiring 64bits of the payload is to prevent people from spoofing ICMP replies to packets they have not received. In the case of a DNS packet, that payload is the first 64 bits of the UDP header. What is in the first 64bits of the UDP header? The source and destination ports of the DNS servers. If these are easily predictable then you can spoof an ICMP unreachable response to a dns query or reply without actually receiving it. If you can spoof ICMP; You can prevent the recursor from communicating with the real nameserver. This will make it very very easy to spoof DNS as it removes the biggest hurdle; that of silencing the real nameservers. It only takes about 2min on a 10mbit/s connection to run through all 65536 possible sequence numbers so if you can prevent the recursor from talking to the real nameservers it really is easy as pie.

"Some good news to go with the bad" by John Levon

Mon, 19 Nov 2007 01:30:51 +0100

Congratulations.