Subject: [Add] Not a good BoF meeting

From: Stephane Bortzmeyer <[email-masked]>
Date: Wed, 24 Jul 2019 12:56:43 -0400

In my opinion, the ADD BoF yesterday was not good. First, it did not
stand by its name. The issue of Applications Doing DNS was just one
point, lost among many others. This mailing list has the same issue,
by the way, so I suggest to rename it, although I don't know to what,
since people here seem to talk about a lot of unrelated
subjects. (Remember that if you want to talk about DoH, there is
[email-masked], and if you want to talk about DNS operations, there is
[email-masked], the place where we overload camels.) I do not see
anything serious coming from such confusion.

A similar problem occured for the "operational issues" question. Under
this umbrella, I've heard people talk about:

* policy requirments, often outrageous (requiring DNSSEC validation or
the use of the IANA root for DoH resolvers, as if we did anything like
that for other DNS resolvers),
* technical tuning of servers (a nice thing, although may be not
something that should be done in the IETF),
* discovery of local DoH resolvers (in my opinion, a flawed idea from the
start: if you trust the local network, you don't need DoH, if you
don't, you won't trust its DoH announces anyway),
* various rants about how DoH would prevent a third-party to see and
modify the DNS messages (which is DoH's main goal, so it's not a
problem),
* and many others.

I suggest that this list does not do anything useful at this time. I
have nothing about specific work on specific points, but I don't think
general "everything I do not like about DoH" slides will help.

---

From: Jim Reid <[email-masked]>
Date: Wed, 24 Jul 2019 19:05:13 +0100

> On 24 Jul 2019, at 17:56, Stephane Bortzmeyer <[email-masked]> wrote:
> 
> I suggest that this list does not do anything useful at this time.

Plenty of others have a different PoV.

> I have nothing about specific work on specific points, but I don't think

[Citation needed.] No such slides were presented yesterday and AFAICT that opinion isn't being expressed on this list.

---

From: Thomas Peterson <[email-masked]>
Date: Wed, 24 Jul 2019 19:16:02 +0100

As the author of a draft (draft-peterson-doh-dhcp[0]) that provides 
discovery of DoH resolvers, I disagree as "trusting the network" is more 
complicated when there may be many operators and users in a given 
network, any of whom could be a threat. To me it is a positive if 
operators can provide secure means of DNS resolution within their 
network, and clients can choose to use them or not.

Regards

0: https://datatracker.ietf.org/doc/draft-peterson-dot-dhcp/

---

From: Vladimír Čunát <[email-masked]>
Date: Wed, 24 Jul 2019 22:22:09 +0200

On 7/24/19 8:16 PM, Thomas Peterson wrote:
> discovery of DoH resolvers, I disagree as "trusting the network" is
> more complicated when there may be many operators and users in a given

I'm fairly sure this has been mentioned a few times, but let me repeat
it: if you don't (fully) trust the network, how can you bootstrap your
trust? (e.g. over insecure DHCP)  You may get some certificate name or
key pin, but if you can't first "secure" the channel over which you
obtain those, I don't think you get much more real security.  With some
additional "approval" from the user perhaps, but that would again run
into the same informed-consent issues - and the attacker could e.g. be
running a service with just a tiny "typo" in the domain name.

> Plenty of others have a different PoV.

I agree that the ADD "group" is still struggling with finding a
"charter", basically, and I'm afraid I can't see much forward progress
(e.g. since the previous IETF) or satisfaction of a larger fraction of
the participants so far.

Much of the struggle seems about *who gets the control* over DNS or even
other traffic (by default), which might be really hard to get a true
consensus about, and... even if IETF manages to publish a position that
some parties should relinquish (part of) this control, I'm a bit
skeptical whether that act itself would have a significant impact.  In
this case it doesn't even seem viable to technically enforce that apps
don't tunnel information somewhere (without drastic measures like MITM
everything).  It's surely worth trying to discuss this and work towards
some compromise to diminish the arms-race, but how to progress the
discussion forward?

--Vladimir

---

From: Paul Wouters <[email-masked]>
Date: Wed, 24 Jul 2019 16:50:06 -0400

Sent from mobile device

> On Jul 24, 2019, at 16:22, Vladimír Čunát <[email-masked]> wrote:
> 
> obtain those, I don't think you get much more real security.

The preconfigured dnssec root key.

> (e.g. since the previous IETF) or satisfaction of a larger fraction of

The discussions on the list and in the group only showed the problem is touching so many issues that it’s hard to contain.

I’m not sure I see a useful future for “ADD”, but it was a terrible name to start so letting it die isn’t the worst.

Paul

---

From: Brian Dickson <[email-masked]>
Date: Wed, 24 Jul 2019 17:06:44 -0400

> The preconfigured dnssec root key.

And just to complete the picture for those less familiar with DNSSEC and
DANE:

   - the root key gives you validation of signatures in the root zone,
   including for the chained trust links across DNSSEC-secure delegations (to
   TLDs)
   - The DNSSEC-signed TLDs (with KSK and ZSK signed by KSK, whose finger
   print is the chained trust record "DS"), give you similar chained trust
   links downward...
   - Eventually, you end up inside a DNSSEC-signed zone, which contains
   - signed A/AAAA records (thus you have cryptographic proof of the values
      for the IPv4 and IPv6 addresses), plus
      - signed TLSA records which provide cryptographic proof of values for
      either the CA or the end entity cert (EE),
         - as either full certificate or as fingerprint,
      - Thus, completing the secure bootstrap to a TLS certificate  (or
   fingerprint) plus IPv4/IPv6 address(es)

The above supports some forms of aliasing along the way (CNAME and DNAME),
as well, which are also DNSSEC-compatible (e.g. signed CNAME or DNAME
records, if they point to DNSSEC-signed targets)

You can see why the DNS folks are proponents of DNSSEC and DANE, in this
discussion.

Without these, secure bootstrap is a very difficult problem.

With DNSSEC and DANE, the problem is already solved, modulo deployment of
DNSSEC by zone owners, and modulo implementation of native DANE in browsers.

Brian

---

From: Rob Sayre <[email-masked]>
Date: Wed, 24 Jul 2019 14:29:56 -0700

> And just to complete the picture for those less familiar with DNSSEC and

I think it would be good to define some terms here.

DNSSEC was first standardized in 1999, as RFC 2535. It was then obsoleted
in 2005 by RFCs 4033-4035.

DANE is RFC 6698, standardized in 2012.

thanks,
Rob

---

From: Vladimír Čunát <[email-masked]>
Date: Thu, 25 Jul 2019 10:28:54 +0200

> The preconfigured dnssec root key.

To be clear, I only had DNS *privacy* in mind, as validation of DNSSEC
seems a much easier problem here, not really interesting in ADD.  For
privacy, web CAs or DNSSEC+DANE (yay! more details written by Brian
Dickson) can be used to authenticate the DoT/DoH connections *against a
name*, but for that to be meaningful you need to determine that name in
some secure way.  Otherwise you can end up "securely" sending all your
DNS to https://black.hat.com/doh

BTW, even if we found a technical way how to securely determine that a
certificate/name/server belongs to "current network provider" (without
interacting with the user), it might still be questionable to assume
that the user actually wants to trust this particular network provider. 
For example, Firefox apparently isn't generally comfortable with such an
assumption.  But *if* we had this technical means, I'd personally be
satisfied with a simple dialog asking the user whether the current
network is to be trusted (e.g. "public" vs. "private" button in Windows).

--Vladimir