Re: [DNSOP] Concerns around deployment of DNS over HTTPS (DoH)

[Brian Dickson <[e-mail]>]

On Sat, Mar 23, 2019 at 10:44 PM Kenji Baheux <kenjibaheux=
[e-mail]> wrote:

>
>
> On Sat, Mar 23, 2019, 13:04 Wes Hardaker <[e-mail]> wrote:
>
>> Kenji Baheux <kenjibaheux=[e-mail]> writes:
>>
>> >   * We are considering a first milestone where Chrome would do an
>> automatic
>> >     upgrade to DoH when a user’s existing resolver is capable of it.
>
>
>> Sorry for the delayed question, but with respect to this bullet:
>>
>
>
>
>
>> 1) Do you have evidence that DOH is faster than DOT, since speed was one
>> of your goals?
>>
>
> Speed isn't a primary goal, hence the use of "hopefully". Based on
> Mozilla's early results [1], there is hope that the performance will be
> improved at the high percentiles and remain neutral/acceptable otherwise.
>
>
> [1]
> https://blog.nightly.mozilla.org/2018/08/28/firefox-nightly-secure-dns-experimental-results/
>
>
>
>
>> 2) What other reasons are you considering when doing DOH instead of DOT
>> to protect privacy.
>
>
> We are not considering DOT, just DOH.
>

I sincerely hope you reconsider this position.

See below on a variety of factors on why DoT >> DoH, for enterprise
use/deployment(s).

The concerns that have been raised about blocking DoT are, IMHO, somewhat
"red herrings".
The specific blocking scenarios are likely to be "block all DoT EXCEPT this
specific set of DoT servers", which is not the same as "blocking DoT". In
particular, it does not downgrade to Do53.

However, it is much more likely, at least in enterprises (especially in
data centers or in multiple security zones) that DoH will be blocked
entirely, while DoT will be restricted (but not blocked).


>
> I believe that there has been many discussions in the past that offered
> reasons why a browser / ... would naturally prefer DoH over DoT.
>
> I don't think I have anything to add that would sway the debate in way or
> another. In fact, I think it's fair to say that the debate is unlikely to
> come to an end anytime soon.
>
> Instead, I imagine it would be more effective to focus on specific
> scenarios: who are the actors, what do they want or accept/understand, is
> the scenario reasonable to all parties involved, what can they do, etc.
>
>
>
Let me give some specific examples of actors, including DNS operators, DNS
software maintainers, malware and other bad actors (with very specific
examples), and CIO/CISO types.

DNS operators (i.e. those operating recursive dns resolvers) generally have
specific existing environments, consisting of selected DNS software
vendor(s), DNS configurations, plus additional DNS-related components.
Changing software vendors is not something done lightly, and generally
requires compelling reasons. Many aspects of DNS configurations do not work
the same, or at all, if vendors are switched.

DNS operations frequently entails a number of additional elements,
including policies for resolution (white lists, black lists, dynamic
white/black lists), security-zone specific configuration elements
(typically maintained with automation tools), logging, inspection,
alerting, and active mitigations (such as RPZ).

DNS operations may involve combinations of caching, recursive resolution,
forwarding, including on a "split-brain" server, and sometimes integrated
authoritative service for a configured set of zones (typically via AXFR
secondary).

The existing mostly-UDP nature of Do53 is problematic for traffic that
crosses security boundaries, specifically because of the stateless nature
of UDP, and the ability of spoofing source addresses. DoT improves this
aspect of DNS operations considerably.

The incremental development of DoT, compared to Do53, is relatively minor,
and from a software perspective, very constrained in the additional code,
pathways, and ability to inspect/audit the changes to the software. This is
especially true when the same software packages are used, with the DoT
being essentially an upgrade. Upgrade/downgrade of software used by DNS
operators means configuration files, zone files, etc., don't require
modification, limiting the impact of requirements to perform roll-backs if
needed.

DNS operators in enterprises often are required to support multiple
environments, including end-users with a large variety of COTS (commercial
off the shelf) equipment, including multiple form factors (desktops,
laptops, tablets, mobile devices), multiple vendors, multiple OS (even
within vendors), multiple applications (everything from OS stub resolvers,
to mail packages, to browsers, to VPN software, to third party
applications), across possibly large ranges of major and minor versions.

The support for multiple environments of greatly simplified, if the same
DNS software packages can be used in multiple environments, including using
a small number of shared caching resolvers (each with their own security
profiles, configurations, etc.).

The operations and support issues strongly lends itself to use of DoT for
inter-security zone resolution, and for shared use across apps/OS/etc which
have DoT enabled and configured. The use of DoT at an egress boundary for
an enterprise, provides the greatest level of all of the features required
and/or desired, for the variety of clients across the enterprise. Operating
the DoT server itself enables all of the functions mentioned above in the
Do53 scenarios (monitoring, alerting, policy, logging, and mitigations). To
the degree permitted/mandated, other aspects of the larger security/privacy
can be centrally administered and enforced (obviously depending on DNS
software implementations providing the necessary features). Examples would
include protection of PII and/or anonymization, log encryption/redaction,
etc.

Other security issues not discussed previously in this thread, which
provide context and motivation:
Case #1:
One major enterprise concern, is "information leakage". DNS queries which
get sent in the wrong direction, may leak sensitive information about
infrastructure. The sensitive material is often the domain within which a
query name exists, such as internal-only domains. As an example, PCI-DSS
considers infrastructure information, including names, to be sensitive
data. Depending on the security zone for the corresponding domain names,
leaking those queries may violate PCI-DSS (this is a bad thing). Thus, DNS
operations for these kinds of environments requires that the DNS resolution
be local, and available for inspection, logging, alerting, and blocking,
and thus the network operations must be able to block any DNS resolution
outside of the specific DNS servers and protocols explicitly in use. When
combined networks for users and non-user machines (servers) exist, the
servers' requirements trumps any desire to offer users third party
privacy-enabled DNS servers, regardless of protocol (DoH or DoT). Providing
users with equivalent services in-house, generally favors single-protocol
and same-vendor solutions, i.e. DoT on existing DNS software platforms.

Case #2:
There exists malware "in the wild", which thankfully has only been seen in
very limited environments, that makes use of DNS as part of its primary
functionality.
Rather than trying to be sneaky, and re-implementing whatever resolver
capabilities it needs, this malware use case is actually orthogonal to DNS
resolution per se.
What it is doing, is using DNS queries (and in some cases responses), as a
covert communication channel.
One know case involves data exfiltration using a flow:
data->encryption->chunking->encoding, where the encoding is a single DNS
label. The label has a specific domain appended, and the query is sent.
The result is ignored, and the malware only requires the public encryption
key to do its dirty work. It leverages the host's on DNS stub, and the
malware is extraordinarily simple and small as a result.
DNS operators are unable to see the unencrypted content or infer anything
about the query names, other than observing relatively high levels of
entropy.
Exfiltration done slowly is likely to not be detected (or even be
detectible). Visible entropy can be reduced by the malware by using simple
"book codes" (old cipher techniques), at the expense of lowering effective
transmission rate.

^^ This is why operators are likely to insist on having DoT -- there is no
guarantee the operators will be able to actually detect such malware, but
if they do, they will have the ability to mitigate (by blocking) the
outbound query traffic necessary for the data exfiltration. If the DNS
operator is not able to MITM the outbound DNS queries, this detection and
mitigation becomes categorically impossible.

Third party (global) operators of DNS resolution have, at least in some
cases, indicated that they will support both DoT and DoH.

The missing element is the support for both DoT and DoH on the part of ALL
browser vendors.

The second element is the requirement that DoH for sure, and to a lesser
degree DoT, needs to be STRICTLY OPT-IN. (This probably requires a new
thread to explain, but the short explanation is, "Did we collectively learn
nothing from SPAM and the opt-out vs opt-in issue?").

Thirdly, the user choice should generally be third-party operator, with
possibly preferences on DoT vs DoH (which has higher preference). A given
operator accessible over DoH or DoT is what the user cares about. Unless
there is any clear evidence/proof that either has unique vulnerabilities,
my assertion is as follows: If the destination operator is the same, the
security/privacy of DoH and DoT are identical. If a network operator
chooses to only permit one of the two protocols (DoH or DoT), that should
not have a negative impact on users, if their choice of provider is
accessible over the non-blocked protocol. (Limiting choice to specific
operators of DoH/DoT, including in-house enterprise servers, is an
orthogonal issue.)

I hope this provides sufficient "color" to explain to implementers (e.g.
browser folks) who don't currently "do" DNS operations, why it is that DNS
operators have requirements, and not just opinions, on the underlying
issues. In many cases the decisions involve approvals made by senior
managers (e.g. CIO or CISO), or are constrained by per-jurisdiction
regulations or laws (GDPR), or involve business decisions based on scalable
deployment and operations. There are often accompanying issues, such as
contracts for software support by vendors of DNS software, feature parity
and compatibility, and constraints which are not necessarily obvious.



>
> Specifically, you're preferring DOH but your stated
>> goals are "Stronger privacy and security." and "Hopefully, some
>> performance wins.", without providing rational for each of the potential
>> solutions.  DNS plain clearly doesn't meet the first, but likely does
>> the second.  But you fail to provide a goal that distinguishes why you'd
>> prefer DOT vs DOH to meet both these goals.
>>
>
I have a similar follow-up question:
I believe that both DoH and DoT construct ordinary DNS Messages (in wire
format), "under the hood", and those messages are then encapsulated over
whatever mechanism the respective protocols employ (naked DNS messages over
a TLS-encrypted TCP session for DoT, and HTTP GET or POST (per DoH
standard) over TLS-encrypted channel (HTTPS) for DoH.

Since both standards require that the query and answer be constructed and
parsed/handled, regardless of transport mechanism, this suggests that
browser support for DoT should be very close to trivial, if not actually
trivial.

Am I missing something, and does this potentially encourage adoption of DoT
by browsers as a first-class supported DNS resolution mechanism?

(Please do not suggest plug-in use, lest this discussion devolve into
impolite exchanges.)

One additional question:
If DoH is supported (with or without DoT support), is there any potential
(and dare I suggest, plan,) to augment the DNS resolution by browsers, to
add support for DANE? Especially for the ability to deploy DoH and DoT
servers, DANE would be a huge win. (Please say "yes". Pretty please, with
sugar on top.)

Brian