Hacker News Reader

Comment by dc396 | Hacker News Reader

I guess you and I were at different meetings. I was at meetings at NSF with TIS folks that resulted in funding for DNSSEC implementation in BIND where the presentation focused on the 16-bit transaction field (and included a live demonstration), so I'll stand by my view that the point of DNSSEC was to address that particular flaw.

In any event, that's a nice site that provides useful stats.

View on HN

I remember tearing my hair out in the pre-2008 era as folks tried to get source-port randomization into Bind. The response was "That's what DNSSEC is for" ... which further supports your narrative. But it's still very damning.

Source port randomization, BCP38, and then the 0x20 qname capitalization trick, all turned out to be far more practical mitigations for query-id concerns and others prioritized them. "We really need this massive internet-wide jobs-program lift of the entire Internet, without even providing confidentiality, to solve this query-id issue. Never mind the easier fixes."

Wow this brings up memories. I was at OpenDNS when Dan gave us the heads up.

I'll just leave this here: https://blog.netherlabs.nl/articles/2008/07/09/some-thoughts...

I found that post so cathartic.

This whole episode reminds me of the story of the Citigroup Center in New York. Years after its completion, an architecture student uncovered that key supports for the building had been done incorrectly and unsafely. It was at risk of collapse in high winds.

The structural engineer worked with the building owner and city to repair the building in secret, before everything was eventually made public. It makes for a story of a folk hero, and it's a great narrative of recovery. Meanwhile the stories of the structural engineers and construction supervisors who weren't woefully negligent and who just quietly built safe buildings go uncelebrated.

Just remember that it was never a "Kaminsky Bug" in the first place, and there's a whole community of people who had spotted it years before, who had been pooh-poohed and naysayed by BIND people for years about all this.

* https://dns.cr.yp.narkive.com/fAkXdiM0/update-on-the-djb-bug...

I'd be interested in more reliable sourcing for this claim.

M. Anderson was not wrong in this particular case. Indeed, Bernstein xyrself was on the bind-users mailing list discussing the vulnerability to packet forgery, just after the turn of the 21st century. The reason that the famous djbdns security guarantee excluded forgery is that it was well known then that there were basic protocol problems in this area, and basically it was speed and luck that had been keeping them at bay.

It should tell you something that even I, who am and was on a different continent to all of these people, knew about this stuff well before it became an ISC press release. I'd like to say that it was Paul Jarc who went into the consequences of what one could do with response forgeries, on Bernstein's dns mailing list, but I might be remembering the wrong person. Certainly, list regulars had read Bernstein's discussion of DNS security and realized the implications.

The logical consequences of being able to forge whatever response one likes were readily apparent. Bert Hubert noted publicly at the time of the Kaminsky announcements that xe had been not only aware of this for years,

* https://mailman.powerdns.com/pipermail/pdns-users/2008-July/...

but had even been trying to get an IETF draft approved about port+ID randomization, and bailiwick checking, acknowledging the factors involved and promoting the adoption of the well-known mitigations as mandatory.

Amusingly for the instant case of researchers rediscovering the well-known, you can read M. Hubert's first draft from a year and a half before the ISC press release, and it lays out there exactly what I laid out here elsewhere in this very discussion, about a query to Google Public DNS taking a second from cold to answer for ~.www.example.com and that being more than enough time to send a tonne of forged responses at 2006 network speeds.

* https://datatracker.ietf.org/doc/html/draft-ietf-dnsext-forg...

This draft does not describe Kaminsky's attack; it describes the vanilla Birthday Attack from 2002. Kaminsky's discovery was the combination of random bogus query names and spoofed authority sections, which dramatically expanded the number of "bites at the apple" attackers had to match query IDs from spoofed responses to original requests.

Daniel Bernstein was right in the late 1990s about randomizing source ports, and randomization did effectively foreclose on Kaminsky's vulnerability. But I'm unaware of a cite in which he outlines Kaminsky's attack in any detail. His djbdns countermeasure was a sensible response to BIND's QID prediction problem, which Paul Vixie was reluctant to fix because the QID only gave him 16 bits of randomness to work with.

I'm not saying you're certainly wrong that other people had discovered the random-name / authority spoofing attack Kaminsky came up with, only that I'm intimately familiar with this whole line of security research and I'm unaware of a source laying it out --- I am thus skeptical of the claim.

I think you're talking past each other and saying the same thing. There never was a Kaminsky bug. There was no new vulnerability. There was a new attack.

Kaminsky figured out how to build a much more practical way to exploit what was known already. This was very significant, and it's one of the ultimate examples of PoC||GTFO finally triggering action. He deserves a lot of credit.

Sure! I feel like repeated spoofing bids through authority records on responses to random in-bailiwick queries is a novel protocol vulnerability but wouldn't die on the hill of it being instead a new class of attack; we all agree that inadequate randomness is the original sin here.

Thanks! For what it's worth: I think hashing out the origins of DNSSEC is a super interesting conversation to have, and I'm happy you're here pushing back on what I'm saying (the truth is going to be somewhere in between the two of us).

Reply on news.ycombinator.com