Subject: [Add] Definition of equivalence

From: Chris Box <[email-masked]>
Date: Mon, 7 Dec 2020 18:45:02 +0000

Hi everyone

During 109's discussion of the concept of equivalence, many valid points
were raised. I've attempted to take these and incorporate them into a new
definition, and came up with the wording below.

*Given an initial resolver A, equivalence is the claim that one or more
other resolvers B, C, etc are:(1) Operated by the same entity as A,(2) Have
authentication and security properties that are no worse than A,(3) Have
access to the same pool of names as A, and(4) Possess the same data privacy
and filtering characteristics as A.*

This is not a final definition by any means, but it is at least closer to
the spirit I heard.

Would this definition work for you, or with some tweaks?

Chris

P.S. Thanks to Andrew Campling for his help in summarising the output of
109.

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 7 Dec 2020 19:44:38 +0000

On Dec 7, 2020, at 10:45 AM, Chris Box <[email-masked]> wrote:
> Given an initial resolver A, equivalence is the claim that one or more other resolvers B, C, etc are:
> (1) Operated by the same entity as A,
> (2) Have authentication and security properties that are no worse than A,
> (3) Have access to the same pool of names as A, and
> (4) Possess the same data privacy and filtering characteristics as A.
> 
> This is not a final definition by any means, but it is at least closer to the spirit I heard.
> 

One easy tweak would be to say before the list that all four requirements need to be met simultaneously.

The third requirement sounds odd. Would "Resolves all names the same was as A does" be better?

--Paul Hoffman

---

From: Eric Orth <[email-masked]>
Date: Mon, 7 Dec 2020 15:00:06 -0500

> The third requirement sounds odd. Would "Resolves all names the same was

I think the discussion points Chris was trying to capture there was that a
lot of people discussed that giving the exact same results was a
non-requirement.  E.g. that caching differences and such were fine.  So
"resolves all names the same" might be too strong in that respect.  I think
the important part was that an equivalent server would be able to answer
for any special/internal names that server A knows about (and that an
equivalent server wouldn't respond for any filtered names that A is also
filtering, but that is covered by (4)).

>
> --Paul Hoffman--
> Add mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/add
>

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 7 Dec 2020 20:36:14 +0000

On Dec 7, 2020, at 12:00 PM, Eric Orth <[email-masked]> wrote:
> I think the discussion points Chris was trying to capture there was that a lot of people discussed that giving the exact same results was a non-requirement.  E.g. that caching differences and such were fine.

Fully agree on "caching difference". Not sure what the list of "and such" contains.

>  So "resolves all names the same" might be too strong in that respect.  

Fair point.

> I think the important part was that an equivalent server would be able to answer for any special/internal names that server A knows about

Yes, that was the salient point I was trying to make in my proposed wording.

> (and that an equivalent server wouldn't respond for any filtered names that A is also filtering, but that is covered by (4)).

Agree.

New proposal: Resolves all names the same was as A does.

--Paul Hoffman

---

From: Martin J. Dürst <[email-masked]>
Date: Tue, 8 Dec 2020 07:38:23 +0900

Hello everybody,

Just one point below that caught my eye.

> authentication and security properties that are no worse than A,

"equivalence" in most people's mind (and in Mathematics) is a symmetric 
relation. I.e. If A is equivalent to B, then people may easily think B 
is also equivalent to A. However, the "no worse than" in (2) is contrary 
to this symmetry. The right thing to do may not be to change (2) 
(because that's what's important for your application), but to use 
another word that equivalence. At the least give a very clear health 
warning, e.g. as follows: "Please note that this definition of 
equivalence is not symmetric, i.e. if resolver A is equivalent to 
resolver B, this does not imply that resolver B is equivalent to 
resolver A."

Regards,   Martin.

>(3) Have

---

From: Andrew Campling <[email-masked]>
Date: Mon, 7 Dec 2020 22:58:53 +0000

> The third requirement sounds odd. Would "Resolves all names the same was as A does" be better?

That looks another way of saying they should give the same answers (apologies if I've misunderstood).  Ted Hardie addressed this during the IETF 109 WG discussion as follows:
 
"If someone tries to test whether this is still equivalent. Unless they're serving out of same cache, they can get different answers just because of the rest of the system changing over time, in a way that is not a function of the resolver."

Andrew 

-----Original Message-----
From: Paul Hoffman <[email-masked]> 
Sent: 07 December 2020 19:45
To: Chris Box <[email-masked]>
Cc: ADD Mailing list <[email-masked]>
Subject: Re: [Add] [Ext] Definition of equivalence

--Paul Hoffman

---

From: "Martin Thomson" <[email-masked]>
Date: Tue, 08 Dec 2020 10:12:15 +1100

The message I got from the discussion was that equivalence was not what we were looking for.  Why is it not enough to say that an pointer is enough?  The entity providing the pointer can apply its own policies in determining what to point to (which might include the below), the entity following the pointer can do the same (again, including the below), and we might strongly recommend certain properties so as to create an expectation that the properties hold, but that's not equivalence.

>From my perspective, I would like to see a recommendation that the pointer only be given if the alternative resolver provides cryptographic protection for queries and responses (equivalent to DoT/DoH), has access to the same set of names, and has equivalent or better privacy treatment for queries.  That's 2-4 from your list, not 1.

The same entity thing is not a good idea.  I understand that people might want to enact that policy, but there are enough networks pointing to external providers that removing the option would be unwise.  I also understand that some networks or jurisdictions or clients might insist on this rule, but I don't quite understand how they guarantee that if it was important.

On Tue, Dec 8, 2020, at 05:45, Chris Box wrote:
> Hi everyone
> 
> During 109's discussion of the concept of equivalence, many valid 
> points were raised. I've attempted to take these and incorporate them 
> into a new definition, and came up with the wording below.
> 
> *Given an initial resolver A, _equivalence_ is the claim that one or 
> more other resolvers B, C, etc are:
> (4) Possess the same data privacy and filtering characteristics as A.*
> 
> P.S. Thanks to Andrew Campling for his help in summarising the output of 109.
> -- 
> Add mailing list
> [email-masked]

---

From: Ted Hardie <[email-masked]>
Date: Mon, 7 Dec 2020 15:45:50 -0800

Howdy,

On Mon, Dec 7, 2020 at 2:59 PM Andrew Campling
<[email-masked]> wrote:

> That looks another way of saying they should give the same answers
> (apologies if I've misunderstood).  Ted Hardie addressed this during the
> IETF 109 WG discussion as follows:
>
> "If someone tries to test whether this is still equivalent. Unless they're
> serving out of same cache, they can get different answers just because of
> the rest of the system changing over time, in a way that is not a function
> of the resolver."
>
>
>
I found Paul's formulation a bit hard to parse.

I think the informal way of saying this is that when a query comes to A, a
pointer to B means that A thinks B will be able to answer the same queries
in the same way.  That is, it has the same pool of names (so, in the case
of split DNS, it knows the "insider" names), would apply the same filters,
has equivalent or better transports from a data integrity/confidentiality
perspective, and would behave the same way to the query stream (monetize
it, post it on twitter, mock it in a low tone via speaker on 34th Street).

I don't think I care that B is operated by the same entity.  If 8.8.8.8
signs an agreement with 42.42.42.42 so that SK Telecom provides the same
DNS service as 8.8.8.8, they could give me a forward pointer to 42.42.42.42
and I get to decide to follow that or not based on how much I believe
Google (since they make the assertion).

In the moment, I have no way of checking whether the forward pointer
service is operated by the same people.  Since some anycast services have
instances that *aren't run by the same organizations* now, this is already
an ambiguity of DNS resolution, and I don't think requiring it here is
useful.  Either you believe the people giving you the pointer or you
don't.  But that's likely based on local config, not in-the-moment
confirmation.

Ted

---

From: Paul Vixie <[email-masked]>
Date: Tue, 8 Dec 2020 04:43:26 +0000

On Tue, Dec 08, 2020 at 10:12:15AM +1100, Martin Thomson wrote:
> ...
> 
> The same entity thing is not a good idea.  I understand that people might
> want to enact that policy, but there are enough networks pointing to external
> providers that removing the option would be unwise.

i read it as the DHCP-assigned server and the prospective-other server being
operated by the same entity, not that the client's attached network and the
prospective-other server being operated by the same entity.

> I also understand that some networks or jurisdictions or clients might
> insist on this rule, but I don't quite understand how they guarantee that if
> it was important.

"guaranty" is a nonsequitur here. what we have to do is describe equivalence
for the purpose of defining polite behaviour. the description will not cause
politeness; if a user or device or app is going to do as it pleases, either
ignoring or never hearing the equivalence principle at issue here, then the
issue is the impoliteness not the non-guaranty.

RFC 8484 says that "this protocol is designed to prevent on-path interference
in DNS operations", by which we can see that the inability to guaranty the
use of a same-entity name server is intentional, that it's an explicit goal
of the DoH protocol. the lengths some networks or jurisdictions will go to in
order to meet the guaranty anyway are not yet plumbed.

but i surely do want it to be true that the definition of politeness is
available and objective, so that when i find a user or an app or a device
which isn't behaving politely i can remove it aggressively, without worry.

-- 
Paul Vixie

---

From: Paul Vixie <[email-masked]>
Date: Tue, 8 Dec 2020 04:46:01 +0000

On Mon, Dec 07, 2020 at 03:45:50PM -0800, Ted Hardie wrote:
> ...
> 
> I don't think I care that B is operated by the same entity.  ...

i think that i, variously, do care.

as a user, i want to know.

as a network operator, i want to say.

-- 
Paul Vixie

---

From: "Martin Thomson" <[email-masked]>
Date: Tue, 08 Dec 2020 16:09:06 +1100

Hi Paul,

Your point about politeness is noted.

> prospective-other server being operated by the same entity.

What value do you attribute to having any level of expectation to having the same operator for the referenced resolvers?  I understand that an entity that provides such a reference might wish to limit to whom they point, and they might value things other than the criteria the IETF lists as important.  That's something they can decide on their own here in deciding what resolver to reference.

What value does a client gain from being able to assume that the operations are the same?  Given that you can't provide any sort of surety for the client - the reason I mentioned guarantees - it seems that any utility the client gains would have to be esoteric.

Thanks,
Martin

---

From: Paul Vixie <[email-masked]>
Date: Mon, 7 Dec 2020 23:32:50 -0800

Martin Thomson wrote on 2020-12-07 21:09:
> What value do you attribute to having any level of expectation to having the same operator for the referenced resolvers? ...

the two pictures now in my head may not be exhaustive, but i'll describe
them. first, if the specification of the "pointer" code point now being
discussed here is "same entity" then clients i develop or operate might
be more open to following that pointer. whereas if the recursion
function is about to be delegated to another entity i may prefer to fail
and suggest that a VPN be used, or some similar local-policy.

second, this discussion point puts some stress on the concept of
equivalence as a constant, which may with further illumination be
released by making equivalence into a variable. if the "pointer" code
point was accompanied by a TLV string in which same-entity was a boolean
or in which entity was the DNS owner name of an RP, that could also
inform my own, or my implementation's, local-policy.

> What value does a client gain from being able to assume that the operations are the same?  Given that you can't provide any sort of surety for the client - the reason I mentioned guarantees - it se…

the trust was already assumed, because the pointer was coming from the
local network operator in some way. if we're willing to follow that
pointer, then we're willing to trust what's a specified constant about
it, or we're willing to trust a specified variable that describes it.

the security philosophy this fits into is al capone and his taxes. my
first hint as a network operator that i have a bad actor among my users,
apps, or devices could well be that netflow shows noncompliance with a
specified norm of DNS behaviour. so it's valuable, not as a guaranty,
but as a warning.

vixie

-- 
Sent from Postbox
<https://www.postbox-inc.com/?utm_source=email&utm_medium=siglink&utm_campaign=reach>

---

From: Andrew Campling <[email-masked]>
Date: Tue, 8 Dec 2020 14:19:54 +0000

> The same entity thing is not a good idea.  I understand that people might want to enact that policy, but there are enough networks pointing to external providers that removing the option would be u…

I think that there are two similar but separate categories here, one for "equivalent" resolvers with a definition based on that provided in the earlier post from Chris Box, and potentially a second one for "designated" resolvers.  The main distinction of the second category is that it drops the requirement for it being from the same entity, could instead detail to a range of resolvers operated by multiple entities.  Whether there is a need for both categories in a user requirements document needs further thought.   

Note though that the inclusion of different entities could, in my view, be significant from the perspective of GDPR etc as a client could be directing personal data to a new data processor.  Those in countries or states without meaningful data privacy legislation may, of course, choose not to worry about such considerations. 

Andrew

---

From: Eric Orth <[email-masked]>
Date: Tue, 8 Dec 2020 12:33:55 -0500

I would be supportive of splitting off the same-entity part as a separately
defined (but still important) concept.  So essentially requirement (1) from
above becomes one concept (call it "same-party") and (2,3,4) alone becomes
another (call it "similar-behavior").

I think making it two defined concepts works well because it would be
reasonable for some parties to have policies regarding one but not the
other.

And, as was discussed a couple times at 109, some parties that care about
both concepts might still have separate enforcement/validation concerns for
the two concepts.  E.g., many clients want some sort of verifiable evidence
of the "same-party" concept but once that has been proven are more
generally willing to trust the provider to maintain the "similar-behavior"
concept as long as it's defined and specified as the intended behavior.

On Tue, Dec 8, 2020 at 9:20 AM Andrew Campling
<[email-masked]> wrote:

> > The message I got from the discussion was that equivalence was not what
> we were looking for.  Why is it not enough to say that an pointer is
> enough?  The entity providing the pointer can apply its own policies in
> determining what to point to (which might include the below), the entity
> following the pointer can do the same (again, including the below), and we
> might strongly recommend certain properties so as to create an expectation
> that the properties hold, but that's not equivalence.
>
> > >From my perspective, I would like to see a recommendation that the
> pointer only be given if the alternative resolver provides cryptographic
> protection for queries and responses (equivalent to DoT/DoH), has access to
> the same set of names, and has equivalent or better privacy treatment for
> queries.  That's 2-4 from your list, not 1.
>
> > The same entity thing is not a good idea.  I understand that people
> might want to enact that policy, but there are enough networks pointing to
> external providers that removing the option would be unwise.  I also
> understand that some networks or jurisdictions or clients might insist on
> this rule, but I don't quite understand how they guarantee that if it was
> important.
>
> I think that there are two similar but separate categories here, one for
> "equivalent" resolvers with a definition based on that provided in the
> earlier post from Chris Box, and potentially a second one for "designated"
> resolvers.  The main distinction of the second category is that it drops
> the requirement for it being from the same entity, could instead detail to
> a range of resolvers operated by multiple entities.  Whether there is a
> need for both categories in a user requirements document needs further
> thought.
>
> Note though that the inclusion of different entities could, in my view, be
> significant from the perspective of GDPR etc as a client could be directing
> personal data to a new data processor.  Those in countries or states
> without meaningful data privacy legislation may, of course, choose not to
> worry about such considerations.
>
> Andrew
>
> --
> Add mailing list
> [email-masked]

---

From: Ted Hardie <[email-masked]>
Date: Tue, 8 Dec 2020 09:51:22 -0800

> as a network operator, i want to say.
There clearly are also networking operators who want to point away to
different entities.  So if the pointer has to be able to distinguish
between those two claims, I'm fine.  But I will reiterate that this is not
possible for the end system to confirm at query time.  Org X can say "those
people are me" when they have outsourced to Provider Y, and the arguments
about whether that was a reasonable claim will not be bits on the wire.

regards,

Ted

---

From: "Martin Thomson" <[email-masked]>
Date: Wed, 09 Dec 2020 12:13:15 +1100

On Wed, Dec 9, 2020, at 04:33, Eric Orth wrote:
> E.g., many clients want some sort of 
> verifiable evidence of the "same-party" concept but once that has been 
> proven are more generally willing to trust the provider to maintain the 
> "similar-behavior" concept as long as it's defined and specified as the 
> intended behavior.

Requirements-in-a-vacuum problem: This is a fine statement in the abstract, but if you look at how this might be implemented, I claim that you will find that you have an opportunity to solve the overarching problem.  That is, the information the client needs to validate any same-party claim would also allow it to authenticate the network provider identity or choose a trustworthy, secured resolver.

Why would devote resources to solving the same-provider problem when that might solve the real problem the group has?

Ted made a similar point, namely that any same-provider claim is unverifiable.  If it was important and verifiable, then it might be worth pursuing, but while there might be some uncertainty about the former, the latter needs support for me to consider that pursuit.

---

From: Paul Vixie <[email-masked]>
Date: Thu, 10 Dec 2020 07:25:05 +0000

On Wed, Dec 09, 2020 at 12:13:15PM +1100, Martin Thomson wrote:
> Requirements-in-a-vacuum problem: This is a fine statement in the abstract,
> but if you look at how this might be implemented, I claim that you will find
> that you have an opportunity to solve the overarching problem.

i think the opportunity for obviation occurs elsewhere...

> That is, the information the client needs to validate any same-party claim
> would also allow it to authenticate the network provider identity or choose
> a trustworthy, secured resolver.

...specifically here. validation is an antipattern here. if one is inclined
to believe any answer received from the same-party claim-source, then one must
be prepared to believe its same-party claims. if we must reject either due to
non-validation, then we must reject both, which is absurd. reason backward.

> Why would devote resources to solving the same-provider problem when that
> might solve the real problem the group has?

we won't be. we will either say that the referral ("pointer") must only be
sent for same-entity, or say that same-entity is a boolean attached to the
referral ("pointer"). the rest is local policy, and out of scope.

> Ted made a similar point, namely that any same-provider claim is
> unverifiable. ...

i answered ted similarly.

> ... If it was important and verifiable, then it might be worth pursuing,
> but while there might be some uncertainty about the former, the latter
> needs support for me to consider that pursuit.

this is nonsequitur, though at heart, noone will expect you to pursue
something you see no point in.

-- 
Paul Vixie

---

From: "Martin Thomson" <[email-masked]>
Date: Fri, 11 Dec 2020 10:48:03 +1100

> non-validation, then we must reject both, which is absurd. reason backward.

I think that we agree on the facts, but not the conclusion you draw from it.  I conclude that same-entity isn't a requirement that is worth trying to build a protocol mechanism for.  I infer that you would agree, but still insist on same-entity being a deployment requirement.  Is that the split?

---

From: Vittorio Bertola <[email-masked]>
Date: Fri, 11 Dec 2020 11:01:33 +0100 (CET)

> Il 11/12/2020 00:48 Martin Thomson <[email-masked]> ha scritto:
> 
>  

If I may provide another perspective, I think that the requirements for non-experimental deployment models will be significantly shaped by the legal constraints. Thus, same-entity is likely to be a deployment requirement for those that want to do automatic upgrades in countries with strict privacy laws, as it avoids the problem of how to legally add one more entity into the personal data loop without having to ask anything to the user.

If we want to give up providing a better technical mechanism for same-provider auto-upgrade, we should be very clear on whether we also mean that we recommend not to use that as a deployment model, or that we recommend to use it through existing technologies, or that we do not want to enter into that decision as it is a policy choice, so both choices would be valid.

In any case, there are strong expectations among external non-technical stakeholders that the IETF will soon produce a SPAU discovery mechanism, as that has been understood as the way through which the IETF will respond to the policy issues raised by early DoH deployments. If this is not the case any more, we'd better have a clear plan B.

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

---

From: "Martin Thomson" <[email-masked]>
Date: Fri, 11 Dec 2020 21:04:57 +1100

On Fri, Dec 11, 2020, at 21:01, Vittorio Bertola wrote:
> If I may provide another perspective, I think that the requirements for 
> non-experimental deployment models will be significantly shaped by the 
> legal constraints. Thus, same-entity is likely to be a deployment 
> requirement for those that want to do automatic upgrades in countries 
> with strict privacy laws, as it avoids the problem of how to legally 
> add one more entity into the personal data loop without having to ask 
> anything to the user.

This seems reasonable.  What expectations do you have regarding where the responsibility for compliance would lie in the case where a network operator provides a reference?  Or, where the DNS resolver provides a reference?  Would the client share responsibility?

I ask because if the client can't authenticate the claim, it might not be reasonable to have it assume responsibility in this case.  It might be that best effort (check that the IP matches) is acceptable though.

(It might be that this comes down to: wait and see, then ask a lawyer, that's OK too, but it doesn't give us much to base design decisions on.)

---

From: Vittorio Bertola <[email-masked]>
Date: Fri, 11 Dec 2020 18:10:24 +0100 (CET)

> Il 11/12/2020 11:04 Martin Thomson <[email-masked]> ha scritto:
> 
>  

This is definitely a question for a lawyer :-) In GDPR terms, I would say that the DNS client is at least a "joint controller" of the user's DNS queries, no matter who tells them what. But if you go down that path, you might conclude that the client will always have to ask for the user's informed consent whenever a new server is contacted, and you end up with the DNS version of cookie popups. As an exception, the resolver of the user's Internet access provider might be safe, as the user consents to share data with it when they sign a contract for Internet access. But again, this is a question for a lawyer.

> (It might be that this comes down to: wait and see, then ask a lawyer, that's OK too, but it doesn't give us much to base design decisions on.)

This looks like a bit of a problem in the IETF's process: standards seem to be designed without having ascertained the non-technical requirements. Even if we wanted to do that, however, how to do that is not immediate.

---

From: Chris Box <[email-masked]>
Date: Tue, 22 Dec 2020 17:48:20 +0000

I've waited for the dust to settle on this thread, and would like to
attempt to move it towards a conclusion in the new year. Here goes!

I think Eric Orth's proposal is wise, i.e. separating "same-party" (1) from
similar-behavior (2,3,4). We appear to agree on the need for an expectation
of similar behavior, perhaps with tweaks to the wording. What is more
extensively debated is same-party or same-entity. To be clear, this is not
saying anything about the operator of the network; it's purely referring to
the operators of the DNS servers (A and B).

Vittorio and Andrew made similar points: a claim for same-entity is
particularly useful in the context of GDPR, because it removes the need for
the client to have to seek the end user's permission to use a new data
processor (and perhaps controller). Of course these are only claims, and
servers can lie, but dealing with the lies goes well beyond the scope of
this working group, to regulators, courts, the press, etc.

So I agree that the ability to say "B is also operated by me" is useful for
clients, just as the ability to say "B has the same behavior as me" is
useful. They're different concepts, but both have value in different
applications.

Martin, do you still object to having same-party as an optional component
of this use case?

Ted, same question, do you still object? I know you also raised the point
about what happens when A is already operated by multiple entities (like
the Root), or if B is operated by more than one. My answer is that in those
cases, the same-party claim should not be made.

This will probably be my last post of 2020 so I wish you all a good
Christmas break, and hope you have time away from complex technical
discussions!

Chris

On Fri, 11 Dec 2020 at 17:10, Vittorio Bertola <vittorio.bertola=
[email-masked]> wrote:

> > This seems reasonable.  What expectations do you have regarding where
> the responsibility for compliance would lie in the case where a network
> operator provides a reference?  Or, where the DNS resolver provides a
> reference?  Would the client share responsibility?
>
> This is definitely a question for a lawyer :-) In GDPR terms, I would say
> that the DNS client is at least a "joint controller" of the user's DNS
> queries, no matter who tells them what. But if you go down that path, you
> might conclude that the client will always have to ask for the user's
> informed consent whenever a new server is contacted, and you end up with
> the DNS version of cookie popups. As an exception, the resolver of the
> user's Internet access provider might be safe, as the user consents to
> share data with it when they sign a contract for Internet access. But
> again, this is a question for a lawyer.
>
> > I ask because if the client can't authenticate the claim, it might not
> be reasonable to have it assume responsibility in this case.  It might be
> that best effort (check that the IP matches) is acceptable though.
> >
> > (It might be that this comes down to: wait and see, then ask a lawyer,
> that's OK too, but it doesn't give us much to base design decisions on.)
>
> This looks like a bit of a problem in the IETF's process: standards seem
> to be designed without having ascertained the non-technical requirements.
> Even if we wanted to do that, however, how to do that is not immediate.
>
> --

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 22 Dec 2020 13:29:14 -0800

I actually think we should just abandon the use of equivalence.

As I understand it, the purpose of this general line of work is for
the network to communicate to clients "I'd like you to use this DoE
server". At that point, the client can then either choose to use that
server or not.

>From the perspective of requirements, then, I think the relevant
question is what other information the client might be interested in
having in order to make the decision as to whether to use that server
[0]. For instance, the network might represent:

1. This resolver will give more or less the same answers as the
   Do53 resolver.
2. This resolver is operated by the same people as the Do53 resolver.

However, I don't think the right way to address this is to say that
you can only advertise a new resolver if you meet certain criteria.
Rather, the way to address these issues is to have an extensible
protocol which allows the network to make a set of such assertions
that are potentially of interest to the client.

This of course brings us to the question then becomes, "what
assertions might the client be interested in consuming", which is, I
imagine, different for different clients.

Of course, at this point we are writing requirements text,
so I think we should stop saying anything about equivalent
and instead just talk about "recommended" as you do in S 3
of your draft. Specifically, I would say something like:

* Discovery MUST provide a local network the ability to announce to
  clients a set of, or absence of, recommended resolvers.

* Discovery MUST provide extensible functionality to announce other
  properties of recommended resolvers.

One might imagine having the requirements document also specify
an initial set of properties for this second bullet (e.g.,
"recommended resolver gives similar answers", "recommended resolver
is operated the same entity") but as it's
extensible it's probably just easiest to defer that to protocol
definition.

-Ekr

[0] It's worth noting that for Do53, pretty much all you get is "hey,
over here".

On Tue, Dec 22, 2020 at 9:48 AM Chris Box <[email-masked]> wrote:

> I think Eric Orth's proposal is wise, i.e. separating "same-party" (1)
> from similar-behavior (2,3,4). We appear to agree on the need for an
> expectation of similar behavior, perhaps with tweaks to the wording. What
> is more extensively debated is same-party or same-entity. To be clear, this
> is not saying anything about the operator of the network; it's purely
> referring to the operators of the DNS servers (A and B).
>
> So I agree that the ability to say "B is also operated by me" is useful
> for clients, just as the ability to say "B has the same behavior as me" is

---

From: Eric Orth <[email-masked]>
Date: Tue, 22 Dec 2020 16:56:26 -0500

While I agree that declaring "equivalence" or anything like that to be an
absolute requirement for advertising providers is probably too far, I think
these (equivalence, same-party, etc) are signals that clients will want to
use often enough in decision making that it seems very beneficial to come
up with common definitions of the concepts in the requirements document.
It can then be left to the protocol to define how/if the signal is
communicated (or make protocol-specific equivalence/etc requirements and
thus signal equivalence/etc by pure presence of the recommended provider
iff it makes sense for the usecases of the specific protocol).

On Tue, Dec 22, 2020 at 4:30 PM Eric Rescorla <[email-masked]> wrote:

>>> This is definitely a question for a lawyer :-) In GDPR terms, I would
>>> say that the DNS client is at least a "joint controller" of the user's DNS

---

From: "Vinny Parla (vparla)" <[email-masked]>
Date: Tue, 22 Dec 2020 22:03:04 +0000

Hi,

I take ‘equivalence’ to mean it will provide the same capabilities/limitations as Do53 with the additional security offered by the encryption protocol(s). Nothing more.  There is no way to reliably determine that Do53 and Encrypted-DNS ‘equivalence’ are the same entity since there is no way to actually ascertain the provenance of the original Do53 messages.

-Vinny

From: Add <[email-masked]> On Behalf Of Eric Orth
Sent: Tuesday, December 22, 2020 4:56 PM
To: Eric Rescorla <[email-masked]>
Cc: ADD Mailing list <[email-masked]>
Subject: Re: [Add] [EXT] Re: Definition of equivalence

While I agree that declaring "equivalence" or anything like that to be an absolute requirement for advertising providers is probably too far, I think these (equivalence, same-party, etc) are signals that clients will want to use often enough in decision making that it seems very beneficial to come up with common definitions of the concepts in the requirements document.  It can then be left to the protocol to define how/if the signal is communicated (or make protocol-specific equivalence/etc requirements and thus signal equivalence/etc by pure presence of the recommended provider iff it makes sense for the usecases of the specific protocol).

On Tue, Dec 22, 2020 at 4:30 PM Eric Rescorla <[email-masked] <mailto:[email-masked]> > wrote:

-Ekr

 

On Tue, Dec 22, 2020 at 9:48 AM Chris Box <[email-masked] <mailto:[email-masked]> > wrote:

I've waited for the dust to settle on this thread, and would like to attempt to move it towards a conclusion in the new year. Here goes!

I think Eric Orth's proposal is wise, i.e. separating "same-party" (1) from similar-behavior (2,3,4). We appear to agree on the need for an expectation of similar behavior, perhaps with tweaks to the wording. What is more extensively debated is same-party or same-entity. To be clear, this is not saying anything about the operator of the network; it's purely referring to the operators of the DNS servers (A and B).

Vittorio and Andrew made similar points: a claim for same-entity is particularly useful in the context of GDPR, because it removes the need for the client to have to seek the end user's permission to use a new data processor (and perhaps controller). Of course these are only claims, and servers can lie, but dealing with the lies goes well beyond the scope of this working group, to regulators, courts, the press, etc.

So I agree that the ability to say "B is also operated by me" is useful for clients, just as the ability to say "B has the same behavior as me" is useful. They're different concepts, but both have value in different applications.

Martin, do you still object to having same-party as an optional component of this use case?

Ted, same question, do you still object? I know you also raised the point about what happens when A is already operated by multiple entities (like the Root), or if B is operated by more than one. My answer is that in those cases, the same-party claim should not be made.

This will probably be my last post of 2020 so I wish you all a good Christmas break, and hope you have time away from complex technical discussions!

Chris

On Fri, 11 Dec 2020 at 17:10, Vittorio Bertola <vittorio.bertola=[email-masked] <mailto:[email-masked]> > wrote:

> Il 11/12/2020 11:04 Martin Thomson <[email-masked] <mailto:[email-masked]> > ha scritto:
> 
>  

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

-- 
Add mailing list
[email-masked] <mailto:[email-masked]> 
https://www.ietf.org/mailman/listinfo/add

-- 
Add mailing list
[email-masked] <mailto:[email-masked]> 
https://www.ietf.org/mailman/listinfo/add

-- 
Add mailing list
[email-masked] <mailto:[email-masked]> 
https://www.ietf.org/mailman/listinfo/add

---

From: Michael Richardson <[email-masked]>
Date: Tue, 22 Dec 2020 20:00:54 -0500

> that are potentially of interest to the client.

I agree.
The network can represent anything it wants, it's up to the client to decide
how to behave.  It's never worked to tell senders what to send, but rather, to
counsel receivers on what appropriate actions to take on each message type.

    > properties of recommended resolvers.

Sounds good.
Why doe the properties have to be in the discovery?
Why can't they be in DNS pseudo-RRs?

    > [0] It's worth noting that for Do53, pretty much all you get is "hey,

more of actually, "hey, it's over *there*" :-)

--
Michael Richardson <[email-masked]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 22 Dec 2020 17:03:47 -0800

> Why can't they be in DNS pseudo-RRs?

No particular reason. Just clumsy phrasing on my part. I think the
requirement just needs to be "there's some standardized way to find them",
right?

> more of actually, "hey, it's over *there*" :-)

Agreed.

-Ekr

---

From: Vittorio Bertola <[email-masked]>
Date: Wed, 23 Dec 2020 12:18:52 +0100 (CET)

>     Il 22/12/2020 22:29 Eric Rescorla <[email-masked]> ha scritto:
> 
I don't think that this was the objective. However, you still have to define a concept of equivalence if you want the resolver to provide an assertion of equivalence in the context of "other information the client might be interested in". As Eric Orth pointed out, there are clients that are interested in receiving and consuming this information, and having an agreed definition of what these concepts mean would be helpful to interoperability, even if it is interoperability in a policy sense.

On the other hand, since anyone willing to use these signals will need to trust the Do53 resolver and its communications, I think we can keep the definition relatively vague, as it will entirely be up to the resolver operator to determine whether the definition is met or not, and thus whether certain properties should be declared as true; clients will have to trust their judgement (or verify it independently from the discovery process) anyway.

Here we are in the realm of voluntary cooperation among good-willing parties, so I think that we are assuming that the resolver is not an adversary, because if we assumed the opposite, there would be no point in establishing any kind of discovery and property communication mechanism. Clients that are not ready to make that assumption (not even if subject to additional checks and restrictions, which pertain to each client's own policy) will not use these definitions anyway, but clients that, at least in some circumstances, are willing to trust the existing resolver would benefit from some standardization.

--

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

---

From: Andrew Campling <[email-masked]>
Date: Sun, 27 Dec 2020 18:05:04 +0000

On Tue, Dec 23, 2020 11:19 AM Vittorio Bertola <[email-masked]<mailto:[email-masked]>> wrote:

Il 22/12/2020 22:29 Eric Rescorla <[email-masked]<mailto:[email-masked]>> ha scritto:

> Here we are in the realm of voluntary cooperation among good-willing parties, so I think that we are assuming that the resolver is not an adversary, because if we assumed the opposite, there would…

+1 to Vittorio’s points above.

Having an agreed definition of equivalence that includes an indication that is operated by the same entity is necessary if clients are to continue to offer a “same provider auto-upgrade” mechanism (I’m assuming that most clients will prefer to use a standards-based discovery mechanism rather than curating their own lists of resolvers).

Andrew