Re: [DNSOP] Fw: New Version Notification for draft-bellis-dns-recursive-discovery-00

[Alex Bligh <[e-mail]>]

Florian,

--On 21 October 2009 09:10:16 +0000 Florian Weimer <[e-mail]> wrote:

>> --On 21 October 2009 08:34:39 +0000 Florian Weimer <[e-mail]>
>> wrote:
>>
>>>>> Mark, I din't think this is true given how the proposed protocol
>>>>> works.  For a start, you often cannot fetch the DNSKEY RR for ARPA
>>>>> before running the protocol.
>>>>
>>>> Indeed LOCAL.ARPA would need to be unsigned.
>>>
>>> Not really.  Why would it need to exist in the public tree at all?
>>> All we need is agreement from both ICANN and IETF that LOCAL.ARPA is
>>> reserved and not to be delegated in the official tree.
>>
>> OK, let's try this one again. LOCAL.ARPA is not delegated at all.
>> It is unsigned.
>
> If it is not delegated, it will be signed (as Mark pointed out).
>
>> Necessarily, ARPA. will have no records for LOCAL.ARPA
>
> Then its non-existence will be signed.

Sure, on the .ARPA nameservers, but these will (a) never be
queried when there is a DOMAIN.LOCAL.ARPA-supporting nameserver,
and (b) the signature of its non-existence will not be relevant
to a DO clear query anyway, will it?

Clearly a validating recursive nameserver not supporting
DOMAIN.LOCAL.ARPA may get a signed denial of existence for
LOCAL.ARPA, but that's just fine. LOCAL.ARPA doesn't
exist "there".

>> Moreover the queries into DOMAIN.LOCAL.ARPA are going to be made
>> in an environment where we suspect DNSSEC queries don't work, as
>> there is, ex hypothesi, possible a misbehaving proxy in the way.
>
> Right.  (Otherwise, you wouldn't use class IN for this stuff.)
>
>> So there are two separate security risks: cache poisoning on the
>> recursive server (this needs addressing and I have some ideas),
>> and a theoretical Kaminsky style attack on the individual
>> non-DNSSEC queries to DOMAIN.LOCAL.ARPA.
>
> Don't worry too much about spoofing from off-path attackers.  ISPs
> have plenty of means to prevent it (granted, for IPv4 directly over
> Ethernet, there's no standard way of doing things which conserves
> address space, but that's a different issue).

I'm not actually worried about it, I just explained it for completeness.

> As I've tried to explain, spoofing by the resolver operator itself is
> the relevant issue here.  It breaks the proposed protocol.  Please
> tell me how I can explain this in a better way---perhaps I shouldn't
> say "spoofing" but "DNS rewriting", "NXDOMAIN redirection",
> "Sitefinder", "online help page", or something else, but it's really
> spoofing.

Ah. I think I now understand what you mean. Well yes they can do that, but
they could do it anyway. The resolving server operator can say "please
query this spoofing/sitefinder/whatever" resolver (let's call it
$evilserver) instead. But it has exactly the same effect as if they supply
$evilserver's IP address by DHCP / over PPPoA to the CPE gateway and the
CPE gateway uses that. Indeed the very server which is responding to
LOCAL.ARPA queries may be $evilserver. So all the bad things you describe
can happen at the moment, and this draft won't fix them. We are solely
changing:

      Client Stack -----> Proxy ----> $evilserver
   to
      Client Stack -----------------> $evilserver

and

      Client Stack -----> Proxy ----> $goodserver
   to
      Client Stack -----------------> $goodserver

> Note that this problem will not go away when you bring LOCAL.ARPA or
> DOMAIN.LOCAL.ARPA into existence.  People say "NXDOMAIN redirection"
> but they really mean "arbitrary DNS manipulation".  It doesn't stop at
> NODATA response or the second level of the tree.

Indeed, and it is not intended to. The draft is simply intended to
bypass the CPE proxy. The only way in which it helps with preventing
arbitrary DNS manipulation is that the technology we already have
to stop that (DNSSEC) has implementation issues due to poorly
performing proxies. Bypass them, and DNSSEC becomes easier to deploy,
in which case we have a weapon against DNS manipulation (I appreciate
there are arguments that this weapon is less than perfect, but it
is currently the best weapon we have).

-- 
Alex Bligh