Subject: [Add] My single use case

From: "Martin Thomson" <[email-masked]>
Date: Fri, 11 Sep 2020 01:07:29 +1000

My preference is to tackle just this:

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.

This might need the full matrix of DoT/DoH, v4/v6, with/without a forwarder, but this is fundamentally just a single use case.

Specifically, I want to NOT learn about whether the resolver does qname minimization or DoT to the authoritative or whether it does the eDNS client subnet or different policies with respect to what is answered or anything else that might make a decision to use this alternative complicated.  Existing methods don't provide this information.  I don't want a protocol that does anything fancy because that makes the decision complex.

---

From: Tommy Jensen <[email-masked]>
Date: Thu, 10 Sep 2020 15:27:19 +0000

> Specifically, I want to NOT learn about whether the resolver does [...]

+1, I couldn't agree more. One exception would be zone ownership for me as I don't consider that a policy, but I agree that's a scenario separate from the one you are describing and should be kept separate.

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

Is the difference important to you? Would you be fine with the network offering the DoT/DoH server in the first place? If not, I just want to better understand why not.

Thanks,
Tommy

================================================

The latest in Windows Internet Protocols:

  Native gRPC support: https://aka.ms/grpcblogpost

  DNS over HTTPS: https://aka.ms/dohblogpost

________________________________
From: Add <[email-masked]> on behalf of Martin Thomson <[email-masked]>
Sent: Thursday, September 10, 2020 8:07 AM
To: [email-masked] <[email-masked]>
Subject: [EXTERNAL] [Add] My single use case

--
Add mailing list
[email-masked]
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fadd&amp;data=02%7C01%7CJensen.Thomas%40microsoft.com%7C616232632199478ff0f408d8559b51e6%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637353472875254723&amp;sdata=uBbsI9uMM7zz8N0XScTyltYtrljaz2i1rUmMaxNbdnU%3D&amp;reserved=0

---

From: "Chris Box (BT)" <[email-masked]>
Date: Thu, 10 Sep 2020 16:31:47 +0100

Hi Martin,

Appreciate you may not be able to answer this until tomorrow but I'd like
to map your statement to sections of the draft.

I think this case is a simpler version of section 3.1 (both 3.1.1 and
3.1.2). I presume you are excluding VPNs (3.3) here, since they are
networks in which you have a prior relationship.

Personally I would say part of "the matrix" of this use case should involve
section 4.1's learning about the scope of names that are relevant.

Chris

On Thu, 10 Sep 2020 at 16:08, Martin Thomson <[email-masked]> 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.
>
> This might need the full matrix of DoT/DoH, v4/v6, with/without a
> forwarder, but this is fundamentally just a single use case.
>
> Specifically, I want to NOT learn about whether the resolver does qname
> minimization or DoT to the authoritative or whether it does the eDNS client
> subnet or different policies with respect to what is answered or anything
> else that might make a decision to use this alternative complicated.
> Existing methods don't provide this information.  I don't want a protocol
> that does anything fancy because that makes the decision complex.
>
> --
> Add mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/add
>

---

From: Jim Reid <[email-masked]>
Date: Thu, 10 Sep 2020 16:37:14 +0100

> On 10 Sep 2020, at 16:27, Tommy Jensen <Jensen.Thomas=[email-masked]> wrote:
> 
> +1, I couldn't agree more.

Ditto.

> One exception would be zone ownership for me as I don't consider that a policy, but I agree that's a scenario separate from the one you are describing and should be kept separate.

What has zone ownership - whatever that means - got to do with resolution transports or resolver selection? How is it relevant to this WG?

---

From: "Robert Mortimer" <[email-masked]>
Date: Thu, 10 Sep 2020 16:58:51 +0100

On 10/09/2020 16:38:32, Jim Reid <[email-masked]> wrote:

> On 10 Sep 2020, at 16:27, Tommy Jensen wrote:
>

Ditto.

Ditto again

Though I kind of see this as opportunistic - if the recommended by the network DNS server can be used more securely regardless of anything else I'd like my OS/Client/whatever to be able to take advantage of that. Even if the DNS server isn't "trustworthy" I'm still in a better position than I was using it insecurely and in most cases it's probably trustworthy enough.
-- 
Robm
873
  "Ask not what I can do for the stupid, 
         but what the stupid can do for me" - Graeme Garden

---

From: Tommy Jensen <[email-masked]>
Date: Thu, 10 Sep 2020 16:31:37 +0000

Changing subject line to avoid the noise on Martin's single use case. This is a separate topic.

>From the WG charter:

> Define a mechanism that allows communication of DNS resolver
> information to clients for use in selection decisions. This could be
> part of the mechanism used for discovery, above

If I know "doh.example.com" is authoritative for "foo.example.com", I may prefer to take *.foo.example.com queries directly to it instead of using an intermediary recursive. I consider this to be separate from policies such as "I perform filtering" because being authoritative or designated isn't a policy / requirement and I can still choose to use an intermediate recursive if I want. This information can also be readily authenticated since TLS already gives us a mechanism for conveying and validating ownership claims relative to a domain name (as opposed to a network name).

Thanks,
Tommy

________________________________
From: Jim Reid <[email-masked]>
Sent: Thursday, September 10, 2020 8:37 AM
To: Tommy Jensen <[email-masked]>
Cc: ADD Mailing list <[email-masked]>
Subject: Re: [Add] [EXTERNAL] My single use case

Ditto.

---

From: Ben Schwartz <[email-masked]>
Date: Thu, 10 Sep 2020 16:48:04 -0400

On Thu, Sep 10, 2020 at 11:31 AM Tommy Jensen <Jensen.Thomas=
[email-masked]> 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.

---

From: "Vinny Parla (vparla)" <[email-masked]>
Date: Thu, 10 Sep 2020 23:18:58 +0000

Hi,

So if I understand the statement below, it is entirely up to an algorithm of
the implementor, which could differ from endpoint to endpoint or browser to
browse, to choose either to use the authoritative vs the recursive resolver.

Did I understand this correctly?

Thanks,

-Vinny

From: Add <[email-masked]> On Behalf Of Tommy Jensen
Sent: Thursday, September 10, 2020 12:32 PM
To: Jim Reid <[email-masked]>
Cc: ADD Mailing list <[email-masked]>
Subject: [Add] Zone ownership in DNS server discovery

Changing subject line to avoid the noise on Martin's single use case. This
is a separate topic.

> part of the mechanism used for discovery, above

If I know "doh.example.com" is authoritative for "foo.example.com", I may
prefer to take *.foo.example.com queries directly to it instead of using an
intermediary recursive. I consider this to be separate from policies such as
"I perform filtering" because being authoritative or designated isn't a
policy / requirement and I can still choose to use an intermediate recursive
if I want. This information can also be readily authenticated since TLS
already gives us a mechanism for conveying and validating ownership claims
relative to a domain name (as opposed to a network name).

Thanks,

Tommy

  Native gRPC support:  <https://aka.ms/grpcblogpost>
https://aka.ms/grpcblogpost 

  DNS over HTTPS:  <https://aka.ms/dohblogpost> https://aka.ms/dohblogpost 

  _____  

From: Jim Reid <[email-masked] <mailto:[email-masked]> >
Sent: Thursday, September 10, 2020 8:37 AM
To: Tommy Jensen <[email-masked]
<mailto:[email-masked]> >
Cc: ADD Mailing list <[email-masked] <mailto:[email-masked]> >
Subject: Re: [Add] [EXTERNAL] My single use case 

> On 10 Sep 2020, at 16:27, Tommy Jensen
<Jensen.Thomas=[email-masked]

Ditto.

> One exception would be zone ownership for me as I don't consider that a
policy, but I agree that's a scenario separate from the one you are
describing and should be kept separate.

What has zone ownership - whatever that means - got to do with resolution
transports or resolver selection? How is it relevant to this WG?

---

From: "Martin Thomson" <[email-masked]>
Date: Fri, 11 Sep 2020 12:00:27 +1000

On Fri, Sep 11, 2020, at 01:27, Tommy Jensen wrote:
> 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.
> 
> Is the difference important to you? Would you be fine with the network 
> offering the DoT/DoH server in the first place? If not, I just want to 
> better understand why not.

Thanks Tommy, that's a good question.

I worded it this way intentionally to allow for both of the interpretations you refer to:

1. What does the network claim is equivalent (DoT/DoH DHCP/RA discovery for example)
2. What does the provided Do53 resolver claim is equivalent (resinfo for example, or maybe just the opportunistic encryption stuff)

As you point out, the latter introduces an extra hop, which might then lead to difficult questions about authentication and what it means to achieve parity.  That's why this is a non-trivial use case to resolve.

I think that the difference is important and we will have to work through both paths, if only because the prevalence of forwarders might mean we need two sets of solutions.  However, it might be that people choose to adopt policies under these different circumstances once we document the properties of the end solutions.

I don't think that this necessarily depends on the creation of new infrastructure for authentication of servers that don't have IP addresses in the public address space, but it might make that results less usable for you.  It all depends on your tolerance for using unauthenticated information.

For instance, Mozilla's TRR program means that we can be more tolerant of failures in discovery, though that requires that we also be tolerant of attacks that aim to make split horizon unavailable, for example.

---

From: "Martin Thomson" <[email-masked]>
Date: Fri, 11 Sep 2020 12:10:33 +1000

On Fri, Sep 11, 2020, at 01:31, Chris Box (BT) wrote:
> Hi Martin,
> 
> Appreciate you may not be able to answer this until tomorrow but I'd 
> like to map your statement to sections of the draft.
> 

Yes, that excludes VPNs and authenticated configuration channels.  It also excludes the "alternatives" thing the draft currently describes in Section 3.

I should have said that this was the thing I want to do *first*.  I think that we'll learn a few things from doing this that will help with those other cases.  I also don't expect people to forget the secondary use cases that they care about and to use those to exert pressure on the design where we are not already fully constrained (that is, if we have to choose between two options where one might be advantageous to a different use case, that is a good way to break a tie).
 
> Personally I would say part of "the matrix" of this use case should 
> involve section 4.1's learning about the scope of names that are 
> relevant.

I don't want to include that in the first version.  My thinking is that this sort of "scoping" is something that can be layered on.

When you join a network, you need a DNS server.  That's fairly simple.  The scoping you talk about is really only necessary if you are really joining two or more networks.  So this reduces to a problem that the provisioning domains and multiple interfaces work already deals with to some extent.  

Dealing with the idea of scoping at that conceptual level is probably more fruitful as it allows our solutions to be simpler (we don't have to muddy the process of choosing to use DoT/DoH with complex questions about whether a resolver is suitable based on what scopes it serves, etc..).  It also allows the overall system to be more robust because we can build fewer, more specific, and more principled scoping mechanisms, as I believe PvDs are intended to be.

I haven't had enough sleep, so that might not be coherent.

---

From: tirumal reddy <[email-masked]>
Date: Fri, 11 Sep 2020 11:29:03 +0530

The use case looks incomplete, it does not explain how the new device is
on-boarded into the network.

-Tiru

---

From: Vittorio Bertola <[email-masked]>
Date: Fri, 11 Sep 2020 12:12:25 +0200 (CEST)

>     Il 10/09/2020 18:31 Tommy Jensen <jensen.thomas=[email-masked]> ha scritto:
> 
> 
>     If I know "doh.example.com" is authoritative for "foo.example.com", I may prefer to take *.foo.example.com queries directly to it instead of using an intermediary recursive. I consider this to be separate from policies such as "I perform filtering" because being authoritative or designated isn't a policy / requirement and I can still choose to use an intermediate recursive if I want.
> 
Who is "I"? Is it the client developer, or the user?
If it is the client developer, then choosing to ignore the recursor and go straight to the authoritative, circumventing whatever policy the recursor would apply, is indeed a policy choice, not very different from going to a recursor different than the system's; if this is not what the user wants, it will break user expectations; and in architectural terms, it creates one more source of unpredictable results by introducing another per-app (or per-OS) different behaviour.

--

Vittorio Bertola | Head of Policy & Innovation, Open-Xchange
[email-masked] mailto:[email-masked] 
Office @ Via Treviso 12, 10144 Torino, Italy

---

From: Joe Abley <[email-masked]>
Date: Fri, 11 Sep 2020 12:33:57 +0200

Hi Tommy,

On Sep 10, 2020, at 18:32, Tommy Jensen <Jensen.Thomas=[email-masked]> wrote:

> If I know "doh.example.com" is authoritative for "foo.example.com", I may prefer to take *.foo.example.com queries directly to it instead of using an intermediary recursive.

In the taxonomy described in RFC 8499, "clients" in the ADD charter refers to "stub resolver" -- "a resolver that cannot perform all resolution itself". The phrase "resolver information" in the charter refers to information about "recursive resolvers" -- resolvers that operate in "recursive mode".

What you are describing above is a hybrid entity that behaves like a stub resolver in some cases but like a recursive resolver in others. The opportunistic choice of transport between this new entity and a particular authoritative server is by definition not communication between stub resolver and recursive resolver (as defined in RFC 8499) or between client and resolver (as described in the ADD charter).

This might be an interesting discussion to start in DNSOP, perhaps as part of a larger discussion about capabilities negotiation between authoritative servers and their clients, but I think it's out of scope for ADD.

Joe

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 11 Sep 2020 04:14:42 -0700

> on-boarded into the network.

For wired network you plug into the wall.
For a wireless network, someone gives you an SSID and a (common) password.
For mobile, via the usual mechanisms.

-Ekr

-Tiru
>> DoH resolver that corresponds to the Do53 resolver offered by that network.
>>

---

From: tirumal reddy <[email-masked]>
Date: Fri, 11 Sep 2020 17:36:13 +0530

> For a wireless network, someone gives you an SSID and a (common) password.

You seem to be referring to home/coffee shop use cases and not relevant to
on-boarding devices in an enterprise network.

-Tiru

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 11 Sep 2020 05:23:15 -0700

> on-boarding devices in an enterprise network.

Sure. Well, if you like add "network certificate + SSO" I don't think it
materially changes the situation.

-Ekr

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 11 Sep 2020 14:51:10 +0000

On Sep 11, 2020, at 5:06 AM, tirumal reddy <[email-masked]> wrote:
> You seem to be referring to home/coffee shop use cases and not relevant to on-boarding devices in an enterprise network.

It is wrong to say that Ekr's model "is not relevant" to enterprise networks. Some enterprise networks use extra configuration for handing out resolver information, many enterprise networks (including the one I'm using at the moment) do not.

It's fine to say that Martin's use case is not the use case you personally are interested in; please don't dismiss it as "not relevant".

--Paul Hoffman

---

From: tirumal reddy <[email-masked]>
Date: Fri, 11 Sep 2020 20:48:33 +0530

On Fri, 11 Sep 2020 at 20:21, Paul Hoffman <[email-masked]> wrote:

> > You seem to be referring to home/coffee shop use cases and not relevant
> to on-boarding devices in an enterprise network.
>
> It is wrong to say that Ekr's model "is not relevant" to enterprise
> networks.

I only meant common password is "not relevent" to an Enterprise network.

> Some enterprise networks use extra configuration for handing out resolver
> information,

many enterprise networks (including the one I'm using at the moment) do not.

Yes, it depends on the enterprise network. In addtion, whether it is a
IT-owned devices, BYOD with MDM or configuration profile or a BYOD with
unique credentails. The use case should consider all the above type devices
including IoT devices.

>
> It's fine to say that Martin's use case is not the use case you personally
> are interested in; please don't dismiss it as "not relevant".
>

I am interested in the use case :)  I would like to understand whether the
use case is for a Home or Enterprise network.

Cheers,
-Tiru

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 11 Sep 2020 08:26:29 -0700

> unique credentails. The use case should consider all the above type devices

I disagree with this. In particular, I do not think it should include
anything that is managed (MDM, enterprise config, etc.) because those
entities can just directly configure the DNS provider. It might still be
useful in some way to have a signaling protocol, but it is a far lower
priority.

-Ekr

>> It's fine to say that Martin's use case is not the use case you
>> personally are interested in; please don't dismiss it as "not relevant".
>>
>

---

From: "Geist, Dan (CCI-Atlanta)" <[email-masked]>
Date: Fri, 11 Sep 2020 17:35:39 +0000

It’s worth stating that use cases and users are not the same. We’re describing attributes of how (or if?) an enterprise, or retailer, or service provider, or home user chooses to implement resolver configuration or discovery. The fact is that most are likely a hybrid of mechanisms careered to their needs (i.e. coffee shop shared Wifi with a password on the wall is not fundamentally different than a large enterprise that provides guest Wifi to professional visitors via similar shared key).

Many enterprises use configuration tools to set certain things and may simultaneously use automatic discovery mechanisms for other things for architectural or business reasons. The overall security posture or purpose of the provider/consumer should not be a key factor in defining how any given discovery mechanism works, only what the technology bits are and how they function.

Agreeing to make the use case discussions about “what” and not “who” or “why” makes those discussions simpler.

Thanks.
Dan

From: Add <[email-masked]> On Behalf Of tirumal reddy
Sent: Friday, September 11, 2020 11:19 AM
To: Paul Hoffman <[email-masked]>
Cc: ADD Mailing list <[email-masked]>
Subject: [EXTERNAL] Re: [Add] [Ext] My single use case

On Fri, 11 Sep 2020 at 20:21, Paul Hoffman <[email-masked]<mailto:[email-masked]>> wrote:
On Sep 11, 2020, at 5:06 AM, tirumal reddy <[email-masked]<mailto:[email-masked]>> wrote:
>
> On Fri, 11 Sep 2020 at 16:45, Eric Rescorla <[email-masked]<mailto:[email-masked]>> wrote:
>

It is wrong to say that Ekr's model "is not relevant" to enterprise networks.

Some enterprise networks use extra configuration for handing out resolver information,
many enterprise networks (including the one I'm using at the moment) do not.

Yes, it depends on the enterprise network. In addtion, whether it is a IT-owned devices, BYOD with MDM or configuration profile or a BYOD with unique credentails. The use case should consider all the above type devices including IoT devices.

I am interested in the use case :)  I would like to understand whether the use case is for a Home or Enterprise network.

Cheers,
-Tiru

--Paul Hoffman

---

From: Tommy Jensen <[email-masked]>
Date: Fri, 11 Sep 2020 19:20:29 +0000

Hey Joe,

I don't think "a resolver that cannot perform all resolution itself" is equivalent to "it has no per-name behavior at all". Stub resolvers such as the one in my product will have a set of resolvers for the general case as well as rules per domain indicating different servers should be used. Examples include names that can only be routed internally ("*.<my-employer>.com") and querying different servers to enable lower cost content loading ("*.<foo-streaming-service>.com", "*.<my-carrier-billing>.com"). I don't think this not-fully-recursive behavior disqualifies client from being stubs.

So to reiterate, I think discovering a DNS server is designated for a set of names is DNS resolver information, and we're chartered to "Define a mechanism that allows communication of DNS resolver information to clients for use in selection decisions". I don't think the definition of "clients" need be as rigid as you claim. I do think the use case discussion is more urgent however so I'll shut up about this for now.

To Vittorio's comments: I think your concern is more related to the policy of implementations, which is not in scope. My point is simply an encrypted DNS server may have name ownership or designation as a property and since clients do use name-based routing logic today already, would find it useful to discover this information. Unlike policy-specific information (ex: "server filters content"), this infromation can be securely defined using existing mechanisms (PKI).

Thanks,
Tommy

________________________________
From: Joe Abley <[email-masked]>
Sent: Friday, September 11, 2020 3:33 AM
To: Tommy Jensen <[email-masked]>
Cc: Jim Reid <[email-masked]>; ADD Mailing list <[email-masked]>
Subject: [EXTERNAL] Re: [Add] Zone ownership in DNS server discovery

Hi Tommy,

Joe

---

From: Tommy Jensen <[email-masked]>
Date: Fri, 11 Sep 2020 20:34:29 +0000

> I think that the difference is important and we will have to work through both paths, if only because the prevalence of forwarders might mean we need two sets of solutions.

Agreed. The challenges a use case faces have nothing to do with its validity, even if it results in no adoption.

>  I don't think that this necessarily depends on the creation of new infrastructure for authentication of servers that don't have IP addresses in the public address space, but it might make that results less usable for you.

My concern is 2) encompasses more use cases than 1). 1) is limited to the use case of joining a network and needing a recommendation. 2) includes other channels of address acquisition such as offline endpoint configuration. I can accept feature parity for 1) which is no authentication. I can possibly accept lower security for 2) when the address came from network advertisement such as DHCP which isn't secure today, but not when it came from endpoint configuration which may be secured.

More simply: 1) includes both server identity and server source, but 2) only includes server property without accounting for server source.

I understand that may be an implementation decision, but I do want to call out a mechanism built to solve 2) generically may have limited usefulness for clients like me who need to use both interpretations of 2). For me, 2) splits into 2a) and 2b) and the line along which I see the bar for authentication changing is 1) and 2a) on one side and 2b) on the other.

I'll try and articulate this in response to Glenn's request for authentication homework.

Thanks,
Tommy

________________________________
From: Martin Thomson <[email-masked]>
Sent: Thursday, September 10, 2020 7:00 PM
To: Tommy Jensen <[email-masked]>; [email-masked] <[email-masked]>
Subject: Re: [EXTERNAL] [Add] My single use case

---

From: "Martin Thomson" <[email-masked]>
Date: Mon, 14 Sep 2020 09:00:02 +1000

On Sat, Sep 12, 2020, at 06:34, Tommy Jensen wrote:
> My concern is 2) encompasses more use cases than 1). 1) is limited to 
> the use case of joining a network and needing a recommendation. 2) 
> includes other channels of address acquisition such as offline endpoint 
> configuration. I can accept feature parity for 1) which is no 
> authentication. I can possibly accept lower security for 2) when the 
> address came from network advertisement such as DHCP which isn't secure 
> today, but not when it came from endpoint configuration which may be 
> secured. 

This is a good summary of this situation.  I share those reservations also, but would add that even in cases where the discovery is not cryptographically authenticated, that doesn't mean it isn't protected somehow, so the second case (talk to the resolver or something akin to that) increases exposure to attacks even when configuration isn't authenticated sometimes.  So you have:

2a) unsecured discovery/configuration
2b) discovery/configuration secured by means that is not apparent (e.g., at layers 1 or 2)
2c) discovery/configuration secured cryptographically (and thus known to the endpoint)

The former two are indistinguishable to the client; the latter two are cases you might want a different policy for.

In the end, this is a subjective decision that might be made in client policy, so our responsibility is to identity the scenario and document the consequences, not necessarily decide it.  The reason I think that this remains in scope is the forwarder case.  This is so common a deployment topology.  And, as those devices are a mix of hard to upgrade or unmaintained, finding some way to route around them seems to be important.

---

From: tirumal reddy <[email-masked]>
Date: Mon, 14 Sep 2020 12:17:31 +0530

Hi Eric,

Please see inline

On Fri, 11 Sep 2020 at 20:57, Eric Rescorla <[email-masked]> wrote:

>>> > You seem to be referring to home/coffee shop use cases and not
>>> relevant to on-boarding devices in an enterprise network.
>>>

If the discovery protocol works for unmanaged BYOD, it would also work for
other types of devices.
I understand device management tools can be used to provision managed
devices with network provided encrypted resolver but it is not yet fully
supported, for example (1) configuration profile (provisioned using OTA)
does not yet support configuring the encrypted DNS resolver and the
configuration profile is specific to Apple (3) I see policies (GPO) can be
set on Chrome/Firefox and OS like Windows to use a DoH server but not sure
about other OS/Browsers. (3) I don't think MDM (from several vendors)
supports encrypted DNS server configuration yet.

-Tiru

>> I am interested in the use case :)  I would like to understand whether
>> the use case is for a Home or Enterprise network.
>>
>> Cheers,
>> -Tiru
>>
>>
>>>
>>> --Paul Hoffman
>>>
>>> --
>> Add mailing list
>> [email-masked]

---

From: tirumal reddy <[email-masked]>
Date: Mon, 14 Sep 2020 15:03:24 +0530

On Mon, 14 Sep 2020 at 04:30, Martin Thomson <[email-masked]> wrote:

> This is a good summary of this situation.  I share those reservations
> also, but would add that even in cases where the discovery is not
> cryptographically authenticated, that doesn't mean it isn't protected
> somehow, so the second case (talk to the resolver or something akin to
> that) increases exposure to attacks even when configuration isn't
> authenticated sometimes.  So you have:
>
> The former two are indistinguishable to the client; the latter two are
> cases you might want a different policy for.
>
> In the end, this is a subjective decision that might be made in client
> policy, so our responsibility is to identity the scenario and document the
> consequences, not necessarily decide it.  The reason I think that this
> remains in scope is the forwarder case.  This is so common a deployment
> topology.  And, as those devices are a mix of hard to upgrade or
> unmaintained, finding some way to route around them seems to be important.
>

Growing number of home routers today support easy update of config and
software, for example routers run RDK software (https://rdkcentral.com/) to
ease config/software update, support LxC container environment to run
network security services.  They can update configs & software on devices
with fine-grained control (controlled release, A/B test, roll fwd/back,
etc.) and with whatever frequency of update is necessary. In short, both
types of router exist in the field.

-Tiru

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 14 Sep 2020 05:47:58 -0700

> supports encrypted DNS server configuration yet.

So? Any of this would require something to change on the endpoints. The
question is what the appropriate change would be in this setting (if any),
and what I'm saying is that the appropriate change is to use the existing
device management.

-Ekr

---

From: Daniel Migault <[email-masked]>
Date: Mon, 14 Sep 2020 11:54:42 -0400

On Thu, Sep 10, 2020 at 4:48 PM Ben Schwartz <bemasc=
[email-masked]> wrote:

> In the other scenario, correspondence is validated using a PKI with its
> own validation rules.
>
> <mglt>
You could also validate (cryptographically) the correspondence between the
encrypted DNS and the Do53, but in essence the confidence of the
authentication will remain with a similar level of the Do53. The discovery
could also provide some proofs that the resolver is associated to your ISP
or the entity providing you the connectivity with a reasonable level of
confidence.
</mglt>

> * When should the client validate the certificate chain, and to which
> trust anchor?
> 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

<mglt>
I think that is important we do not exclusively work in a single use case
when it comes to designing a solution and that we do have a global picture
of the use cases and requirements. More specifically, I do not think that
discovery is limited to the discovery of the network provided resolvers.
</mglt>

-- 
Daniel Migault
Ericsson

---

From: Daniel Migault <[email-masked]>
Date: Mon, 14 Sep 2020 12:11:55 -0400

Hi Martin,

Discovering and selecting are from my point of view, separate processes,
and learning that one resolver performs qname should be learnt during the
discovery, while the decision should be part of the selection process.

Yours,
Daniel

> that does anything fancy because that makes the decision complex.
<mglt>
The discovery as far as I understand it is expected to be followed by a
selection process which could result in using multiple resolvers. So, it
may be possible information related to a resolver is being discovered
during the discovery. That these parameters should not influence the
discovery process is one thing, that these parameters should not be
discovered is another thing. The text seems to say the second. If you
happen to know that the resolver does qname or not will be considered by
the selection process not the discovery but one may learn it during the
discovery - at least in my opinion.
</mglt>

-- 
Daniel Migault
Ericsson

---

From: Vittorio Bertola <[email-masked]>
Date: Mon, 14 Sep 2020 18:55:57 +0200 (CEST)

>     Il 14/09/2020 17:54 Daniel Migault <[email-masked]> ha scritto:
> 
>     <mglt>
>     You could also validate (cryptographically) the correspondence between the encrypted DNS and the Do53, but in essence the confidence of the authentication will remain with a similar level of the Do53. The discovery could also provide some proofs that the resolver is associated to your ISP or the entity providing you the connectivity with a reasonable level of confidence.   
>     </mglt> 
> 
For the use case of "same-provider auto-upgrade" as currently implemented, being sure that a given DoH resolver really corresponds to the currently active Do53 system resolver would suffice, even if you were not able to authenticate who is actually operating those two resolvers. (This is different from "same-provider auto-upgrade only for selected trusted providers", which requires a hardcoded list of trusted providers in the client, but as far as I understand the objective is to get rid of hardcoded lists altogether.)

For this purpose, we could simply use a TLSA record. The Do53 resolver would provide a TLSA record together with the RESINFO/TXT/whatever response to the discovery query, and when establishing the DoH connection, the client would validate the certificate against the TLSA record. If you add DNSSEC to the Do53 communication, this should be a secure process. Could this work?

(Glenn - perhaps this is a specific topic for discussion tomorrow: authenticating the relationship between a Do53 and a DoH resolver without necessarily identifying their operator, i.e. breaking your #3 topic into two separate parts)

--

---

From: Andrew Campling <[email-masked]>
Date: Mon, 14 Sep 2020 17:06:08 +0000

On 14/09/2020 17:56 Vittorio Bertola <[email-masked]> wrote:

> For the use case of "same-provider auto-upgrade" as currently implemented, being sure that a given
> DoH resolver really corresponds to the currently active Do53 system resolver would suffice, even if
> you were not able to authenticate who is actually operating those two resolvers. (This is different
> from "same-provider auto-upgrade only for selected trusted providers", which requires a hardcoded
> list of trusted providers in the client, but as far as I understand the objective is to get rid of
> hardcoded lists altogether.)
>
> For this purpose, we could simply use a TLSA record. The Do53 resolver would provide a TLSA record
> together with the RESINFO/TXT/whatever response to the discovery query, and when establishing
> the DoH connection, the client would validate the certificate against the TLSA record. If you add
> DNSSEC to the Do53 communication, this should be a secure process. Could this work?

This seems like a reasonable proposal, especially with the addition of DNSSEC.

Andrew

---

From: Steffen Nurpmeso <[email-masked]>
Date: Mon, 14 Sep 2020 23:20:38 +0200

Daniel Migault wrote in
 <CADZyTknjg+47Rk1+a4B2DZT_0NSX=0vaAu7NBuxprr=[email-masked]>:
 |Hi Martin,
 |
 |Discovering and selecting are from my point of view, separate processes,
 |and learning that one resolver performs qname should be learnt during the
 |discovery, while the decision should be part of the selection process.

Definitely my last post here.
But in the meantime i have looked around because i have these
tremendous woes regarding the use of JSON in things a (caching)
stub resolver has to work with, and whereas i have found jsmn
(jasmine), which is just a few kilobytes and can easily be
included both because it is header-only, even stdlib-free and
zero-copy, and freely licensed, primitive though and difficulties
are up to you, but well, there is something with a user base so
that error detection is distributed and there is no need to do it
yourself (hmm) or to use these very, very big libraries like even
json-c is.

What i meant is, i would expect that the RESINFO structure is
filled with several types of data, like single addresses, or
address+mask tuples, and of course hostnames (with and without
wildcards, as in RFC 2818 and RFC 6125), it could very well
include pointers to other encrypted resolvers which should be
contacted for targets which do not match what this RESINFO
defines.  It even has to, since the special .ARPA lookup was
responded with this RESINFO.

This more or less implies that, once you got a RESINFO with only
the reference to the encrypted resolver via DHCP or so, you have
to contact the encrypted resolver and ask for a real RESINFO,
then.

--steffen
|
|Der Kragenbaer,                The moon bear,
|der holt sich munter           he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

---

From: Daniel Migault <[email-masked]>
Date: Mon, 14 Sep 2020 17:41:35 -0400

Hi,

I believe that DNSSEC is a good way to get authenticated information.
Especially as DNS is the common protocol between DoX. With DNSSEC, TLSA
would bind a key to a FQDN and the FQDN needs to be bound to *your* or
*the* or *an* ISP.
If UI are involved this seems sufficient as long as the EU is able to see
it is connected to connectivity_provider.net <http://my.isp.net>. What I
had in mind was to improve the level of confidence without UI but by
binding the resolver to the IP address used by the user. Of course the
connectivity provider is not necessarily the legitimate one, but still that
would be the associated resolver. One mechanism I would consider is binding
the IP address with DNSSEC to you resolver.sip.net. One way of doing so is
to start with a reverse resolution of the public IP address which provides
the FQDNs of the resolvers.

Note that in some cases the CPE also advertises the Public IP address of
the ISP resolver. I do not know how frequent this is.

Yours,
Daniel

On Mon, Sep 14, 2020 at 12:55 PM Vittorio Bertola <
[email-masked]> wrote:

> For the use case of "same-provider auto-upgrade" as currently implemented,
> being sure that a given DoH resolver really corresponds to the currently
> active Do53 system resolver would suffice, even if you were not able to
> authenticate who is actually operating those two resolvers. (This is
> different from "same-provider auto-upgrade only for selected trusted
> providers", which requires a hardcoded list of trusted providers in the
> client, but as far as I understand the objective is to get rid of hardcoded
> lists altogether.)
>
> For this purpose, we could simply use a TLSA record. The Do53 resolver
> would provide a TLSA record together with the RESINFO/TXT/whatever response
> to the discovery query, and when establishing the DoH connection, the
> client would validate the certificate against the TLSA record. If you add
(Glenn - perhaps this is a specific topic for discussion tomorrow:
> authenticating the relationship between a Do53 and a DoH resolver without
> necessarily identifying their operator, i.e. breaking your #3 topic into
> two separate parts)
>
> --
>
> [email-masked]

-- 
Daniel Migault
Ericsson

---

From: tirumal reddy <[email-masked]>
Date: Tue, 15 Sep 2020 12:00:26 +0530

On Mon, 14 Sep 2020 at 18:18, Eric Rescorla <[email-masked]> wrote:

>> If the discovery protocol works for unmanaged BYOD, it would also work
>> for other types of devices.
> So? Any of this would require something to change on the endpoints.
>

Yes.

> The question is what the appropriate change would be in this setting (if
> any), and what I'm saying is that the appropriate change is to use the
> existing device management.
>

It depends whether the discovery standard gets deployed first or device
management tools upgrade before the standard is developed. I am hoping in
the near future if the standard secure discovery protocol gets adopted by
endpoints, no need to wait for an upgrade to device management tools.

-Tiru

---

From: Tommy Jensen <[email-masked]>
Date: Tue, 15 Sep 2020 15:30:43 +0000

I'm glad I waited until after the second interim to respond, because I think that discussion gave more context to this.

I agree with you. The forwarder case is valid and should be addressed (the DHCP "yes, but").

My only remaining point to call out then (which I think we agree on but I'm writing out for the record) is we should be careful to identify cases where authentication isn't possible or is weaker than PKI and then let clients decide if they care. Client trust != protocol authentication.

Thanks,
Tommy

Sent: Sunday, September 13, 2020 4:00 PM

--
Add mailing list
[email-masked]
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fadd&amp;data=02%7C01%7CJensen.Thomas%40microsoft.com%7Cbbf88f42338147731cf108d85838d290%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637356348784982922&amp;sdata=1flFu0OfnW%2BUaFeuzO2k6Ak6Jk8oBJanj3KppEE8JXI%3D&amp;reserved=0