<html><head>
<meta http-equiv="content-type" content="text/html; charset=ISO-8859-1"></head><body
bgcolor="#FFFFFF" text="#000000">
Haya Shulman wrote:<br>
<br>
<blockquote type="cite"><span><pre style="color: rgb(0, 0, 0); font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; text-align: start; text-indent: 0px; text-transform: none; word-spacing: 0px;"><span style="font-style: italic;"></span>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`.</pre></span></blockquote>
<br>
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.<br>
<br>
<blockquote type="cite"><span>
<pre style="color: rgb(0, 0, 0); font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; text-align: start; text-indent: 0px; text-transform: none; word-spacing: 0px;">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.</pre>
</span></blockquote>
<br>
your text above shows a drastic misunderstanding of both dns and dnssec.<br>
<br>
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.<br>
<br>
<blockquote type="cite"><span>
<pre style="color: rgb(0, 0, 0); font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; text-align: start; text-indent: 0px; text-transform: none; word-spacing: 0px;">...
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.</pre>
</span></blockquote>
<br>
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.<br>
<br>
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.<br>
<br>
<blockquote type="cite"><span>
<pre style="color: rgb(0, 0, 0); font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; text-align: start; text-indent: 0px; text-transform: none; word-spacing: 0px;"><span><span>[vixie]
</span></span><span><blockquote style="font-style: italic;" type="cite"><span>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. </span></blockquote>
</span><span><span></span></span>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.</pre>
</span></blockquote>
<br>
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.<br>
<br>
<br>
<blockquote type="cite"><span>
<pre style="color: rgb(0, 0, 0); font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; text-align: start; text-indent: 0px; text-transform: none; word-spacing: 0px;">[vixie]
<span style="font-style: italic;"><blockquote type="cite"><span>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. </span></blockquote></span>
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.</pre>
</span></blockquote>
<br>
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?<br>
<br>
vixie<br>
</body>
</html>