Subject: [Add] Requirements drafts

From: "Chris Box (BT)" <[email-masked]>
Date: Fri, 31 Jul 2020 18:35:25 +0100

All,

My take on the conclusion of this week's meeting (notes at
https://codimd.ietf.org/notes-ietf-108-add?view) was that the next step
should be to step back and write some new drafts that clearly define the
problem statement and requirements to be met.

Assuming there is more than one of these drafts, how would you define the
subject area for each one?

Martin and Eric (Orth) both suggested Same Provider Auto Upgrade, aka
"discovering potential upgrade information for the current resolver".

Eric also suggested "networks communicating what their preferred resolver
is". If the current resolver is the one automatically learned from the
network, this is identical to the above. If it is not, because there's
manual configuration, presumably we always/nearly-always honor the manual
config? But are there cases where it's still helpful to know the network's
preference?

Within SPAU, I think a useful distinction is Ekr's "steering which generic
resolver will be used". This allows for the current provider to have
multiple possible resolvers (e.g. edge vs core), and communicating the
nature of the differences between those options.

Finally we have Domain Designated Resolvers, where domains tell you what
their preferred resolver is.

Any thoughts on the scope of each draft, and how many should be created in
time for the September interim?

Chris

P.S. In terms of content, one idea I've had is that each should also
mention performance considerations, particularly as I'm now thinking that
the larger the set of resolvers a client talks to, the fewer requests it
sends to each, and the more likely it is that a query will require a new
TLS setup. Jim also mentioned another, that they'll need to report on
GDPR-type issues

---

From: Tommy Pauly <[email-masked]>
Date: Fri, 31 Jul 2020 17:05:52 -0700

Hi Chris,

Thanks for starting this thread. I think focusing the interim meeting on clarifying these use cases is a good idea.

As I mentioned in my presentation, I think there are two clear categories we see repeated across the proposals for discovery. In the most abstract terms, these are:

1. Given a known resolver, discover one or more associated/equivalent encrypted resolvers
2. Discover an encrypted resolver that is applicable to a limited domain

Each of these has several specific use cases for *both* local network resolvers and Internet-accessible resolvers.

Under (1), we have:
1a: Discover encrypted resolvers that are equivalent to the resolver given out by DHCP/RA
1b: Discover encrypted resolvers that are equivalent to a manually-configured resolver, which may be a public Internet resolver
1c: Discover encrypted resolvers that are equivalent to a VPN-configured DNS servers
...

Under (2), we have:
2a: Discover a mapping between a locally-hosted domain and an encrypted resolver
- Walled-garden content
- Locally-cached content
- Private enterprise names
2b: Discover a mapping between a public domain and an encrypted resolver
- Name hosted by CDN foo can use CDN foo’s resolver
…

I don’t think we need to cover the manual configuration case, other than to indicate that user preference should always take precedence. I don’t think there is a viable use for having a network claim a preference that should override manual user configuration.

I think these two use cases could share one document, or be separate. They probably shouldn’t be broken down any further than that.

Beyond use cases, I think any requirements document needs to primarily address the privacy, security, and authentication requirements of the architecture. I suggest using some of the conversation from Martin Thomson’s email thread titled “My principles for discovery”. We should have baseline standards for how trusted a given signal must be before a client should use it.

Thanks,
Tommy

> On Jul 31, 2020, at 10:35 AM, Chris Box (BT) <[email-masked]> wrote:
> 
> All,
> 
> My take on the conclusion of this week's meeting (notes at https://codimd.ietf.org/notes-ietf-108-add?view <https://codimd.ietf.org/notes-ietf-108-add?view>) was that the next step should be to step back and write some new drafts that clearly define the problem statement and requirements to be met.
> 
> Assuming there is more than one of these drafts, how would you define the subject area for each one?
> 
> Martin and Eric (Orth) both suggested Same Provider Auto Upgrade, aka "discovering potential upgrade information for the current resolver".
> 
> Eric also suggested "networks communicating what their preferred resolver is". If the current resolver is the one automatically learned from the network, this is identical to the above. If it is not, because there's manual configuration, presumably we always/nearly-always honor the manual config? But are there cases where it's still helpful to know the network's preference?
> 
> Within SPAU, I think a useful distinction is Ekr's "steering which generic resolver will be used". This allows for the current provider to have multiple possible resolvers (e.g. edge vs core), and communicating the nature of the differences between those options.
> 
> Finally we have Domain Designated Resolvers, where domains tell you what their preferred resolver is.
> 
> Any thoughts on the scope of each draft, and how many should be created in time for the September interim?
> 
> Chris
> 
> P.S. In terms of content, one idea I've had is that each should also mention performance considerations, particularly as I'm now thinking that the larger the set of resolvers a client talks to, the fewer requests it sends to each, and the more likely it is that a query will require a new TLS setup. Jim also mentioned another, that they'll need to report on GDPR-type issues
> 
> -- 
> Add mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/add