Re: [Add] Draft Posting: CNAME Discovery of Local DoH Resolvers

On Fri, Jun 26, 2020 at 2:46 PM Tommy Pauly <tpauly@apple.com> wrote:

> Hi Ekr,
>
> Thanks for sharing this draft. Very exciting to see this step forward in
> supporting the automatic use of DoH.
>
> Regarding the choice of using DNS + CNAME, I completely understand and
> sympathize with the practical deployment aspects. Going forward, I’d like
> to see if collectively we can use a record that gives a full DoH URI. Your
> draft does reference the option of using HTTPS RRs for this, as Tommy
> Jensen has proposed in
> https://tools.ietf.org/id/draft-pauly-add-resolver-discovery-00.html#name-discovery-of-doh-capabiliti
> .
>
> In my email to this list just a bit ago, I mentioned that we’re starting
> to request these RR types (well, the older version for HTTPSSVC, but will
> be updated) on the iOS and macOS betas. Hopefully we can measure based on
> that how much RRType interference exists in networks. I’d be curious to
> hear what kinds of measurements the Mozilla team is taking in this space,
> as you are able to share.
>

We're just starting the work to collect data, but we expect to publish it
once we have it.

I’d also be interested to have a discussion here about the acceptable
> ranges for breakage. Certainly, if the percentage of home wifi setups that
> fails with a new RRType is very high, it’s a problem. However, if the
> percentage is lower but still significant (say, 5%?), we can consider the
> tradeoff of solutions. Intolerance to passing unknown RRTypes is one way
> that this could break; however, there are many other ways a local wifi
> router could potentially interfere. For example, a wifi router might not
> recurse to the ISP's DNS resolver, but some other resolver (which if it is
> 1.1.1.1 or 8.8.8.8 would support DoH, but could be something else that
> doesn’t).
>

Sure. Though note that it's proxying to a non-TRR resolver then whether it
filters CNAMEs doesn't matter because the intent here would be to use a
default TRR.

I'd be interested in hearing what tradeoffs you see here. Other than
inelegance, what's problematic about the CNAME approach?

There will always be *some* tail of networks that won’t work, even with the
> CNAME approach; and I’d like to see a long-term solution that allows for
> richer information than just a hostname. Thoughts?
>

Well, as I said when this group was first formed, we should start by
figuring out what we are trying to accomplish and the threat model.

For the TRR case, it's not actually the hostname we are interested in but
rather the identity of the network-associated TRR. The hostname is just a
convenient lookup key. If an ISP told us they wanted to use
"<isp-name>.invalid" that wouldn't be a problem for us as long as it was
unique.

The scenario you seem to be interested in is one in which the user joins
the network and then learns that the associated Do53 resolver supports DoH
and then connects to it with whatever coordinates that resolver (or DHCP or
whatever) provides. That clearly is not useful in the 3552 threat model
which assumes that the attacker entirely controls the network because the
attacker can just send their own resolver coordinates. That isn't to say
that there aren't more limited but still realistic threat models where this
would be useful, but I think you should start by describing those.

-Ekr

> Best,
> Tommy
>
> On Jun 25, 2020, at 7:05 AM, Eric Rescorla <ekr@rtfm.com> wrote:
>
> Hi folks,
>
> As has been noted previously, the current Firefox DoH/TRR design
> bypasses the ISP resolver even if the ISP resolver supports DoH.
>
> I have just posted draft-rescorla-doh-cdisco-00, which describes a
> CNAME-based mechanism for discovering when a local resolver supports
> DoH/TRR. Firefox can then determine whether that resolver is on the
> TRR list and if so can use it in preference to generic resolver.. The
> use of CNAME was chosen for pragmatic reasons (laid out in the draft).
> We're studying other designs but thought it would be a good idea
> to document this one.
>
> See: https://www.ietf.org/internet-drafts/draft-rescorla-doh-cdisco-00.txt
>
> -Ekr
>
>
>
>
>
>
>
>
> --
> Add mailing list
> Add@ietf.org
> https://www.ietf.org/mailman/listinfo/add
>
>
>