Florian,
--On 21 October 2009 09:10:16 +0000 Florian Weimer <fwei...@bfk.de> wrote:
--On 21 October 2009 08:34:39 +0000 Florian Weimer <fwei...@bfk.de>
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
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
