Subject: [Add] equivalence definition

From: Jim Reid <[email-masked]>
Date: Mon, 16 Nov 2020 08:41:39 +0000

The point I didn’t get to make at the mike is using “two or more resolvers operated by the same entity” as the definition of equivalence probably doesn’t work: the captive portal at $coffeeshop, enterprise nets that let some but not all users resolve names on the public Internet, local forwarders/proxies that send Do53 and DoH queries to different upstream servers, etc.

Although this definition might be a good enough starting point, I think there will be too many corner cases to make this apply in the general case.

---

From: Vittorio Bertola <[email-masked]>
Date: Mon, 16 Nov 2020 10:06:16 +0100 (CET)

> Il 16/11/2020 09:41 Jim Reid <[email-masked]> ha scritto:
> 
>  

IMHO the fundamental problem is that "equivalent resolvers" is a policy concept, so it is very hard to define it precisely in technical terms. 

For example, building on ekr's comment on the DEER draft:

> Il 15/11/2020 01:12 Eric Rescorla <[email-masked]> ha scritto:
> 
> S 2.
>  Equivalent Encrypted Resolver: An Encrypted Resolver which is
>  considered to provide answers equivalent to a given resolver.
>  This equivalency can be authenticated with TLS certificates.
> 
> This has the same problem as with draft-box. If the attacker
> stands up a resolver that proxies to the given resolver, it would
> meet this definition, but would not provide confidentiality,
> which is one of the prime motivators for this work.
> 
> I know this kind of thing is difficult to formalize, but I think
> we actually need to. There are two properties we need to capture
> (1) that your data is only going to the EER (2) that the answers
> are somehow similar. Perhaps.

In policy terms, the two conditions above (which are correct) become quite straightforward:
1) moving the DNS resolution service from the resolver to its EER does not introduce or remove any data controllers or processors, and
2) the EER applies the same query resolution policies as the original resolver.

I concede that you might need a bit of clarification on the fact that #2 isn't broken by differences in technical practices such as caching, prefetching etc. However, the magic of policy language is that being vague is ok and actually useful, differently from technical specifications. So you could adopt a definition like the above and then limit further discussions to corner cases where it is not fully clear whether something that the resolver does is a "query resolution policy" or not, while being able to proceed in all other cases.

Also, things could perhaps be easier if we limited ourselves to sub-cases of equivalence - for example, to "ISP-equivalent encrypted resolver", i.e. the encrypted resolver that is part of the resolver platform to which your DNS-forwarding home router forwards the queries it receives. This condition could be technically proven by relying on a SUDN query forwarded through the router, though it is unclear whether that could be done securely enough to make this definition useful.

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

---

From: Eric Orth <[email-masked]>
Date: Mon, 16 Nov 2020 04:15:19 -0500

And the points that I didn't get to make before that exciting conclusion:

I think the best answer is the combination of all these "you're missing
this side of it" points everybody is making.  Considering what's best for
the end user, overall, I think there are two big areas to consider to
really answer the question of whether or not an upgrade will be a good idea
for that user.

   1. Will the encrypted resolver keep working for the user as well as the
   unencrypted resolver.  This generally doesn't mean exact equivalence (the
   user doesn't care if resolvers have slight differences due to cached
   results) but just generally that if things were working well for the user
   before, they need to keep working and not feel broken to the user.  This
   includes stuff like reasonable performance after upgrade, any private names
   the user was relying on still being resolvable, any user-desired filtering
   still being in place, etc.
   2. Will the encrypted resolver meet the user's trust/privacy
   expectations.  If the user had any hand in choosing the unencrypted
   resolver (and clients often have no way of knowing whether or not that was
   the case), they would have every right to be upset if they get switched to
   a different resolver that isn't trustworthy for the user.  Need to ensure
   the same assignment of trust is maintained, or at least that a different
   switched-to resolver has high privacy standards.

How do we technically determine a resolver meets these needs? I don't
know.  It's hard.  For Chrome, we've found that "same provider" (same legal
entity controlling both resolvers) is a decent (but definitely not perfect)
technical signal.  It's the same entity a user has potentially chosen to
trust, and while not guaranteed, the provider generally wants to provide
the same working experience to their users, at least if they're suggesting
an upgrade should be made.

On Mon, Nov 16, 2020 at 3:43 AM Jim Reid <[email-masked]> wrote:

> The point I didn’t get to make at the mike is using “two or more resolvers
> operated by the same entity” as the definition of equivalence probably
> doesn’t work: the captive portal at $coffeeshop, enterprise nets that let
> some but not all users resolve names on the public Internet, local
> forwarders/proxies that send Do53 and DoH queries to different upstream
> servers, etc.
>
> Although this definition might be a good enough starting point, I think
> there will be too many corner cases to make this apply in the general case.
>
> --
> Add mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/add
>

---

From: Tommy Jensen <[email-masked]>
Date: Mon, 16 Nov 2020 09:26:55 +0000

> It's the same entity a user has potentially chosen to trust, and while not guaranteed, the provider generally wants to provide the same working experience to their users, at least if they're suggesting an upgrade should be made.

This I think is key nuance to highlight. If the upgrade mechanism is verifiable as the same controlling entity, then similar functionality should be a given. I do think it's fair per the discussion to define EER as "same functionality" but I think adding "same entity" as an AND clause prevents this from becoming a policy discussion.

Example: DNS Provider Foo offers "no edits" DNS as well as "ad blocking" and "kid friendly" functionalities. If a client asks for the EER from an ad-blocking Do53 Foo server, then they should end up with the configuration for an ad-blocking EER also from Foo.

To enable going from ad-blocking Do53 Foo to ad-blocking EER Bar (if we don't add "same entity" clause to EER definition) would require Foo and Bar can adhere to some shared definition of what ad-blocking is, opening the policy can of worms (how do we verify behavior?). Same entity means we side step that issue.

Thanks,
Tommy
________________________________
From: Add <[email-masked]> on behalf of Eric Orth <ericorth=[email-masked]>
Sent: Monday, November 16, 2020 1:15 AM
To: Jim Reid <[email-masked]>
Cc: ADD Mailing list <[email-masked]>
Subject: [EXTERNAL] Re: [Add] equivalence definition

I think the best answer is the combination of all these "you're missing this side of it" points everybody is making.  Considering what's best for the end user, overall, I think there are two big areas to consider to really answer the question of whether or not an upgrade will be a good idea for that user.

  1.  Will the encrypted resolver keep working for the user as well as the unencrypted resolver.  This generally doesn't mean exact equivalence (the user doesn't care if resolvers have slight differences due to cached results) but just generally that if things were working well for the user before, they need to keep working and not feel broken to the user.  This includes stuff like reasonable performance after upgrade, any private names the user was relying on still being resolvable, any user-desired filtering still being in place, etc.
  2.  Will the encrypted resolver meet the user's trust/privacy expectations.  If the user had any hand in choosing the unencrypted resolver (and clients often have no way of knowing whether or not that was the case), they would have every right to be upset if they get switched to a different resolver that isn't trustworthy for the user.  Need to ensure the same assignment of trust is maintained, or at least that a different switched-to resolver has high privacy standards.

How do we technically determine a resolver meets these needs? I don't know.  It's hard.  For Chrome, we've found that "same provider" (same legal entity controlling both resolvers) is a decent (but definitely not perfect) technical signal.  It's the same entity a user has potentially chosen to trust, and while not guaranteed, the provider generally wants to provide the same working experience to their users, at least if they're suggesting an upgrade should be made.

On Mon, Nov 16, 2020 at 3:43 AM Jim Reid <[email-masked]<mailto:[email-masked]>> wrote:
The point I didn’t get to make at the mike is using “two or more resolvers operated by the same entity” as the definition of equivalence probably doesn’t work: the captive portal at $coffeeshop, enterprise nets that let some but not all users resolve names on the public Internet, local forwarders/proxies that send Do53 and DoH queries to different upstream servers, etc.

--
Add mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/add<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fadd&data=04%7C01%7CJensen.Thomas%40microsoft.com%7C56094efec9894d8b3fc908d88a103273%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637411149512782818%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=WGJjtFLJiqPK6Z6x%2BjiYH1rBGSRyKshuHFIQv50e1mA%3D&reserved=0>

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Mon, 16 Nov 2020 10:31:36 +0100

On Mon, Nov 16, 2020 at 08:41:39AM +0000,
 Jim Reid <[email-masked]> wrote 
 a message of 11 lines which said:

> The point I didn’t get to make at the mike is using “two or more
> resolvers operated by the same entity” as the definition of
> equivalence probably doesn’t work:

Another case where it doesn't work is when the same entity offers
different services (one lying and one not, for instance), which is
common among public resolvers <https://quad9.net/faq/>
<https://dns.yandex.com/>
<https://blog.cloudflare.com/introducing-1-1-1-1-for-families/>, etc

I suggest to not just say "equivalent" but be more specific: "with
equivalent answers". Equivalent answers being defined by the user's
use cases. If resolver A censors SciHub and resolver B does not, they
do not yield equivalent answers. If resolver A sees gmail.com at
2a00:1450:400e:809::2005 and resolver B sees it at
2a00:1450:4007:816::2005, they probably give equivalent answers, as
far as the ordinary user is concerned.

"Equivalent" is too loaded to be used alone.

---

From: "Martin Thomson" <[email-masked]>
Date: Mon, 16 Nov 2020 20:38:58 +1100

My definition was slightly different:

If we assume that either Do53 discovery was perfectly secure, OR that plus the Do53 resolver itself were perfectly secure, then - in the presence of a Dolev-Yao attacker and any information obtained from those perfectly secure sources, can we provide something that uses TLS and is reasonably secure?

I think that we can, but not in the presence of old DNS forwarders that can't be updated.

What I heard from David Schinazi (though these were I think Eric Orth's figures) was that the environment was such that none of our existing solutions would work and we would need a looser definition if we were to be able to offer DoH/DoT to most users.  If we don't accept something a little more opportunistic, we only get ~15% of people (assuming that dataset is representative, which I believe it should be).

---

From: Ben Schwartz <[email-masked]>
Date: Mon, 16 Nov 2020 16:02:23 -0500

I think "equivalence" here is not an "equivalence relation"; it is not
symmetric.  What we mean by "equivalent" is more like "equivalent or
better".

I think part of our confusion is that we are describing two separate
things.  Before recommending an upgrade from (unencrypted) server A to
(encrypted) server B:

1. What properties of these servers can the client prove to itself?
2. What conditions are we asking the operator(s) of these servers to meet?

For example, we might ask that the operator of server B conform to the
privacy policy of server A, but this is not verifiable by the client.
Similarly, I don't think we intend for clients to verify that they get the
same answers from servers A and B, even if we want the answers to be
"equivalent".

In the local network use case, it's important to ask what properties the
client can prove about server A.  In particular, I posit that any
persistent attacker who can answer queries sent to server A is
indistinguishable from server A.  This suggests a possible solution to the
local network use case: ask the client to regularly revalidate server A's
intention to upgrade to server B, and stop using server B if server A stops
recommending it.

On Mon, Nov 16, 2020 at 4:39 AM Martin Thomson <[email-masked]> wrote:

> If we assume that either Do53 discovery was perfectly secure, OR that plus
> the Do53 resolver itself were perfectly secure, then - in the presence of a
> Dolev-Yao attacker and any information obtained from those perfectly secure
> sources, can we provide something that uses TLS and is reasonably secure?
>
> What I heard from David Schinazi (though these were I think Eric Orth's
> figures) was that the environment was such that none of our existing
> solutions would work and we would need a looser definition if we were to be
> able to offer DoH/DoT to most users.  If we don't accept something a little
> more opportunistic, we only get ~15% of people (assuming that dataset is
> representative, which I believe it should be).
>

---

From: "Deen, Glenn" <[email-masked]>
Date: Mon, 16 Nov 2020 22:20:46 +0000

On 11/16/20, 1:32 AM, "Add on behalf of Stephane Bortzmeyer" <[email-masked] on behalf of [email-masked]> wrote:

    Another case where it doesn't work is when the same entity offers
    different services (one lying and one not, for instance), which is
    common among public resolvers <https://urldefense.com/v3/__https://quad9.net/faq/__;!!PIZeeW5wscynRQ!4CvDk5WBd186D8mt1jVvYx8Oy3887z4KgGdC1lyZyFRhRKPEOOCN8fcFvalvqtHp$ >
    <https://urldefense.com/v3/__https://dns.yandex.com/__;!!PIZeeW5wscynRQ!4CvDk5WBd186D8mt1jVvYx8Oy3887z4KgGdC1lyZyFRhRKPEOOCN8fcFvbdTkNjq$ >
    <https://urldefense.com/v3/__https://blog.cloudflare.com/introducing-1-1-1-1-for-families/__;!!PIZeeW5wscynRQ!4CvDk5WBd186D8mt1jVvYx8Oy3887z4KgGdC1lyZyFRhRKPEOOCN8fcFvZi2z6wS$ >, etc

From the user's point of view - which is always a priority - the goal is to meet the user's expectation that the "upgraded" DoH/DoT resolver will continue to give the same service that the Do53 did for the user, with the addition that the communication with the server is now encrypted.

-glenn

---

From: tirumal reddy <[email-masked]>
Date: Tue, 17 Nov 2020 12:15:06 +0700

> intention to upgrade to server B, and stop using server B if server A stops

Yes, an attacker may not be alway on-path. TOFU can also help to identify
an non-zero day attacker modifying the responses to server A.

-Tiru

>> If we assume that either Do53 discovery was perfectly secure, OR that
>> plus the Do53 resolver itself were perfectly secure, then - in the presence
>> of a Dolev-Yao attacker and any information obtained from those perfectly
>> secure sources, can we provide something that uses TLS and is reasonably
>> secure?
>>

---

From: Ben Schwartz <[email-masked]>
Date: Tue, 17 Nov 2020 16:23:59 -0500

On Mon, Nov 16, 2020 at 4:02 PM Ben Schwartz <[email-masked]> wrote:
...

> I posit that any persistent attacker who can answer queries sent to server
> A is indistinguishable from server A.  This suggests a possible solution to
> the local network use case: ask the client to regularly revalidate server
> A's intention to upgrade to server B, and stop using server B if server A
> stops recommending it.
>

I've taken the liberty of turning this into a PR for DEER:
https://github.com/tfpauly/draft-pauly-adaptive-dns-privacy/pull/147.  I
believe this solves the "85%" problem securely, assuming this security
model.

---

From: Eric Orth <[email-masked]>
Date: Thu, 19 Nov 2020 04:02:18 -0500

On Tue, Nov 17, 2020 at 4:24 PM Ben Schwartz <bemasc=
[email-masked]> wrote:

>> I posit that any persistent attacker who can answer queries sent to
>> server A is indistinguishable from server A.  This suggests a possible
>> solution to the local network use case: ask the client to regularly
>> revalidate server A's intention to upgrade to server B, and stop using
>> server B if server A stops recommending it.
>>
>

Wrote a comment in the PR, but more generally:
I think there's an important distinction in this security model. An
attacker is only indistinguishable from server A if it can answer *all*
queries sent to server A.  In the case of local forwarders, if only some
queries are forwarded (due to e.g. filtering, local-only names, split
horizon, etc) to server B, then relying on the ability for 1 name to
indicate equivalence or acceptance of upgrade could result in server B
receiving those names that previously would have only been sent to server
A.  This has issues both with user expectations and security.

---

From: Ben Schwartz <[email-masked]>
Date: Thu, 19 Nov 2020 11:26:32 -0500

On Thu, Nov 19, 2020 at 4:02 AM Eric Orth <ericorth=
[email-masked]> wrote:

> queries sent to server A.
>

Yes, I meant to describe the behavior of an attacker in the local network,
between the client and the Unencrypted Resolver.

> In the case of local forwarders, if only some queries are forwarded (due
> to e.g. filtering, local-only names, split horizon, etc) to server B, then
> relying on the ability for 1 name to indicate equivalence or acceptance of
> upgrade could result in server B receiving those names that previously
> would have only been sent to server A.  This has issues both with user
> expectations and security.
>

I think this is an important point and worthy of discussion.  As I noted in
the PR, the behavior I'm describing would be similar to Mozilla's canary
domain ("use-application-dns.net").  With over two years' deployment
experience, I think it's clear that the canary domain approach has been
working well, and represents our best path forward.

One subtlety about the canary domain is that Mozilla has also implemented
fallback-on-NXDOMAIN, which provides seamless support for non-canary-aware
split-horizon forwarders.  We could employ the same approach here, if we
think that the compatibility benefits outweigh the privacy loss.

Forwarders that want to prevent queries from leaking upstream just have to
block the canary domain.  We can provide plenty of lead time to allow those
updates to happen before clients are deployed.