Re: how many angels can dance on the head of a pin?

[Alex Bligh <[e-mail]>]

--On 10 August 2008 16:24:54 +1000 Duane at e164 dot org <[e-mail]> 
wrote:

> If shared caching at the ISP level is abandoned in favour of moving them
> closer to the end user, either on their computer or on the LAN but isn't
> accessible usually from beyond the LAN, would that not solve the
> majority of concerns currently being expressed?

I think ISP-level caching has only been targeted here because it's the most
obvious way to obtain maximum impact for a cache poisoning attack. However,
unfortunately, it's not the only way to use cache poisoning techniques.
Not using ISP-level caching means (aside from the increased load):

  1. Lookups would more often take place from behind a NAT. This can reduce
     entropy and make any given attack easier. Thus remember unlike many
     attack profiles, sticking a shared cache behind a NAT only serves
     to make things worse.

  2. For specifically targeted attacks (e.g. where what Mallory really
     wants to do is poison the DNS for a particular mail smarthost), it
     gets no more difficult.

Let's also remember that no intermediate caching at all means lots
of additional load and complexity on the end user device (as full caching
and recursion needs to be implemented there) and/or greater latency,
as the recursive element requires lookups from "." upwards go over
an end user link. Consider how, for instance, internet browsing on a mobile
phone would be affected by a total absence of intermediate caching servers.

To return to the original angels and pins discussion, when this group
was first busying itself designing just how the lipstick might be applied
to the DNSSEC pig, one of the original design criteria was that the security
worked in such a way that it was transparent to dumb caches between
authoritative server and end resolver. Solving integrity problems without
dumb caches being the ones providing the data (i.e. assuming resolver
could always talk directly to the authoritative server) would have been
far easier, and would no doubt have resulted in a far less ugly beast
of a protocol. If we were wrong to include caching as a design criterion
at all (i.e. if we can ditch it now), then yes, that is seems consistent
with your view of DNSSEC. I don't, however, think dropping caching is
a realistic option, either for vanilla DNS or for DNSSEC or any substitute
thereof.

Alex

--
to unsubscribe send a message to [e-mail] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>