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

[Ted Hardie <[e-mail]>]

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]> 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
>
>
>