Haya Shulman wrote: > I understood that you asked two questions: > (1) by this, do you mean that you have found a fragmentation based attack > that works against DNSSEC? > (2) by this, do you mean that if DNSSEC is widely deployed, your other > recommendations are unnecessary? > > -- > > Correct me if I am wrong, but I understood > > that in (1) you meant partial deployment of DNSSEC, since later in (2) > you emphasised the `full deployment`.
i apologize for my sloppy wording. i mean full deployment, in either case. your claims and your proposed workarounds will be evaluated through the lens of engineering economics. as vernon schryver has been (unsuccessfuly thus far) trying to explain, effort expended to defend against vulnerabilities will have to be prioritized alongside of, and in competition with, effort expended to deploy dnssec. > As I wrote, even if DNSSEC is fully deployed and validated, > denial/degradation of service attacks, via cache poisoning (of records > in referral responses), are still feasible - since the resolver caches > spoofed records. DNSSEC was designed to prevent cache poisoning. your text above shows a drastic misunderstanding of both dns and dnssec. a correctly functioning recursive name server will not promote additional or authority data to answers. poison glue in a cache can cause poison referrals, or poisoned iterations, but not poisoned answers given to applications who called gethostbyname(). dnssec was crafted with this principle firmly in mind, and the lack of signatures over glue is quite deliberate -- not an oversight -- not a weakness. > ... > This is the work that we shared with you last year, when we contacted you > regarding help coordinating disclosure of the fragmentation-based > vulnerability. You also cite it at the end of the article, but it is not > mentioned explicitly in the fragmentation section. The publication version > of this work is on my site. thanks for clarifying that. i cannot credit your work in the section of my article where i wrote about fragmentation, because you were not the discoverer. in 2008, during the 'summer of fear' inspired by dan kaminsky's bug, i was a personal information hub among a lot of the dns industry. at one point florian weimer of BFK called me with a concern about fragmentation related attacks. i brought kaminsky into the conversation and the three of us brainstormed on and off for a week or so as to how to use fragments in a way that could cause dnssec data to be accepted as cryptoauthentic. we eventually gave up, alas, without publishing our original concerns, our various theories as to how it might be done, and why each such theory was unworkable. i was happy to cite your work in my references section because your explaination is clear and cogent, but since you were not the discoverer, i won't be crediting you as such. > [vixie] >> i believe that if we can't make a significant difference in the >> resiliency and quality of core internet infrastructure after 16 >> years, then we wasted our time. and i know that if five more years >> wasn't enough, then fifty years would also not be enough. as an >> industry we must at some point either declare victory and stop >> creating lower quality counter-measures which add complexity, or we >> must declare failure and stop expecting dnssec to help with any >> problems we might discover in the existing system. we can't >> realistically or credibly have it both ways. > > I beg to differ, I think DNSSEC is already a success. Maybe, had DNSSEC > been immediately fully adopted as soon as it was standardised, in 1997, it > could have, by now, been adandoned due to interoperability, functionality > and security problems that would have emerged (nothing specific of DNSSEC > but just the same for any new mechanism). > Since changing the Internet and adapting it for DNSSEC is not a realistic > option, DNSSEC had to be adapted. DNSSEC has already substantially changed > over the years, during its incremental deployment. > > IMHO deploying additional countermeasures, like port randomisation, in > tandem with DNSSEC, in the meanwhile, does not introduce a security or > functionality problem. your answer is evasive and nonresponsive, and i beg you to please try again, remembering that the vulnerabilities you are reporting and the workarounds you're recommending will be judged according to engineering economics. if we assume that dnssec is practical on a wide enough scale that it could prevent the vulnerabilities you are reporting on, then your work is of mainly academic interest. as vernon said earlier today, none of the vulnerabilities you are reporting on have been seen in use. i also agree with vernon's assessment that none of them will ever be seen in use. > [vixie] >> i'd like to hear more about this. at the moment i have no picture in >> my head of "not only cache poisoning" when i think of the prevention >> offered by source port randomization. > > Port randomisation can be a useful coutermeasure against other attacks as > well, e.g., the ability to predict ephemeral ports can be used for a range > of attacks, e.g., name server pinning (not only for poisoning, e.g., for > covert communication), low rate attacks against clients/resolvers, > breaching instances' isolation on cloud platforms, injection of content > into TCP connections (was applied by Watson VU415294 against BGP, but can > also be used against web traffic), deanonymisation of communication over > TOR. Some of the papers are already on my site. that's too many "e.g.'s" and external references for me to follow. each fragmentary concept you've listed above strikes me as a nonsequitur for source port randomization. can you dumb it down for me, please? vixie
_______________________________________________ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
