Re: [Resolverless-dns] Paper on Resolver-less DNS

[Ted Hardie <[e-mail]>]

Hi Erik,

Thanks for the time you've taken with your replies.  It appears we simply
disagree, as I believe the measure does increase the attack surface,
especially in the cases where the measures to limit the supplied records
are not (for example, I think "same browser tab" is too lax).  I appreciate
the opportunity to discuss this, however, despite our disagreement.

regards,

Ted

On Fri, Aug 16, 2019 at 11:40 AM Erik Sy <[e-mail]>
wrote:

> Hi Ted,
>
> On 8/16/19 17:50, Ted Hardie wrote:
> >
> > Yes, this is true, but I thought you asserted that it would
> > opportunistically attempt to use the provided records.  That means it
> > could also leak the interest of the client in a specific resource to a
> > potentially malign collector at the instigation of any web site
> > providing the malign DNS record; that's the increase in attack surface
> > for the existing attack.
>
> Today, websites can already learn something about the interest of their
> clients in specific resources. For example, search engines learn which
> results a client clicked by providing the client redirects instead of
> direct links. Thus, I think the described attack surface does not
> increase with respect to links directly provided by the website
> supporting resolver-less DNS.
>
> Beyond this, I describe in Section 3.2.2 of the paper restrictions for
> DNS records retrieved via resolver-less DNS. Here, it is recommended
> that user agents restrict the use of unvalidated DNS records retrieved
> via resolver-less DNS within the context of the same website or possibly
> the same browser tab. This measure prevents the described leaks beyond
> the applied context of a website or browser tab. Thus, I do not agree
> that resolver-less DNS contributes to the described increase in the
> attack surface.
>
> Erik
>
> >   At the very least, that appears to require clients to cache where
> > DNS records came from in their cache, so that they can build a
> > reputation for sources that supplied bad data and ignore data from
> > sources that gave bad data.  That's a far from perfect mitigation, of
> > course, but it helps some.
> >
> >
> >     >
> >     >  It also raises the risk that a client will receive a server
> >     > authentication from a CA not intended by the domain owner (our
> >     friend
> >     > the enterprise, an attacker, a government, etc.).  We have some
> >     > mitigations for that, but they are not complete.
> >
> >     The problem you are describing is not introduced by resolver-less
> DNS.
> >
> >
> > Agreed, but it also can't be ignored that the new source of supplied
> > DNS records gives a new opportunity to line up the facilities needed
> > for a successful attack.
> >
> > regards,
> >
> > Ted
> >
>
> --
> Resolverless-dns mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/resolverless-dns
>