Re: [DNSOP] [Doh] New I-D: draft-reid-doh-operator

[Michael Sinatra <[e-mail]>]

I realize you're responding to Paul, but your message below did pique
(in a good way) my thinking and the distinction in my mind, as an
operator, between DoH and DoT (and other forms of encrypted
communication).  I am top-posting intentionally because I am responding
to your entire message.

I support TLS 1.3 as written.  I support DoT.  I support DNSSEC,
HTTPS-everywhere, HSTS, etc.  I am a big fan of confidentiality and
privacy.  DoT gives us that.  DoH does too, but it also gives us
protocol obfuscation, and that makes me uneasy as an operator.  I
understand that in certain environments, this is seen as a good thing,
but I can also imagine a number of environments where this approach will
create considerable collateral damage and greatly hamper efforts at risk
mitigation.  Put differently, if we try to work around what our CISO is
legitimately trying to do, they will come out with bigger and more
expensive ban-hammers[1], and that will potentially lead to an arms race
of more workarounds and even bigger ban-hammers.

I think DoT makes a good compromise between confidentiality and protocol
transparency.  DoH does not because it intentionally works against
protocol transparency.  Again, that's what makes me uneasy and why I
support the efforts behind the various internet-drafts that we're
discussing here.

michael

[1] As an example, I am personally and practically opposed to inline TLS
decryption in most enterprises.  DoH gives further ammo for security
folks to insist on inline TLS decryption, IMO.  DoT, not as much, since
the protocol can be easily identified on the wire and any necessary
actions taken.  Manipulating DoT transactions is a far cry from
manipulating/decrypting all TLS...

On 3/12/19 1:52 PM, Ted Hardie wrote:
> Paul,
> 
> Since it is apparent our disagreement is at a more fundamental level, I
> will make only two further comments.
> 
> The first is that you recently chided someone for using the word "rant",
> saying that it would "diminish and disrespect" someone's words.  In the
> note below you use terms like "warfare" to characterize the work of the
> authors; that is both inflammatory and disrespectful.  The authors
> worked on a chartered working group item throughout the IETF process. 
> You disagree with the security trade-offs made in the chartering and
> execution of that work, and discussion of that disagreement will
> hopefully be fruitful.  But  if you want their respect of your opinion,
> according them the respect due theirs will go a long way; they did not
> make these choices arbitrarily.
> 
> My second comment is to point out that the IETF has been heading this
> way for about five years now.  The IAB formalized its early support of
> this approach in November of 2014 with this text:
> 
> The IAB urges protocol designers to design for confidential operation by
> default.  We strongly encourage developers to include encryption in
> their implementations, and to make them encrypted by default.  We
> similarly encourage network and service operators to deploy encryption
> where it is not yet deployed, and we urge firewall policy administrators
> to permit encrypted traffic.
> 
> We believe that each of these changes will help restore the trust users
> must have in the Internet.  We acknowledge that this will take time and
> trouble, though we believe recent successes in content delivery
> networks, messaging, and Internet application deployments demonstrate
> the feasibility of this migration.  We also acknowledge that many
> network operations activities today, from traffic management and
> intrusion detection to spam prevention and policy enforcement, assume
> access to cleartext payload.  For many of these activities there are no
> solutions yet, but the IAB will work with those affected to foster
> development of new approaches for these activities which allow us to
> move to an Internet where traffic is confidential by default.
> 
> By that point, the IETF working groups were already in formation.. 
> Moving the DNS toward encryption has been going on since DPRIVE and has
> been accompanied by the rise of transports like QUIC which are encrypted
> by default.  You have been working around that, rather than developing
> new practices.  I invite you instead to consider how you can accomplish
> what you need to in an Internet where all traffic is confidential. 
> Enterprises are currently doing that via managed software and
> environments, and that approach seems to be well in-line with your
> practices below.  Using resolution systems for this will not accomplish
> what you need now, nor will it do so going forward; it is time for a
> different approach, rather than seeking to return to cleartext.
> 
> The situation that moved this community to that stance was well-laid out
> in IETF 88.  We must acknowledge that not all devices which are on-path
> are controlled by entities known to the user or network operator and not
> all of them are acting in the interests of those parties.  Protecting
> against that threat requires us to change our ways.  Please help, rather
> than working around the effort.
> 
> regards,
> 
> Ted Hardie
> (wearing no hats)
> 
> 
> On Tue, Mar 12, 2019 at 1:22 PM Paul Vixie <[e-mail]
> <mailto:[e-mail]>> wrote:
> 
>     On Tuesday, 12 March 2019 19:15:16 UTC Ted Hardie wrote:
>     > ...
>     > > that's precisely the goal, because very few network operators can
>     > > preordain the users and apps that will connect through their
>     networks.
>     >
>     > I do not believe this goal is met by what you describe, since an
>     > application can use a proprietary resolution service in its flows.
> 
>     rogue flows have their own accounting. my problem isn't with one-off's,
>     because traditional security is anomaly-based. DoH, by folding
>     control plane
>     data into previously non-anomalous flows, presents a new problem. if
>     CF and G
>     and IBM and Cisco decide to offer DoH on the same IP address that
>     they offer
>     API's and services i actually do need or want to permit, i'm going
>     to have to
>     increase my investment.
> 
>     this equation, where something is created which is a danger to me,
>     which
>     blends in with the crowd of things that are not dangerous to me, is
>     the method
>     by which DoH achieves its stated aim, "prevent on-path interference
>     in DNS
>     operations." all war is economics. they are increasing my costs,
>     deliberately.
> 
>     i am on-path and i intend to interfere. at whatever cost that may
>     be. i also
>     reserve the right to re-externalize some or all of those new imposed
>     costs.
> 
>     > Imagine for a moment an application on a smart TV that wants to
>     provide
>     > content from the closest server which contains that content.  ...
>     Blocking
>     > destinations for which you have seen no resolution events will
>     work for a
>     > subset of these cases, but it won't work when the resolution
>     points to a
>     > common CDN destination.  That approach will, of course, also have
>     a wide
>     > variety of failure modes when the resolution event data is
>     incomplete for
>     > timing or other reasons; it will also block all of the flows which MUD
>     > would handle.
> 
>     generally speaking, security policies break down into two
>     categories. allow
>     all except some, or deny all except some. which one an operator
>     chooses will
>     depend on their goals, budgets, and in particular, the cost of anomaly
>     detection. it's the change in cost of anomaly detection,
>     deliberately intended
>     by the authors of RFC 8484, which is at the root of some very
>     expensive policy
>     choices that the rest of us must now make.
> 
>     your smart-tv example is not involved in that causalality path.
>     noting also, i
>     have a TV which offers the kind of feature you describe, but only if
>     i accept
>     its software license. (something to do with GDPR, i suspect.) so i
>     did not
>     accept that license, and as a result, i have a disconnected device
>     whose
>     flaws, both now known and not yet known, will pose no threats here.
>     my TV, my
>     rules.
> 
>     > > to the extent that monitoring ('dnstap') and controlling (DNS
>     RPZ) dns
>     > > lookups by connected users and apps is considered a vital local
>     security
>     > > policy, attempts at such "pass through" must be made to fail.
> 
>     > Those are security mechanisms, rather than policy, and it may be worth
>     > teasing apart what the actual desired security policy is.  You may
>     find
>     > that it is more easily implemented at the routing layer than the
>     resolution
>     > system in the light of proprietary resolution systems and DoH.
> 
>     to be clear, the policy is, "allow all, except some". i implement as
>     much of
>     this policy as possible at the routing layer, and i do my research on
>     proprietary resolution systems to decide whether i can tolerate the
>     risks of
>     devices which use such things. (so, no nest thermostats here, the
>     TV's are not
>     smart, and the apple home pods are in their not-logged-in state.)
> 
>     it is the standards nature of DoH that amplifies its imposed costs.
>     i could
>     simply outlaw by IP or port# a proprietary or otherwise bespoke
>     protocol.
>     (working out with my kids what online games require what
>     permissions, has been
>     burdensome on both me and them.) DoH, by _intending to bypass_ network
>     operator policy DNS, and my seamlessly hiding in the crowd of TCP/443
>     transactions now made indiscernible  by TLS 1.3 and ESNI, is an act of
>     economic warfare against all RDNS control plane owners. (deliberately.)
> 
>     vixie
> 
> 
> 
> _______________________________________________
> DNSOP mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dnsop
>