Re: [Doh] Mozilla's plans re: DoH

[Brian Dickson <[e-mail]>]

On Wed, Mar 27, 2019 at 5:57 PM Eric Rescorla <[e-mail]> wrote:

>
>
> On Wed, Mar 27, 2019 at 9:32 AM Tony Finch <[e-mail]> wrote:
>
>> Eric Rescorla <[e-mail]> wrote:
>>
>
> > However, there are two more restricted cases in which we do think some
>> > network control of the resolver is reasonable.
>>
>> What about allowing Firefox users to access private / internal domain
>> names?
>>
>
> If a name doesn't resolve with DoH, we fall back to the system resolver.
> This doesn't work properly when the same name is available on the public
> DNS but pointing to a different location. As I alluded to in my email,
> we're still working out how to deal with this split horizon scenario.
>
>
I think there are data leakage and enterprise-specific issues, above and
beyond this, but I think there are ways to limit that, and identify the
split horizon existence:

If you do QNAME minimization and compare the delegations returned from the
system resolver and DoH server, if they don't have identical results, that
should point to the need to use the system resolver.

I can't think of reasons why they would differ except for split-horizon,
and possibly geo-ip stuff.

Non-split-horizon stuff follows:

I'd like to suggest other tests for determining whether using a public
resolver might be contrary to network policy, and thus be indicative of a
need for explicit user approval (opt-in).

   - Make connection attempts to the public resolver's IP address on UDP
   port 53, TCP port 53, and TCP port 853 (DoT).
   - Success on any of those could be interpreted as that public resolver
   being permitted by network policy.
   - Failure on all of those should be interpreted as that public resolver
   not being permitted by network policy.
   - I would also like to suggest adding a standardized DoH-only port,
   where the DoH-only port is used when policy appears to permit access to the
   third party resolver.
   - And finally, I would humbly suggest that the DoH "shared" 443 (HTTPS)
   port be used only with explicit user permission, and only when none of the
   above ports are accessible, i.e. "dissident mode".


(IMHO, dissident mode should also engage, or require the user to have
previously engage, whatever the specific browser calls its privacy mode,
e.g. "incognito", "private", etc., so as to minimize any residual risk to
dissidents.)

There are host/network security reasons about why "DoH to third party, on
by default" is a riskier choice, or where the mechanisms of enabling DoH to
third party locations are easily accessible.
Malware C&C communication, and malware data exfiltration over DNS, are
host-specific concerns, whereby malware might take advantage of encrypted
DNS to offsite providers, by accessing the browser as a DNS vector.
Even if it doesn't raise the bar that much, taking it out of the realm of
"trivial" (i.e. requiring some activity on the part of malware to enable
DoH) would be preferable.

Brian

Brian