Subject: [Doh] Clarification re: "Opportunistic DNS"

From: Adam Roach <[email-masked]>
Date: Tue, 27 Mar 2018 15:45:48 -0500

I'm posting this in my role as AD, to get information that might help us 
figure out next steps regarding the "Opportunistic DNS" [1] work that 
was discussed in London. Note that the "Opportunistic DNS" work remains 
out of scope for DOH: I'm posting here because this list has the correct 
community of interest.

During last week's discussion in DOH regarding techniques for 
proactively pushing DNS records to endpoints [2], there were several 
comments at the microphone that make me think there are important and 
subtle issues that were not completely obvious.

Specifically: while the slides and proponent were careful to talk about 
DNSSEC, TLS certificate validation, and "additional validation checks" 
for received information, there were at least two independent comments 
at the microphone that expressed concerns about cache poisoning. There 
were also multiple comments (one at the mic, one after the meeting) 
expressing concerns that DNSSEC doesn't provide the right kind of 
assurances necessary to validate records received from untrusted sources.

If the DNS experts on this list could expand on the concerns about 
poisoning in the context of DNSSEC, it would be greatly appreciated. 
Feel free to reply directly to me, or on-list.

Thanks!

/a

___
[1] I'm carefully using quotation marks here to indicate what it was 
called in the meeting, with the explicit recognition that this name is 
considered problematic by some.

[2] Presentation at 
https://datatracker.ietf.org/meeting/101/materials/slides-101-doh-opportunistic-dns-00

---

From: Ben Schwartz <[email-masked]>
Date: Tue, 27 Mar 2018 18:54:18 -0400

I'm not a DNS expert, but I've had a lot of time to think about this.

To me, in the context of the web, the most interesting concerns are about
scoping and lifetime.  For example, as a web server operator, if I can
populate a user's DNS cache with some distinctive (but valid, signed) DNS
records, then perhaps I can follow that user across the web, effectively
"marking" their traffic until the RRSIGs expire.  I think we can remove
this problem by scoping opportunistic records to the client IP address that
received them, so their use doesn't link two client IP addresses.  (This
resembles QUIC's issues with connection IDs.)

There's also a similar problem related to same-origin user tracking.  I
think that will require us to treat opportunistic DNS records like cookies,
and to clear them in similar situations.

Another concern is related to bad server selection.  Could a rogue actor
use an ad network to push suboptimal records to millions of users, breaking
a target site's load balancing?  I'm less concerned about this, especially
thanks to redirection tools like Alt-Svc, but it is worth some careful
attention.

On Tue, Mar 27, 2018 at 4:45 PM, Adam Roach <[email-masked]> wrote:

> figure out next steps regarding the "Opportunistic DNS" [1] work that was
> discussed in London. Note that the "Opportunistic DNS" work remains out of
> scope for DOH: I'm posting here because this list has the correct community
> of interest.
>
> During last week's discussion in DOH regarding techniques for proactively
> pushing DNS records to endpoints [2], there were several comments at the
> microphone that make me think there are important and subtle issues that
> were not completely obvious.
>
> DNSSEC, TLS certificate validation, and "additional validation checks" for
> received information, there were at least two independent comments at the
> microphone that expressed concerns about cache poisoning. There were also
> multiple comments (one at the mic, one after the meeting) expressing
> concerns that DNSSEC doesn't provide the right kind of assurances necessary
> to validate records received from untrusted sources.
>
> poisoning in the context of DNSSEC, it would be greatly appreciated. Feel
> free to reply directly to me, or on-list.
>
> Thanks!
>
> /a
>
> ___
> [2] Presentation at https://datatracker.ietf.org/m
> eeting/101/materials/slides-101-doh-opportunistic-dns-00
>
> _______________________________________________
> Doh mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/doh
>

---

From: Dave Lawrence <[email-masked]>
Date: Wed, 28 Mar 2018 14:42:24 -0400

> Feel free to reply directly to me, or on-list.

Honestly, I'm curious what the rationale *in the context of DNSSEC* is
as well, since from my point of view, what DNSSEC is giving you is an
indication that the records from the authority are authentic no matter
which way you got them, whether through your own iteration or on a
sheet of paper that that the RFC 2549 pigeon brought you.  

The Chain Query extension works under the very same principle: you
configure a trust anchor as the starting point, and are provided all
of the necessary chain-of-trust records necessary to validate the
final answer -- records which almost certainly all came from different
administrative authorities.