Subject: [Add] Review of draft-box-add-requirements-01.txt

From: Eric Rescorla <[email-masked]>
Date: Sat, 14 Nov 2020 15:49:19 -0800

This document is improved by restricting itself to one use case.
Thanks.

More comments below.

S 3.

   The network's recommended unencrypted resolver may have a number of
   properties that differ from a generic resolver.  It may be able to
   answer names that are not known globally, it may exclude some names
   (for positive or negative reasons), and it may provide address
   answers that have improved proximity.  In this use case it is assumed
   that the user who chose to join this network would also like to make
   use of these properties of the network's unencrypted resolver, at
   least some of the time.

This seems like a terrible assumption. As has been discussed many
times, users basically have no idea about IETF, and so why would you
think they want to "make use of" various filtering or surveillance
properties, let alone cases where the resolver injects its own data
as in captive portals. I understand what you're trying to do here,
but I think what you need to say is something quite different:

   The objective of this use case is simply to replace Do53 with
   an encrypted DNS protocol to the same resolver. Note that
   the network's recommended unencrypted resolver may have a number of
   properties that differ from a generic resolver.  It may be able to
   answer names that are not known globally, it may exclude some names
   (for positive or negative reasons), and it may provide address
   answers that have improved proximity. The user may or may not
   desire these properties and may or may not be aware of them,
   but for the purposes of this use case, we are not attempting
   to change these properties, but merely to provide the user
   with encrypted transport.

   Using an encrypted and authenticated resolver that is equivalent to
   the one provisioned by the network can provide several benefits that
   are not possible if only unencrypted DNS is used:

   ...

   *  Authenticate that the DNS resolver is the correct one

   *  Verify that answers come from the selected DNS resolver

"can" is doing a lot more work here than I am comfortable with.
Ignoring the case where the resolver is *not* equivalent to the one
provided by the network, which you're just assuming is not the case,
in many cases there is real uncertainty about which network is being
joined. The most obvious case is coffee shop networks, hotspots,
etc. in which the user may think they are joining the network
associated with a given establishment (say Starbucks) but they are in
fact joining the attacker's network. While it may be the case that
they are legitimately upgraded to the attacker's Do[HTQ] server, I
don't think you can call this "authenticating that the DNS resolver is
the correct one".

S 3.1.
   Given two resolvers A and B, equivalence is the claim that A and B
   can provide the same upper-layer DNS function to the client.  This
   does not include the DNS transport protocol (e.g.  Do53 or DNS-over-
   HTTPS) which can differ between equivalent resolvers.  To provide
   equivalence it is frequently likely to be the case that A and B are
   operated by the same administrative domain, but this document does
   not require that.

This doesn't seem right. Suppose I stand up a fake DoT resolver that
just proxies traffic to the Do53 resolver and then sends me a copy.
That's providing the same service as the Do53 resolver (you might
argue that the Do53 resolver isn't leaking the traffic to me and
so the service isn't the same, but if I'm an on-path attacker, the
service actually is the same as I get the data that way).

   *  The local network can claim that one or more encrypted DNS
      resolvers (B, C, etc) are equivalent to the Do53 resolver (A) it
      has offered.  This is known as network-identified.

   *  During communication with the (often unencrypted) resolver (A),
      this resolver can claim that one or more encrypted DNS resolvers
      (B, C, etc) are equivalent.  This is known as resolver-identified.

These seem like two options, but they're not the only one. For instance,
neither of these covers the preconfigured SPAU lists that Chrome and
Edge use.

   Network-identified is preferred since it comes from the same source
   of information, and removes the need to talk to the Do53 resolver at
   all.  However it cannot be the sole mechanism, at least for several
   years, since there is a large installed base of local network
   equipment that is difficult to upgrade with new features.  Hence the
   second mechanism must support being able to announce an equivalent
   resolver using only existing widely-deployed DNS features.

I'd prefer this document not to take a position on what technical
approach is preferred at this time. For instance, if we have to do
resolver-identified anyway, it's not clear that having two mechanisms
is in fact better.  It's not clear to me if 3.2 and 4 are requiring
support for network-identified, but if so it should be a topic of
discussion.

S 5.
The way that this section is written implies that it is preferable
to have encrypted transport terminated at the local resolver rather
than at some central caching resolver. While I agree that this has
certain benefits, it also has a number of operational drawbacks
(for instance, these local access points/routers are often quite
insecure). This section should be adjusted to be more neutral.

S 6.
   *  Cause clients to use a discovered resolver which has no
      authenticated delegation from a client-known entity.

It's not clear to me what this means. As read literally, why
doesn't it rule out basically all of the versions where
the client receives some unauthenticated Do53 message that
says "DoT at this same address"?

S 7.
     | R1.1        | Discovery MUST provide a local network the      |
     |             | ability to announce to clients a set of, or     |
     |             | absence of, equivalent resolvers.               |

I don't agree that this is a requirement. See my comments about S 3.1.
above.

     | R1.3        | Discovery MUST support at least one encrypted   |
     |             | DNS protocol.                                   |
     +-------------+-------------------------------------------------+
     | R1.4        | Discovery SHOULD support all standardised       |
     |             | encrypted DNS protocols.                        |

I don't understand these. Are you saying it's not a requirement to
be able to indicate all the standardized protocols? That seems like
it would be a fail.

     | R2.1        | Networks MUST be able to announce one or more   |
     |             | equivalent encrypted DNS resolvers using        |
     |             | existing mechanisms such as DHCPv4, DHCPv6,     |
     |             | IPv6 Router Advertisement, and the Point-to-    |
     |             | Point Protocol.                                 |

Again, I don't agree.

     | R2.2        | The format for resolver information MUST be     |
     |             | specified such that provisioning mechanisms     |
     |             | defined outside of the IETF can advertise       |
     |             | encrypted DNS resolvers.                        |

At most a SHOULD

     | R5.2        | Threat modelling MUST assume that there is a    |
     |             | passive eavesdropping attacker on the local     |
     |             | network.                                        |
     +-------------+-------------------------------------------------+
     | R5.3        | Threat modelling MUST assume that an attacker   |
     |             | can actively attack from outside the local      |
     |             | network.                                        |

Normally one wouldn't call these requirements.

-Ekr

---

From: Chris Box <[email-masked]>
Date: Sun, 15 Nov 2020 19:04:26 +0000

Ekr,

Thanks for the review. Some quick answers to your points below.

On Sat, 14 Nov 2020 at 23:50, Eric Rescorla <[email-masked]> wrote:

> I understand what you're trying to do here,

Your wording, especially the last half, is a substantial improvement. I'll
look to merge this. In the first sentence I'd like to modify "to the same
resolver", since we are only trying to reach an equivalent resolver, and it
may be physically separate from the Do53 so I wouldn't consider them "same".

> don't think you can call this "authenticating that the DNS resolver is

Agree on the uncertainty, but not yet sure what the right wording is here.

> This doesn't seem right. [Discussion of B being an attacker that offers
> the same DNS responses but also shares communications]
>

Again, not sure what kind of different/stronger definition would remove
this risk. Perhaps it can be explored in the meeting tomorrow.

> neither of these covers the preconfigured SPAU lists that Chrome and

Yes, preconfigured lists could be another way to claim equivalence. But are
they useful in the context of ADD which is all about automatic discovery?

> approach is preferred at this time.
>

Agree - you're not the first to point this out and it will be removed.

> insecure). This section should be adjusted to be more neutral.
Agree. Central can be better.

> says "DoT at this same address"?

I'll need to think about this some more.

> I don't agree that this is a requirement. See my comments about S 3.1.

I think you're saying that network-identified is not mandatory, and may not
feature at all in the solution?

>      | R1.3        | Discovery MUST support at least one encrypted   |

I'm saying it needs the ability to point users to DoT resolvers and DoH
resolvers. If it couldn't do one of those it would be less desirable. If
DoQ is published as an RFC, it would be useful for the ADD discovery
protocol to support DoQ too. This is *not *the same as having reserved bits
for each transport protocol, as draft-btw-add-home-10 does.

>      |             | encrypted DNS resolvers.                        |

Agree.

>      |             | passive eavesdropping attacker on the local     |

Are you proposing they are deleted?

Chris

---

From: Eric Rescorla <[email-masked]>
Date: Sun, 15 Nov 2020 11:44:47 -0800

> may be physically separate from the Do53 so I wouldn't consider them "same".

Agreed.

> Agree on the uncertainty, but not yet sure what the right wording is here.

Yeah, I think the whole thing just needs to be a lot more nuanced.

> this risk. Perhaps it can be explored in the meeting tomorrow.

I suggested some text in the DEER thread.

> Yes, preconfigured lists could be another way to claim equivalence. But
> are they useful in the context of ADD which is all about automatic
> discovery?
>

Well, they are automatic for the client, no?

Imagine a central database that listed the IPs of resolvers and their
corresponding equivalent resolvers (with the mechanism for populating that
database TBD, but potentially via an ACME-like verification of control
mechanism). This seems like it would be roughly isomorphic in functionality
to the proposals you have here, except with a different signaling
mechanism. I'm not saying it's the best design, but rather that it's not an
invalid design. This document should not constrain the design space.

> I think you're saying that network-identified is not mandatory, and may
> not feature at all in the solution?
>

Yes.

> protocol to support DoQ too. This is *not *the same as having reserved
> bits for each transport protocol, as draft-btw-add-home-10 does.
>

So, this text would be satisfied if this solution could only point users at
DoH resolvers but not DoT resolvers. If we are to list requirements like
this (which I am somewhat skeptical of ) then I think this document ought
to require that the solution be able to support both DoH and DoT and be
extensible to new protocols.

> Are you proposing they are deleted?

Yes.

-Ekr

---

From: Andrew Campling <[email-masked]>
Date: Sun, 15 Nov 2020 21:17:31 +0000

On Sun, Nov 15, 2020 at 19:45 Eric Rescorla <[email-masked]<mailto:[email-masked]>> wrote:

> On Sun, Nov 15, 2020 at 11:04 AM Chris Box <[email-masked]<mailto:[email-masked]>> wrote:

On Sat, 14 Nov 2020 at 23:50, Eric Rescorla <[email-masked]<mailto:[email-masked]>> wrote:

Yes, preconfigured lists could be another way to claim equivalence. But are they useful in the context of ADD which is all about automatic discovery?

> Imagine a central database that listed the IPs of resolvers and their corresponding equivalent resolvers (with the mechanism for populating that database TBD, but potentially via an ACME-like verification of control mechanism). This seems like it would be roughly isomorphic in functionality to the proposals you have here, except with a different signaling mechanism. I'm not saying it's the best design, but rather that it's not an invalid design. This document should not constrain the design space.

Based on the recent briefing by one of the regulators, such an approach could well see any clients being classified as data controllers under GDPR.  This doesn’t make it a bad solution but it may make it less attractive to some.

Andrew

---

From: Eric Rescorla <[email-masked]>
Date: Sun, 15 Nov 2020 13:26:31 -0800

On Sun, Nov 15, 2020 at 1:17 PM Andrew Campling
<[email-masked]> wrote:

> On Sun, Nov 15, 2020 at 19:45 Eric Rescorla <[email-masked]> wrote:
>
>
>
> Based on the recent briefing by one of the regulators, such an approach
> could well see any clients being classified as data controllers under
> GDPR.  This doesn’t make it a bad solution but it may make it less
> attractive to some.
>

I'm not really following your argument here: I'm not talking about a system
that is operated by the clients but rather a system that is isomorphic to
the approaches listed here but in which the communication is via a central
(potentially open) database rather than via DNS or DHCP. If it makes it
clearer, consider a version where the database just consists of HTTPSVC
records as in DEER that are keyed under the resolver IP.

In any case, I'm not arguing for this system; I'm arguing that the
requirements document shouldn't limit the technical options.

-Ekr