[dns-operations] summary of recent vulnerabilities in DNS security.

[Paul Vixie]

Haya Shulman wrote:
>
>
>     > > so if i add "first weaponized by Haya Shulman" this would
>     settle the
>     > > matter?
>     >
>     > Thank you, can you please use Amir Herzberg and Haya Shulman (I
>     > collaborated on this attack together with my phd advisor Amir
>     Herzberg).
>
>     it shall be done.
>
>
> Thank you.

upon deeper consideration, "weaponized" is the wrong verb, unless you
have released your software. i can say "first published" if that will
serve your purpose.

> Eastlake cookies is a very neat proposal. In contrast to other
> challenge-response mechanisms, which reuse existing fields for
> security (while those fields were originally designed for a different
> purpose), e.g., source ports, Eastlake's proposal uses the EDNS to add
> randomness in order to authenticate communication between resolver and
> name server. So, you are right, it does prevent many attacks, but, it
> does not prevent all the attacks, particularly those that exploit
> fragmentation. For instance:
>
> 1. what about an IP packet that is fragmented into three fragments,
> such that the EDNS OPT RR is in the third fragment? By replacing the
> second fragment, the attacker can inject malicious content.
>
> 2. another example also involves IP fragmentation, however in this
> scenario the second fragment can be of any size, e.g., a single byte.
> The attacker overwrites the transport layer port of the first
> fragment, e.g., to its own port and intercepts the packet (along with
> the cookie); replaces the DNS records and forwards the resulting
> response to the resolver.
>
> Both tricky but feasible. 
> Correct me if I am wrong, but I think that the cookies would not
> prevent these (above) attacks.

i can't tell whether you're wrong, there's not enough detail here. if
you're able to replace the middle fragment, or perhaps replace all
fragments except the last one, then only SIG(0) or TSIG or DNSSEC could
stop you. however, my back of envelope estimate is that replacing the
middle fragment with one the same size but different content is more
than just "tricky", and replacing all-but-the-last fragment would
require many hours at 100MBit/sec, which to me places it out of
consideration as an attack worth defending against.

i believe that mark andrews of ISC is going to re-release eastlake
cookies. i expect that in consideration of your fragmentation work, he
will add a 32-bit CRC covering the full message to the EDNS option that
contains the cookie. since the cookies method is something we need
anyway (for DDoS prevention), we ought to depend on it to solve for
fragmentation as well.


>
>
>     > I absolutely agree with you, deploying DNSSEC on the end hosts
>     would be
>     > ideal for security.
>
>     wait, wait, that's not what i said. i said recursive dns should be
>     on-premise
>     or on-host, not wide-area. i said nothing about end to end dnssec.
>     what are
>     you specifically agreeing with?
>
>
> Yes you are right, I agree with you that it is best to validate on
> recursive resolver on-premise.

that is, again, not what i said. i want recursion, iteration, and
caching to occur on-premise or if necessary on-host. i will want this
even in the absence of globally deployed dnssec. i will also want
on-premise or if necessary on-host validation where possible, but that's
not what i was saying in the text you quoted.

> But, I also wanted to add, that I think best to validate on the end
> host; this would also prevent attacks by attackers that are on the
> same network with the client, e.g., wireless networks or networks of ISPs.

that's a controversial topic, as i expect followups to this thread to
demonstrate. i won't address it here.

>
>     > I think I may have been misinterpreted. I believe cryptography
>     is important
>     > and efforts should be invested in deployment of DNSSEC. One of
>     the goals of
>     > our work on DNS was to motivate adoption of DNSSEC.
>
>     that's great to hear.
>

a side by side reading of your earlier draft
(http://arxiv.org/pdf/1205.4011.pdf) and your current draft:

https://0a94266f-a-62cb3a1a-s-sites.googlegroups.com/site/hayashulman/files/fragmentation-poisoning.pdf?attachauth=ANoY7cpB1yJsBXMWL0_spxDjUMV9m5G_TjI98UgJE6OtoP98H-WrlRJ2AyJVhajdZ5za2vjZ14twuMHuB7NUcRW_EYv36scybuofLgPOwoU2Rvs7zpSnm_Qj3jA3noSc3ibX9b9_7tncZJdGca0FLY8SOrzMTY_O5bd0NPcwBXtDx9vtCjbRisMFf48MiOYFNO-66BY3iyGa584pJ0Sy2vYfI5ZKKCmvJhJsmY96N4XChK5cGgky8eg%3D&attredirects=0
<https://0a94266f-a-62cb3a1a-s-sites.googlegroups.com/site/hayashulman/files/fragmentation-poisoning.pdf?attachauth=ANoY7cpB1yJsBXMWL0_spxDjUMV9m5G_TjI98UgJE6OtoP98H-WrlRJ2AyJVhajdZ5za2vjZ14twuMHuB7NUcRW_EYv36scybuofLgPOwoU2Rvs7zpSnm_Qj3jA3noSc3ibX9b9_7tncZJdGca0FLY8SOrzMTY_O5bd0NPcwBXtDx9vtCjbRisMFf48MiOYFNO-66BY3iyGa584pJ0Sy2vYfI5ZKKCmvJhJsmY96N4XChK5cGgky8eg%3D&attredirects=0>


...shows a remarkably different attitude toward dnssec. what led to your
reconsideration?

vixie
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.dns-oarc.net/pipermail/dns-operations/attachments/20131022/847acbbd/attachment.html>