Re: [Add] [EXTERNAL] My single use case

[Ben Schwartz <[e-mail]>]

On Thu, Sep 10, 2020 at 11:31 AM Tommy Jensen <Jensen.Thomas=
[e-mail]> wrote:

> > As a new device or application, when I join a network that I have no
> prior relationship with or configuration for, I want to discover the DoT or
> DoH resolver that corresponds to the Do53 resolver offered by that network
>
> My issue with this scenario is I see "discover a DoT/DoH" server
> differently from "discover a DoT/DoH server that corresponds to the Do53
> resolver". The former doesn't require authentication to meet security
> parity with Do53 server use today. The latter is a novel concept I would
> prefer to be authenticated. This means for existing TLS infra would only be
> possible for publicly routable IP addresses, a subset of the
> network-offered servers out there.
>

I think of this as a distinction about how the correspondence is
validated.  In one scenario, the client validates the correspondence
topologically.  That could be the IP network topology (e.g. using the same
IP for both Do53 and encrypted DNS) or the DNS lookup topology (in-band
upgrade, with or without forwarder bypass).

In the other scenario, correspondence is validated using a PKI with its own
validation rules.

Which of these is appropriate depends on the intended user experience (does
the user see this IP address?) and also threat modeling questions (what
does it mean to own an IP address?).  This seems like a good example of how
even this seemingly narrow use case has a wide variety of potential
variations and complexities.  Here are some more potential complications:

* Increased query linkability, if multiple users' queries would otherwise
be mixed together by a NAT or a DNS forwarder.
* When should the client validate the certificate chain, and to which trust
anchor?
* Enabling a DNS-poisoning attacker to capture all DNS traffic
* Enabling a transient attacker to become persistent
* Defending against a passive+drop attacker who is trying to prevent upgrade
* Defending against a late-arriving attacker who is trying to trigger a
downgrade

All of these apply to the narrow use case that Martin highlighted.  When we
talk about requirements, these are the kinds of questions I'd like to see
the group considering.  On some points, I think we will find consensus; on
others, I think we will need to leave options open for implementers.  Which
properties we can provide will depend on the details of our protocol design.

For developing requirements, I agree that we should focus on this use case,
which deserves its own requirements draft.  When it's time to adopt
solutions, I'd prefer to consider the bigger picture, and try to find a
solution that extends naturally to other use cases as well.