Subject: Re: [Add] [EXT] Re: Definition of equivalence

From: Ben Schwartz <[email-masked]>
Date: Thu, 7 Jan 2021 11:50:01 -0500

I do not believe there is any coherent meaning to "same entity" in this
context, and I do not think we should require any design to attempt to make
sense of it.  Attempting to enforce any "same entity" restriction can only
harm users' privacy, not improve it.  (We also run the risk of
seriously confusing policymakers by misrepresenting the technology.)

I know it's tempting to believe that the user can keep themselves safer by
refusing to follow certain upgrade instructions, but this is just not
true.  The user is always _less_ protected if they refuse to perform an
upgrade based on a "same-entity" criterion:
- If the original server is acting in good faith, then the upgrade is safe
by definition.
- If the original server is not acting in good faith, it can reveal all the
user's query information to any third party whether or not the user accepts
the upgrade.

In other words, "same entity" restrictions are an Evil Bit (RFC 3514).

I think we should focus on (a) providing clear guidance to server operators
about appropriate use of the upgrade mechanism and (b) identifying relevant
use cases.  For example, I think some of the "same entity" concerns are
really about minimizing disruption to non-updatable legacy split-horizon
forwarder configurations.  That's a legitimate technical concern that we
can address directly.

On Sun, Dec 27, 2020 at 1:05 PM Andrew Campling
<[email-masked]> wrote:

> On Tue, Dec 23, 2020 11:19 AM Vittorio Bertola <
> [email-masked]> wrote:
>
>
>
> Il 22/12/2020 22:29 Eric Rescorla <[email-masked]> ha scritto:
>
>
> 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.
>
>
>
> > 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.
>
>
>
>
>
> +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
>
> --
> Add mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/add
>

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 7 Jan 2021 18:43:32 +0000

On Jan 7, 2021, at 8:50 AM, Ben Schwartz <bemasc=[email-masked]> wrote:
> 
> I do not believe there is any coherent meaning to "same entity" in this context, and I do not think we should require any design to attempt to make sense of it.  Attempting to enforce any "same entity" restriction can only harm users' privacy, not improve it.  (We also run the risk of seriously confusing policymakers by misrepresenting the technology.)

Thank you to Ben for such a concise summary. I support all of those statements.

--Paul Hoffman

---

From: Eric Orth <[email-masked]>
Date: Thu, 7 Jan 2021 13:47:46 -0500

On Thu, Jan 7, 2021 at 11:50 AM Ben Schwartz <bemasc=
[email-masked]> wrote:

> - If the original server is not acting in good faith, it can reveal all
> the user's query information to any third party whether or not the user
> accepts the upgrade.
>

Counterargument: Most of the protocols under consideration in this space do
not provide any protection that the upgrade signal is even being provided
by the original server.  If an attacker manages a transient interception
(which isn't a very far-fetched scenario when dealing with DNS over UDP),
then the client trusting that signal and performing upgrade changes the
transient attack to a persistent attack.  Alternatively, if an attacker
manages an insertion-only attack but couldn't read the genuine requests or
responses (again not very far-fetched with DNS over UDP), the
attacker could trick the client into switching to a DNS server the attacker
completely controls.

Same-entity protections provide one possible mitigation to these attack
scenarios if they allow a client to validate that the upgrade target is
reasonable for the user's intended original server (whether or not the
upgrade signaler actually matches that user intention).

---

From: Andrew Campling <[email-masked]>
Date: Thu, 7 Jan 2021 18:58:50 +0000

> I know it's tempting to believe that the user can keep themselves safer by refusing to follow certain upgrade instructions, but this is just not true.  The user is always _less_ protected if they refuse to perform an upgrade based on a "same-entity" criterion:
> - If the original server is acting in good faith, then the upgrade is safe by definition.
> - If the original server is not acting in good faith, it can reveal all the user's query information to any third party whether or not the user accepts the upgrade.

> I think we should focus on (a) providing clear guidance to server operators about appropriate use of the upgrade mechanism and (b) identifying relevant use cases.  For example, I think some of the "same entity" concerns are really about minimizing disruption to non-updatable legacy split-horizon forwarder configurations.  That's a legitimate technical concern that we can address directly.

This appears to rule out the provision of same-provider auto-upgrade unless clients continue to operate proprietary, curated lists, which of course leaves them open to being treated as data controllers under GDPR, requiring them to strike contractual agreements with all participating resolver operators than are in turn treated as data processors.  Given that SPAU is the most straight forward way to gain adoption of encrypted DNS, it is surely in the best interest of end-users to find an acceptable way to implement “same entity”, as envisaged in earlier discussions.

In my view, those that disagree do not have to implement SPAU but should not rule it out for others.

Andrew

---

From: Ben Schwartz <[email-masked]>
Date: Thu, 7 Jan 2021 14:08:14 -0500

On Thu, Jan 7, 2021 at 1:48 PM Eric Orth <ericorth=
[email-masked]> wrote:

> Counterargument: Most of the protocols under consideration in this space
> do not provide any protection that the upgrade signal is even being
> provided by the original server.  If an attacker manages a transient
> interception (which isn't a very far-fetched scenario when dealing with DNS
> over UDP), then the client trusting that signal and performing upgrade
> changes the transient attack to a persistent attack.
>

Absolutely, that is an important security consideration that we should
address carefully in our threat modeling.

>   Alternatively, if an attacker manages an insertion-only attack but
> couldn't read the genuine requests or responses (again not very far-fetched
> with DNS over UDP), the attacker could trick the client into switching to a
> DNS server the attacker completely controls.
>

Nit: I'm not sure this makes sense.  This attacker has to be able to read
queries in order to inject a response, so the game is already lost.

> upgrade signaler actually matches that user intention).

Yes, we need to be very careful with upgrades when we don't have good
authentication of the upgrade info.

No, I still don't like the term "same-entity" for this.

The problem is that "same-entity" implies that we can identify the
"entity", but the reason we can't authenticate the upgrade info (in this
scenario) is because we don't have a strong identifier for the "entity".
It's paradoxical.

For a requirements document, rather than speak about "same-entity" rules, I
would simply require the solution to defeat the attack you described.  In
whatever specification we devise, we can speak about the actual mechanism,
which is likely to involve IP addresses, certificates, and other things
that are not "entities".

---

From: Tommy Jensen <[email-masked]>
Date: Thu, 7 Jan 2021 20:27:40 +0000

> For a requirements document, rather than speak about "same-entity" rules, I would simply require the solution to defeat the attack you described.  In whatever specification we devise, we can speak about the actual mechanism, which is likely to involve IP addresses, certificates, and other things that are not "entities".

I can see now why “same entity” isn’t working for you and others. How does the term “designated” work for you in requirement docs? I can imagine the term being applicable whether a forwarder is sending clients to an off-network resolver as well as when a resolver is bootstrapping itself.

Thanks,
Tommy

From: Add <[email-masked]> On Behalf Of Ben Schwartz
Sent: Thursday, January 7, 2021 11:08 AM
To: Eric Orth <ericorth=[email-masked]>
Cc: Chris Box <[email-masked]>; Andrew Campling <[email-masked]>; ADD Mailing list <[email-masked]>; Vittorio Bertola <[email-masked]>; Eric Rescorla <[email-masked]>
Subject: [EXTERNAL] Re: [Add] [EXT] Re: Definition of equivalence

On Thu, Jan 7, 2021 at 1:48 PM Eric Orth <ericorth=[email-masked]<mailto:[email-masked]>> wrote:

On Thu, Jan 7, 2021 at 11:50 AM Ben Schwartz <bemasc=[email-masked]<mailto:[email-masked]>> wrote:
- If the original server is acting in good faith, then the upgrade is safe by definition.
- If the original server is not acting in good faith, it can reveal all the user's query information to any third party whether or not the user accepts the upgrade.

Counterargument: Most of the protocols under consideration in this space do not provide any protection that the upgrade signal is even being provided by the original server.  If an attacker manages a transient interception (which isn't a very far-fetched scenario when dealing with DNS over UDP), then the client trusting that signal and performing upgrade changes the transient attack to a persistent attack.

Absolutely, that is an important security consideration that we should address carefully in our threat modeling.

  Alternatively, if an attacker manages an insertion-only attack but couldn't read the genuine requests or responses (again not very far-fetched with DNS over UDP), the attacker could trick the client into switching to a DNS server the attacker completely controls.

Nit: I'm not sure this makes sense.  This attacker has to be able to read queries in order to inject a response, so the game is already lost.

Same-entity protections provide one possible mitigation to these attack scenarios if they allow a client to validate that the upgrade target is reasonable for the user's intended original server (whether or not the upgrade signaler actually matches that user intention).

Yes, we need to be very careful with upgrades when we don't have good authentication of the upgrade info.

The problem is that "same-entity" implies that we can identify the "entity", but the reason we can't authenticate the upgrade info (in this scenario) is because we don't have a strong identifier for the "entity".  It's paradoxical.

For a requirements document, rather than speak about "same-entity" rules, I would simply require the solution to defeat the attack you described.  In whatever specification we devise, we can speak about the actual mechanism, which is likely to involve IP addresses, certificates, and other things that are not "entities".

---

From: Ben Schwartz <[email-masked]>
Date: Thu, 7 Jan 2021 15:36:49 -0500

On Thu, Jan 7, 2021 at 3:27 PM Tommy Jensen <Jensen.Thomas=
[email-masked]> wrote:

> How does the term “designated” work for you in requirement docs? I can
> imagine the term being applicable whether a forwarder is sending clients to
> an off-network resolver as well as when a resolver is bootstrapping itself.
>

I'm definitely supportive of that language.

>
>
> Thanks,
>
> Tommy
>
>
>
> *From:* Add <[email-masked]> *On Behalf Of * Ben Schwartz
> *Sent:* Thursday, January 7, 2021 11:08 AM
> *To:* Eric Orth <ericorth=[email-masked]>
> *Cc:* Chris Box <[email-masked]>; Andrew Campling
> <[email-masked]>; ADD Mailing list <[email-masked]>;
> Vittorio Bertola <[email-masked]>; Eric Rescorla <
> [email-masked]>
> *Subject:* [EXTERNAL] Re: [Add] [EXT] Re: Definition of equivalence
>
>
>
>
>
>
>
> For a requirements document, rather than speak about "same-entity" rules,
> I would simply require the solution to defeat the attack you described.  In

---

From: Andrew Campling <[email-masked]>
Date: Thu, 7 Jan 2021 21:12:07 +0000

> I can see now why “same entity” isn’t working for you and others. How does the term “designated” work for you in requirement docs? I can imagine the term being applicable whether a forwarder is sen…

Is there a reason to make this an either/or decision?  In my view, “designated” and “equivalent” share some properties but are different, assuming that the latter denotes “same entity”.  Both are potentially useful but could have different consequences to an end-user (or their personal data at least) so should be treated as different.  Why wouldn’t a user requirements document cover both?

Andrew

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 7 Jan 2021 13:44:40 -0800

On Thu, Jan 7, 2021 at 1:12 PM Andrew Campling
<[email-masked]> wrote:

> On Thu, Jan 7, 2021 at 20:28 Tommy Jensen <[email-masked]>
> wrote:
>
>
>
> > I can see now why “same entity” isn’t working for you and others. How
> does the term “designated” work for you in requirement docs? I can imagine
> the term being applicable whether a forwarder is sending clients to an
> off-network resolver as well as when a resolver is bootstrapping itself.
>
>
>
> Is there a reason to make this an either/or decision?  In my view,
> “designated” and “equivalent” share some properties but are different,
> assuming that the latter denotes “same entity”.
>

Why would "equivalent" denote "same-entity"? On the contrary, it seems very
common for even the same entity to run multiple non-equivalent resolvers
(e.g., one unfiltered one and one filtered one).

-Ekr

---

From: "[email-masked]" <[email-masked]>
Date: Fri, 8 Jan 2021 11:03:10 +0100 (CET)

>     Il 07/01/2021 22:44 Eric Rescorla <[email-masked]> ha scritto:
> 
> 
> 
> 
>     On Thu, Jan 7, 2021 at 1:12 PM Andrew Campling <[email-masked]> wrote:
> 
>         > > 
> >         On Thu, Jan 7, 2021 at 20:28 Tommy Jensen <[email-masked] mailto:[email-masked] > wrote:
> > 
> >          
> > 
> >         Is there a reason to make this an either/or decision?  In my view, “designated” and “equivalent” share some properties but are different, assuming that the latter denotes “same entity”. 
> > 
> >     > 
>     Why would "equivalent" denote "same-entity"? On the contrary, it seems very common for even the same entity to run multiple non-equivalent resolvers (e.g., one unfiltered one and one filtered one).
> 
I think we are again conflating two different meanings of "equivalent". One is functional equivalence: the new server will apply the same policies of the old one, e.g. in terms of logging, filtering, processing of data. The other is legal equivalence: the new server will be run by the same entity in the same jurisdiction, and thus the upgrade will not add new parties into the personal information loop, will not require additional consent from the user and will not change the legal data protection regime.

Both concepts are policy-related, and may need to be conveyed in some way during the update process to allow the client and the end-user to decide whether to perform the upgrade (a decision which may be automated or not, may involve the end-user or not, etc. - this depends on client-side policy).

The old server may propose an upgrade to a new "designated" encrypted server which offers any combination of the two properties above: a "designated" server may be functionally equivalent, or legally equivalent, or both, or none.

The client, as far as I can see, will never be able to determine independently whether the old server's claim of either type of equivalence is true. Perhaps legal equivalence could be ascertained through extended certificates. Clients may try to verify functional equivalence by trying the same query and comparing the results. Still, any type of property associated with a designation will require the assumption of trust in the communications received from the old server. (But of course any ideas on how to authenticate these claims would be welcome.)

I think that there are broad differences among us on whether that assumption of trust is acceptable, but this is going to be an individual decision for each client and end-user.

Additionally, requiring in a technical spec that a server only proposes upgrades to encrypted servers that possess one or both types of equivalence is futile - this will be the subject of server-side policy. I do think that there should be recommendations or even requirements about this, but these would be better discussed in policy venues, and are likely to change depending on each jurisdiction's data protection regime.

In the end, I think that the options we have for the technical upgrade protocol are the following:

a) we allow the upgrade message to carry information on the equivalences above, as unilaterally stated by the old server, so that clients that intend to trust and consume that information can do so; this could vary from a 2-bit field up to any kind of complex policy expression language;

b) we disallow the upgrade message to carry information on the equivalences above, which will possibly lead, at least in some jurisdictions, to legal/policy requirements for DNS resolvers not to offer the upgrade to an encrypted resolver at all, unless the new server guarantees the equivalences above.

I personally prefer a), as it looks better suited to cover a wide range of use cases and policies, and likely to lead to more upgrades.

--

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: Fri, 8 Jan 2021 13:41:14 +0000

On Thu, Jan 7, 2021 at 21:45 Eric Rescorla <[email-masked]<mailto:[email-masked]>> wrote:

> On Thu, Jan 7, 2021 at 1:12 PM Andrew Campling <[email-masked]<mailto:[email-masked]>> wrote:

> Why would "equivalent" denote "same-entity"? On the contrary, it seems very common for even the same entity to run multiple non-equivalent resolvers (e.g., one unfiltered one and one filtered one).

As above, equivalent doesn’t just denote that a resolver is operated by the same entity (and is located in the same jurisdiction), but also that other factors are unchanged, that the same policies are applied (eg which may include filtering).  If an entity operates multiple Do53 resolvers then it could have equivalent DoE resolvers for each.

And to expand on my reasoning for “designated” being useful but different, I can envisage scenarios when, for example a closed Do53 resolver operator has both an “equivalent” DoE option when users are on-net (ie which works for clients using same-provider auto-upgrade) as well as a “designated” resolver (eg Quad9 or similar) recommended when a user is off-net.  I hope this provides a little more clarity.

Andrew

---

From: Andrew Campling <[email-masked]>
Date: Fri, 8 Jan 2021 13:50:52 +0000

> I personally prefer a), as it looks better suited to cover a wide range of use cases and policies, and likely to lead to more upgrades.

I agree that the concepts of equivalent and designated resolvers both assume that the resolver operator is trusted by the user, if not then any recommendations made by that resolver operator should rightly be ignored.  As to the definition of equivalent, and indeed designated, we can either work to agree on a single one or agree on the components together with a mechanism to single which apply in each case as Vittorio suggests.  It would be helpful to understand if there is a rough consensus regarding the preferred approach.

Andrew

---

From: Ben Schwartz <[email-masked]>
Date: Fri, 8 Jan 2021 10:14:22 -0500

On Fri, Jan 8, 2021 at 5:03 AM [email-masked]
<vittorio.bertola=[email-masked]> wrote:
...

> a) we allow the upgrade message to carry information on the equivalences
> above, as unilaterally stated by the old server, so that clients that
> intend to trust and consume that information can do so; this could vary
> from a 2-bit field up to any kind of complex policy expression language;
>
> b) we disallow the upgrade message to carry information on the
> equivalences above, which will possibly lead, at least in some
> jurisdictions, to legal/policy requirements for DNS resolvers not to offer
> the upgrade to an encrypted resolver at all, unless the new server
> guarantees the equivalences above.
>

This is quite different from the "same entity" concept as I understood it.
I was referring to the client attempting to prove whether the upgrade was
to the same entity _without_ trusting the server.  That's quite different
from the client simply accepting an assertion of "sameness" without
attempting to validate it.

However, I'm confused about the use case for a non-verifiable "not same
entity" indication.  Why would a server ever set that bit?

In the absence of a compelling use case, I would prefer to stick to case b).

---

From: "Martin Thomson" <[email-masked]>
Date: Mon, 11 Jan 2021 09:56:36 +1100

> In the absence of a compelling use case, I would prefer to stick to case b).

I share Ben's reservations.  As a client, we only have assertions, not proof.  I don't see any value in an unverifiable assertion.

It might be different if clients could do something with the information.

---

From: Vittorio Bertola <[email-masked]>
Date: Mon, 11 Jan 2021 10:39:11 +0100 (CET)

>     Il 08/01/2021 16:14 Ben Schwartz <bemasc=[email-masked]> ha scritto:
> 
> 
> 
> 
>     On Fri, Jan 8, 2021 at 5:03 AM [email-masked] mailto:[email-masked] <vittorio.bertola=[email-masked] mailto:[email-masked] > wrote:
>     ... 
> 
>         > > 
>     This is quite different from the "same entity" concept as I understood it.  I was referring to the client attempting to prove whether the upgrade was to the same entity _without_ trusting the server.  That's quite different from the client simply accepting an assertion of "sameness" without attempting to validate it.
> 
>     However, I'm confused about the use case for a non-verifiable "not same entity" indication.  Why would a server ever set that bit?
> 
For example, the operator of the unencrypted server could have outsourced the encrypted resolver to a different party. But I see this as the consequence of a broader design decision that needs to be taken: we can be as flexible as possible to allow the widest choice of policies by existing and future clients, or we can try to preempt policies by removing even the possibility for the server to assert certain properties.

--

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 11 Jan 2021 05:36:04 -0800

On Mon, Jan 11, 2021 at 1:39 AM Vittorio Bertola <vittorio.bertola=
[email-masked]> wrote:

> This is quite different from the "same entity" concept as I understood
> it.  I was referring to the client attempting to prove whether the upgrade
> was to the same entity _without_ trusting the server.  That's quite
> different from the client simply accepting an assertion of "sameness"
> without attempting to validate it.
>
> For example, the operator of the unencrypted server could have outsourced
> the encrypted resolver to a different party. But I see this as the
> consequence of a broader design decision that needs to be taken: we can be
> as flexible as possible to allow the widest choice of policies by existing
> and future clients, or we can try to preempt policies by removing even the
> possibility for the server to assert certain properties.
>

I don't think that's correct. Quite a bit earlier in this thread, I
proposed that we simply design an extensible protocol, so this function
could be added later. Currently we're at the requirements stage and so the
question is whether we need to design such a function in now.

-Ekr

> [email-masked]

---

From: Ben Schwartz <[email-masked]>
Date: Mon, 11 Jan 2021 10:10:00 -0500

On Mon, Jan 11, 2021 at 4:39 AM Vittorio Bertola <vittorio.bertola=
[email-masked]> wrote:

> the encrypted resolver to a different party.
>

If I understand correctly, you are (more specifically) describing a case in
which the unencrypted server has outsourced the encrypted resolver to a
party that is not already appropriately authorized to receive the user's
DNS query stream.  In this case, it seems to me that a "not same entity"
flag is far from sufficient.  The user would presumably also need to see
some human-meaningful identity for the additional party (a domain name
won't suffice), a privacy policy, terms of service, and possibly other
documentation.

I believe that this flow is not in scope for an "upgrade" protocol.  We are
no longer discussing an upgrade; we are discussing a "third-party resolver
advertisement", made without any guarantee.

I would much prefer to say that unencrypted->encrypted "upgrade" is
presumed to be non-user-visible, an internal detail of the DNS and related
protocols.  This at least makes the legal situation unambiguous: if you're
triggering an upgrade, you have to assume that it will happen without the
user's knowledge, and if that's not OK then you must not do it.

I would compare this to an HTTP 3XX redirect (often used for HTTP->HTTPS
upgrade).  Redirect following in web browsers is not gated on a user
consent step.  As a result, a 3XX redirect could be used to send user data
to an unauthorized third party.  We don't solve this by adding a flag that
says "user must approve this redirect"; we simply make it clear that 3XX
does not have user-approval, and let websites figure out what limits this
implies.

But I see this as the consequence of a broader design decision that needs
> to be taken: we can be as flexible as possible to allow the widest choice
> of policies by existing and future clients, or we can try to preempt
> policies by removing even the possibility for the server to assert certain
> properties.
>
> --
>

---

From: Vittorio Bertola <[email-masked]>
Date: Mon, 11 Jan 2021 18:07:03 +0100 (CET)

>     Il 11/01/2021 16:10 Ben Schwartz <bemasc=[email-masked]> ha scritto:
> 
> 
> 
> 
>     On Mon, Jan 11, 2021 at 4:39 AM Vittorio Bertola <vittorio.bertola=[email-masked] mailto:[email-masked] > wrote:
> 

> 
>         > >         For example, the operator of the unencrypted server could have outsourced the encrypted resolver to a different party.
> > 
> >     > 
>     If I understand correctly, you are (more specifically) describing a case in which the unencrypted server has outsourced the encrypted resolver to a party that is not already appropriately authorized to receive the user's DNS query stream.  In this case, it seems to me that a "not same entity" flag is far from sufficient.  The user would presumably also need to see some human-meaningful identity for the additional party (a domain name won't suffice), a privacy policy, terms of service, and possibly other documentation.
> 
>     I believe that this flow is not in scope for an "upgrade" protocol.  We are no longer discussing an upgrade; we are discussing a "third-party resolver advertisement", made without any guarantee.
> 
>     I would much prefer to say that unencrypted->encrypted "upgrade" is presumed to be non-user-visible, an internal detail of the DNS and related protocols.  This at least makes the legal situation unambiguous: if you're triggering an upgrade, you have to assume that it will happen without the user's knowledge, and if that's not OK then you must not do it.
> 
Thanks - now I get your objections, as you were considering a narrower use case than I was doing. However, in your model the server is preempting the client's decision on whether user consent is required, which may depend on the user's jurisdiction and on any existing legal relationship between the client and the user, previous privacy consent etc. I don't think that a server operator will always be in the position to do that evaluation and determine whether a non-user-visible update can legitimately be sent.

In any case, this was an attempt to build on Tommy Jensen's proposal to replace the concept of equivalence with the concept of designation, as a way to deal with a previous objection that you made. We can get back to discussing only the case of equivalence, though I still think that you cannot avoid the distinction between functional and legal equivalence, or at least you have to clarify which one(s) you want to require.

--