Subject: Re: [Add] Communication of DNS resolver information for use in selection decisions

From: "Deen, Glenn" <[email-masked]>
Date: Thu, 28 Jan 2021 00:08:52 +0000

On 1/27/21, 10:14 AM, "Add on behalf of Chris Box" <[email-masked]<mailto:[email-masked]> on behalf of [email-masked]<mailto:[email-masked]>> wrote:

>   In the meeting it sounded like Ekr had a different interpretation to me of the second charter deliverable.

- Define a mechanism that allows clients to discover DNS resolvers
that support encryption and that are available to the client
either on the public Internet or on private or local networks.
>  I agree the above is the first step we should work on, and we have been doing so.

- 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.
> The difference of opinion here might be the meaning of "resolver information". I personally think this goes beyond learning how to contact the resolver. I think it encompasses areas like "Resolver behavior self-description" that Tommy Jensen presented. Do the chairs agree?

As many will recall, when the ADD Charter was being approved there was a deliberate choice to limit the scope of ADD.  This excluded ADD from taking on the task of defining the what the actual information that would be provided to clients.   Hence, ADD was chartered to worry about how but not the what.   That means that ADD works on how to convey the information – both in terms of how to transport but also what container to use.

How this plays out in ADD is that we’ve really had 3 sorts of proposals that have been put forward on how to convey and subsequently then what the container is, noting that we haven’t been specific about what is in the container in detail. :

  #1 – conveyance is by DNS and the  container is the DNS and whatever information that can be put into a DNS record.
          This is what DEER/SVCB up uses.  Basically, DNS transport + DNS data in one phase, followed by HTTP in the next phase so the containers are DNS records, and a Certificate.

  #2 – conveyance is by network configuration protocol and the container is then configuration protocol fields. This is what DHCP/RA in BTW-Home uses.

  #3 – conveyance is HTTP.   The container is them something that you can carry over HTTP. Could be JSON, certificates or could be some other information encoding structure that HTTP transports.

Some of the workflows such as DEER use a combination of the above approaches, and so far we’ve been able to get this far without needing to provide details on what is being conveyed to the client.

The very deliberate scope limitation crafted into the ADD Charter and approved by both the community advocates for ADD and the IESG was to EXCLUDE ADD from defining the information that is conveyed to the client and how the client would use that information.    This means that the conveyance methods give a container to the services that want advertise DNS services and then transport that container to the client.   What specific information the advertising services share is undefined here, as is what the clients do with it.

If there is a need for “resolver behavior self-description information” to be conveyed it’s fine to say that there is a need for a container that holds that sort of information generically, and even specify the container choice.   Where we are not chartered to go into is defining the actually information detail.     So a box labeled “resolver behavior information” is fine, but detail beyond that is where we cross beyond the ADD Charter.

Consider it like a generic HTTP transport.  HTTP doesn’t really need to know what information is being transported, only that it’s transporting information in the HTTP stream container.   That information could be pictures of cats,  movies of cats, discussion of cats, or even actual cats once some develops cat teleportation encoding/decoding.

Regards
Glenn

---

From: Chris Box <[email-masked]>
Date: Thu, 28 Jan 2021 12:37:33 +0000

On Thu, 28 Jan 2021 at 00:09, Deen, Glenn <[email-masked]> wrote:

> As many will recall, when the ADD Charter was being approved there was a
> deliberate choice to limit the scope of ADD.  This excluded ADD from taking
> on the task of defining the what the actual information that would be
> provided to clients.   Hence, ADD was chartered to worry about how but not
> the what.   That means that ADD works on how to convey the information –
> both in terms of how to transport but also what container to use.
>

> The very deliberate scope limitation crafted into the ADD Charter and
> approved by both the community advocates for ADD and the IESG was to
> EXCLUDE ADD from defining the information that is conveyed to the client
> ...   This means that the conveyance methods give a container to the
> services that want advertise DNS services and then transport that container
> to the client.   What specific information the advertising services share
> is undefined here
>

Glenn, thanks for clarifying the distinction. I hadn't grasped that it was
out of scope to define any of the pieces of data that are carried.
Searching for this in the charter, the only way I can obtain that
interpretation is from the word "mechanism".

*It is chartered solely to develop technical *
*mechanisms. *

*Define a mechanism that allows communication of DNS resolver*
* information to clients *

I guess you are saying that "mechanism" means "conveyance of a container"??

If so, then any discussion of *which* information clients would like to
consume cannot occur under the auspice of this working group, and we should
terminate the thread. But I worry this will postpone the definition of any
information to be carried by a year or two, meaning we have to accept a
world where clients make decisions either blindly, or through the use of
multiple proprietary information sources.

Chris

---

From: Vittorio Bertola <[email-masked]>
Date: Thu, 28 Jan 2021 15:16:04 +0100 (CET)

>     Il 28/01/2021 13:37 Chris Box <[email-masked]> ha scritto:
> 
> 
>     Glenn, thanks for clarifying the distinction. I hadn't grasped that it was out of scope to define any of the pieces of data that are carried. Searching for this in the charter, the only way I can obtain that interpretation is from the word "mechanism".
> 
>          It is chartered solely to develop technical mechanisms.
> 
>          Define a mechanism that allows communication of DNS resolver
>          information to clients
> 
>     If so, then any discussion of which information clients would like to consume cannot occur under the auspice of this working group, and we should terminate the thread. But I worry this will postpone the definition of any information to be carried by a year or two, meaning we have to accept a world where clients make decisions either blindly, or through the use of multiple proprietary information sources.
> 
I agree with Chris that having a clear idea of which information clients would like to consume would be important, both for designing the transport mechanism and for standardizing the ways to express that information. If that latter part is considered out of scope for this WG, then we should work out where it should be performed, because having a mechanism to convey information from servers to clients that are run by a broad number of independent parties is entirely useless if there is no agreement on what the information means and how it should be expressed and encoded.

First of all, however, we should understand if client developers are interested in actually defining a (current, temporary) list of potentially interesting information that they would like to learn from the resolver and/or the network (I assume that, for the sake of simplicity, while transport mechanisms may be different, the information in the two cases may often be the same).

For example, we already have the "canary domain" mechanism to convey the indication that the network would not like "remote" DoH to be turned on; this is one piece of information that needs more standard ways to be expressed and transmitted. I also think that some identification of the operator, and perhaps a (link to a) privacy policy, may be necessary for GDPR compliance and consent management purposes.

Indeed, the question is more for the clients' UX designers and policy people than for the software developers - also, some parties are still working out their future plans and policies. Still, I think that some collective work on this, here or elsewhere, would be useful.

--

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

---

From: Eric Orth <[email-masked]>
Date: Thu, 28 Jan 2021 11:28:15 -0500

To me, this is a surprising interpretation of the ADD charter.  Very
unambiguously clear to me that defining how a client behaves in response to
communicated information is out of scope.  But seems much more of a stretch
to me to say that what specific information is possible to be communicated
(neutrally of how that data is to be used or what behavior it affects or
similarly under what circumstances a server must send that information) is
also out of scope.

ADD is chartered to define a "mechanism" for communicating resolver
information, and defining the included fields is a normal part of defining
communication mechanisms.  If we call that out of scope, then we've
artificially limited our potential mechanisms to unstructured blobs or
undefined key/value stuff.  And that's just not going to be very useful to
clients or servers without some basic understanding of what information is
included.

On Wed, Jan 27, 2021 at 7:09 PM Deen, Glenn <Glenn_Deen=
[email-masked]> wrote:

>
>
>
>
>
>
>
>
> On 1/27/21, 10:14 AM, "Add on behalf of Chris Box" <[email-masked]
> on behalf of [email-masked]> wrote:
>
>
>
> > The difference of opinion here might be the meaning of "resolver
> information". I personally think this goes beyond learning how to contact
> the resolver. I think it encompasses areas like "Resolver behavior
> self-description" that Tommy Jensen presented. Do the chairs agree?
>
>
>
> How this plays out in ADD is that we’ve really had 3 sorts of proposals
> that have been put forward on how to convey and subsequently then what the
> container is, noting that we haven’t been specific about what is in the
> container in detail. :
>
>
>
>   #1 – conveyance is by DNS and the  container is the DNS and whatever
> information that can be put into a DNS record.
>
>           This is what DEER/SVCB up uses.  Basically, DNS transport + DNS
> data in one phase, followed by HTTP in the next phase so the containers are
> DNS records, and a Certificate.
>
>
>
>   #2 – conveyance is by network configuration protocol and the container
> is then configuration protocol fields. This is what DHCP/RA in BTW-Home
> uses.
>
>
>
>   #3 – conveyance is HTTP.   The container is them something that you can
> carry over HTTP. Could be JSON, certificates or could be some other
> information encoding structure that HTTP transports.
>
>
>
> Some of the workflows such as DEER use a combination of the above
> approaches, and so far we’ve been able to get this far without needing to
> provide details on what is being conveyed to the client.
>
>
>
> and how the client would use that information.    This means that the
> conveyance methods give a container to the services that want advertise DNS
> services and then transport that container to the client.   What specific
> information the advertising services share is undefined here, as is what
> the clients do with it.
>
>
>
> If there is a need for “resolver behavior self-description information” to
> be conveyed it’s fine to say that there is a need for a container that
> holds that sort of information generically, and even specify the container
> choice.   Where we are not chartered to go into is defining the actually
> information detail.     So a box labeled “resolver behavior information” is
> fine, but detail beyond that is where we cross beyond the ADD Charter.
>
>
>
> Consider it like a generic HTTP transport.  HTTP doesn’t really need to
> know what information is being transported, only that it’s transporting
> information in the HTTP stream container.   That information could be
> pictures of cats,  movies of cats, discussion of cats, or even actual cats
> once some develops cat teleportation encoding/decoding.
>
>
>
> Regards
>
> Glenn
>
>
> --
> Add mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/add
>

---

From: Chris Box <[email-masked]>
Date: Thu, 28 Jan 2021 17:10:29 +0000

> clients or servers without some basic understanding of what information is

+1 to this.

Although Glenn said:

> The charter’s line was drawn against the group getting into working on the
> details of the information and how the client needed to use it.  So group
> can and has discussed at a high level what information needs to be
> conveyed, but not into the information detail or semantics of client use of
> the information.
>

Which seems to permit unstructured blobs that carry some specifically
defined high-level information.

Yet Glenn added:

> For example, btw-add-home details the bits, fields and values in DHCP to
> use to describe and communicate resolver descriptive information.  Which is
> fine and in scope.
>

Which would appear to be a detailed definition of how specific information
is transmitted.
So I admit to still being confused.

Chris

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Thu, 28 Jan 2021 17:21:25 +0000

<bhs> Actually, I think if the mechanisms define an IANA registry along with protocol position and format for extensions, with something like “specification required”, then it would be possible for the work of defining these to be completely external to IETF. This definition could then happen in a group where the target application/system developer and deployer audience is present. It’s pretty clear that the target app/system developers for some of the desired info elements are not present in ADD or necessarily in IETF. There exist a number of orgs that could easily and readily take on such work, even before the mechanisms become an RFC. Then they would be ready to put into the IANA registry as soon as the registry comes into existence.
Barbara

---

From: Chris Box <[email-masked]>
Date: Thu, 28 Jan 2021 20:14:57 +0000

Having discussed this offline, I think I have a better understanding of the
dividing line now. I'll try and phrase it in my own words.

It is in charter for ADD to develop an extensible mechanism to convey
generic "information that might be useful in selection". In order for it to
do so, it's a good idea to have some conversations about the types of
information that might be needed, so that we can have a suitable format
that does the job well.

It is not in charter to define exactly what the information elements
carried inside that mechanism are, e.g. their names, values and
interpretations. Of course we recognise that this is needed, otherwise the
whole mechanism is pointless. But the task of defining those elements lies
outside this group. It could be in other working groups, or independent, or
outside the IETF. Whatever. Just not here.

So Barbara's comment turned out to be spot on.

Chris

---

From: Eric Orth <[email-masked]>
Date: Fri, 29 Jan 2021 16:29:11 -0500

I too had a nice offline discussion on this, and I'm at least now
comfortable that the chairs and IESG are interpreting our scope reasonably
when it comes to communication of resolver information.  It's just a bit
difficult to communicate the nuances of what is and isn't in scope.  I
think I've got it, but somebody correct me if I'm still wrong...

Taking DoH servers authenticating client identity as a concrete example
(since that was one of the specific topics that led into this scope
conversation): Defining an actual authentication mechanism is out of scope
for ADD (and probably not necessary anywhere since general authentication
mechanisms for HTTP and TLS and such already exist).  When it comes to
defining mechanisms to communicate resolver information for use in
discovery or selection, it would be completely ADD-in-scope for those
communication mechanisms to include things like a field to declare that a
resolver uses an authentication mechanism because that is likely to be a
valuable factor in a client's selection decisions.  Getting more
borderline, but it may even be in-scope for the communication mechanism to
provide keys or similar for authentication mechanisms, provided that a
reasonable structure/format for those keys has been defined elsewhere
(probably in the WG that defined the authentication mechanism), but it's
getting out-of-scope for ADD to define the format/structure for those keys
since that's getting into defining the authentication mechanism, not the
communication mechanism.  And any communication mechanisms should be
reasonably extensible enough that outside-ADD groups could add the
information they need to communicate as they define mechanisms to
communicate about.

So when people are saying that communicated-information interpretation is
out of scope and we can only create envelopes to contain blobs, it doesn't
mean we can't assign data fields to pieces of information relevant to
discovery/selection and can only define a single payload blob.  It just
means we can't define the data structures at the level that's getting into
defining the mechanisms we're communicating about.

And it would, of course, be unambiguously out-of-scope for ADD to define
how clients/servers should react or behave on receiving any communicated
information.  How a client uses the communicated information to select a
resolver (or its behavior in connecting to the selected resolver) is out of
scope for ADD to define.

On Thu, Jan 28, 2021 at 3:15 PM Chris Box <[email-masked]> wrote:

> Having discussed this offline, I think I have a better understanding of
> the dividing line now. I'll try and phrase it in my own words.
>