Subject: Re: [Add] ADD WG Github

From: Vittorio Bertola <[email-masked]>
Date: Tue, 1 Sep 2020 10:58:14 +0200 (CEST)

>     Il 21/08/2020 19:58 Chris Box (BT) <[email-masked]> ha scritto:
>      
>      
> 
> 
>         > > 
> >          
> > 
> >         BTW – I believe Chris Box is looking for additional contributors to the requirements doc.
> > 
> >          
> > 
> >     >      
>     Indeed I am, and also looking for feedback on whether this is a suitable structure to articulate the initial set of requirements.
>      
>     Direct links:
>      
>     https://ietf-wg-add.github.io/draft-add-requirements/draft-add-requirements.html
>     https://ietf-wg-add.github.io/draft-add-requirements/draft-add-requirements.txt
>     https://github.com/ietf-wg-add/draft-add-requirements
>      
>     Hoping to hear your suggestions on the list, the repo, or via any other means.
> 
Thanks for starting this work. I confess I am a bit lost between github, datatracker and multiple but similar drafts, so I reviewed the text at the first link above - here are my notes.

Section 3

R1.2: I think you mean "the IP address of the unencrypted resolver".

Section 3.1

I think that (after the bullet list) you should also mention another advantage in a different direction:

"For clients that prefer or only support encrypted DNS communication, discovering and using a network-provided encrypted resolver enables access to local DNS-based services, policies and security features that would not be available through remote encrypted resolvers."

(not sure if we should define "local" and "remote" and/or if we need to add a specific terminology/definitions section somewhere, in addition to a reference to the terminology RFCs, which by the way also seems to be missing)

In terms of turning this into a requirement, there are two options:

- if we only want to be able to discover the network-provided encrypted resolver when we already know the network-provided unencrypted resolver's IP address, then we are already covered by R1.x: once you have a discovery mechanism that works with any IP address including private ones, you also have a discovery mechanism that works with network-provisioned resolvers;

- however, it would be possible (at least until we conclude that it is not) to address the problem more generally in a single step, rather than first getting the unencrypted resolver's IP address via DHCP etc and then convert it into an encrypted resolver; in this case, the requirement could be:

"R2.1 There must [should?] be a mechanism for a client to learn the URI template (for DoH) or IP address and port (for DoT) of one or more encrypted resolvers provided by the local network, even if the network-provided unencrypted resolver is unknown."

Optionally, another requirement could be to let the client learn who is actually running the network, either in some machine-readable form or in human form (like the information in EV certificates for websites). This has been suggested a number of times; however, others have said that displaying EV information has not proven to be very useful, so I don't know if we want to go this way.

Section 3.1.1/3.1.2

I don't know which additional requirements you can add here, except for "the mechanisms above must work in this case". Same applies to most of the following x.y.z sections.

Section 4.2

The first bullet point of the list does not look like a benefit of "using a content-provider's encrypted resolver", it looks like a benefit of using any encrypted resolver. Actually, even if the client uses a local unencrypted resolver then devices along the path to the content provider cannot observe client DNS messages.

(I think the problem here is that, differently from previous use cases, this is entirely new - there is no common usage of a "content-provider's unencrypted resolver" - so it is unclear which case you are comparing this to when you mention "benefits".)

Section 5

I think that the document should acknowledge that the initial set of "attacker goals" is not an "iff", i.e. an attacker may have those goals, but there are other actors that for legitimate reasons, sometimes even in the interest of the user, may have the same goals. This is actually the root cause for why this is so difficult.

Consequently, whether the second bullet list makes sense depends on how you interpret it. If you say "an attacker must not be able to..." I think we all agree, but if you imply that anyone trying to do those things is an attacker, then I don't think we have consensus on that. For example, I guess that the corporate security people definitely want to interfere with the user's resolver preferences.

Last paragraph: what if someone imagines a discovery mechanism that only works with a subset of encrypted resolvers, i.e. only with the content providers' ones, or only with the local ones? Would this break the prescription here? (it is not actually clear whether this is a prescription, i.e. another requirement, or not) Perhaps the requirement should be weaker, i.e. make sure that at least one general discovery mechanism is available but (as an addition after that general mechanism is standardized) not prevent more specialized discovery mechanisms.

Section 5.1

I am quite puzzled by this section - perhaps I am missing the point, or misunderstanding what you mean by "opportunistic encryption". At first sight, the text looks like a self-fulfilling prophecy: since you defined the security requirements in the previous section in that way, opportunistic security becomes impossible. Also, I'm not sure of what you mean by "when the client cannot authenticate the entity that provides encrypted DNS"; if your objective is to upgrade your existing unencrypted resolver because you just discovered that it also supports encrypted transport, you only need to be sure that the unencrypted and encrypted resolver are run by the same entity.

I think that many here want to do opportunistic DNS encryption at least as an initial step, so we should first of all agree whether we want to rule it out or not. If this is ruled out, some people may lose interest in this work and try to address their problem in other ways.

Also, claiming that "Performing opportunistic encrypted DNS does not require specific discovery mechanisms" is a half-truth. Sure, you can possibly do opportunistic DoT, but you cannot do opportunistic DoH, so DoH-only clients (like, basically, any browser that has currently implemented encrypted DNS) cannot do encrypted DNS opportunistically.

Section 5.2

I don't have a problem with the content, but I thought we would not prescribe anything to clients. In any case, perhaps we should be ambitious and include as a requirement (or perhaps as a "nice to have" if we can) a way for networks and resolvers to signal what's happening and why some things don't work as expected. This has been mentioned a number of times already - I don't think we concluded whether we want to work on it or not.

In the end, I think that we still have some points of disagreement where we need to come to a solution that fits everyone's use cases - this work is very useful to bring them out so that we can discuss them one at a time.

--

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

---

From: "Chris Box (BT)" <[email-masked]>
Date: Tue, 1 Sep 2020 11:38:10 +0100

Vittorio,

It's good to have all this feedback, and I'm sure this will improve the
text, although I find it a lot to take in at one time!

The draft you read on github-pages is actually not the master branch; not
sure why that is the case. It's a branch that is proposed to be merged in a
pull request (https://github.com/ietf-wg-add/draft-add-requirements/pull/2).

I'm trying to work on completion of this PR this week, and then publishing
to datatracker. Following that I think we will find it easiest to discuss
different parts of the text by using "Issue Discussion Mode" of RFC8874:
https://tools.ietf.org/html/rfc8874#section-5.3

This means anyone can start a new issue on github that focuses on one
specific topic, and discussion will be localised there so you don't have to
wade through other topics at the same time. This doesn't remove the need to
also consult the mailing list, but reduces the volume on the list.

Formally we need the chairs to determine WG consensus on which mode we'll
work in, so if anyone has a view on the best mode please say.

Chris

On Tue, 1 Sep 2020 at 09:58, Vittorio Bertola <
[email-masked]> wrote:

> Indeed I am, and also looking for feedback on whether this is a suitable
> structure to articulate the initial set of requirements.
>
> Direct links:
>
>
> Thanks for starting this work. I confess I am a bit lost between github,
> datatracker and multiple but similar drafts, so I reviewed the text at the
> first link above - here are my notes.
>
> Section 3
>
> "For clients that prefer or only support encrypted DNS communication,
> discovering and using a network-provided encrypted resolver enables access
> to local DNS-based services, policies and security features that would not
> be available through remote encrypted resolvers."
>
> (not sure if we should define "local" and "remote" and/or if we need to
> add a specific terminology/definitions section somewhere, in addition to a
> reference to the terminology RFCs, which by the way also seems to be
> missing)
>
> - if we only want to be able to discover the network-provided encrypted
> resolver when we already know the network-provided unencrypted resolver's
> IP address, then we are already covered by R1.x: once you have a discovery
> mechanism that works with any IP address including private ones, you also
> have a discovery mechanism that works with network-provisioned resolvers;
>
> - however, it would be possible (at least until we conclude that it is
> not) to address the problem more generally in a single step, rather than
> first getting the unencrypted resolver's IP address via DHCP etc and then
> convert it into an encrypted resolver; in this case, the requirement could
> be:
>
> "R2.1 There must [should?] be a mechanism for a client to learn the URI
> template (for DoH) or IP address and port (for DoT) of one or more
> encrypted resolvers provided by the local network, even if the
> network-provided unencrypted resolver is unknown."
>
> Optionally, another requirement could be to let the client learn who is
> actually running the network, either in some machine-readable form or in
> human form (like the information in EV certificates for websites). This has
> been suggested a number of times; however, others have said that displaying
> EV information has not proven to be very useful, so I don't know if we want
> to go this way.
>
> Section 3.1.1/3.1.2
>
> I don't know which additional requirements you can add here, except for
> "the mechanisms above must work in this case". Same applies to most of the
> following x.y.z sections.
>
> Section 4.2
>
> The first bullet point of the list does not look like a benefit of "using
> a content-provider's encrypted resolver", it looks like a benefit of using
> any encrypted resolver. Actually, even if the client uses a local
> unencrypted resolver then devices along the path to the content provider
> cannot observe client DNS messages.
>
> (I think the problem here is that, differently from previous use cases,
> this is entirely new - there is no common usage of a "content-provider's
> unencrypted resolver" - so it is unclear which case you are comparing this
> to when you mention "benefits".)
>
> Section 5
>
> I think that the document should acknowledge that the initial set of
> "attacker goals" is not an "iff", i.e. an attacker may have those goals,
> but there are other actors that for legitimate reasons, sometimes even in
> the interest of the user, may have the same goals. This is actually the
> root cause for why this is so difficult.
>
> Consequently, whether the second bullet list makes sense depends on how
> you interpret it. If you say "an attacker must not be able to..." I think
> we all agree, but if you imply that anyone trying to do those things is an
> attacker, then I don't think we have consensus on that. For example, I
> guess that the corporate security people definitely want to interfere with
> the user's resolver preferences.
>
> Last paragraph: what if someone imagines a discovery mechanism that only
> works with a subset of encrypted resolvers, i.e. only with the content
> providers' ones, or only with the local ones? Would this break the
> prescription here? (it is not actually clear whether this is a
> prescription, i.e. another requirement, or not) Perhaps the requirement
> should be weaker, i.e. make sure that at least one general discovery
> mechanism is available but (as an addition after that general mechanism is
> standardized) not prevent more specialized discovery mechanisms.
>
> Section 5.1
>
> I am quite puzzled by this section - perhaps I am missing the point, or
> misunderstanding what you mean by "opportunistic encryption". At first
> sight, the text looks like a self-fulfilling prophecy: since you defined
> the security requirements in the previous section in that way,
> opportunistic security becomes impossible. Also, I'm not sure of what you
> mean by "when the client cannot authenticate the entity that provides
> encrypted DNS"; if your objective is to upgrade your existing unencrypted
> resolver because you just discovered that it also supports encrypted
> transport, you only need to be sure that the unencrypted and encrypted
> resolver are run by the same entity.
>
> I think that many here want to do opportunistic DNS encryption at least as
> an initial step, so we should first of all agree whether we want to rule it
> out or not. If this is ruled out, some people may lose interest in this
> work and try to address their problem in other ways.
>
> Also, claiming that "Performing opportunistic encrypted DNS does not
> require specific discovery mechanisms" is a half-truth. Sure, you can
> possibly do opportunistic DoT, but you cannot do opportunistic DoH, so
> DoH-only clients (like, basically, any browser that has currently
> implemented encrypted DNS) cannot do encrypted DNS opportunistically.
>
> Section 5.2
>
> I don't have a problem with the content, but I thought we would not
> prescribe anything to clients. In any case, perhaps we should be ambitious
> and include as a requirement (or perhaps as a "nice to have" if we can) a
> way for networks and resolvers to signal what's happening and why some
> things don't work as expected. This has been mentioned a number of times
> already - I don't think we concluded whether we want to work on it or not.
>
>
> In the end, I think that we still have some points of disagreement where
> we need to come to a solution that fits everyone's use cases - this work is
> very useful to bring them out so that we can discuss them one at a time.
>
> --
>
> [email-masked]

---

From: tirumal reddy <[email-masked]>
Date: Tue, 1 Sep 2020 16:40:31 +0530

Hi Eric,

Please see inline

On Fri, 28 Aug 2020 at 19:08, Eric Rescorla <[email-masked]> wrote:

>
>
> On Fri, Aug 28, 2020 at 12:35 AM tirumal reddy <[email-masked]> wrote:
>
>> On Thu, 27 Aug 2020 at 18:46, Eric Rescorla <[email-masked]> wrote:
>>
>>>
>>>
>>> On Wed, Aug 26, 2020 at 10:15 PM tirumal reddy <[email-masked]>
>>> wrote:
>>>
>>>> Hi Eric,
>>>>
>>>> Please see inline
>>>>
>>>> On Wed, 26 Aug 2020 at 16:50, Eric Rescorla <[email-masked]> wrote:
>>>>
>>>>>
>>>>>
>>>>> On Wed, Aug 26, 2020 at 3:10 AM tirumal reddy <[email-masked]>
>>>>> wrote:
>>>>>
>>>>>>
>>>>>>
>>>>>> On Tue, 25 Aug 2020 at 20:19, Christopher Wood <[email-masked]>
>>>>>> wrote:
>>>>>>
>>>>>>> Thanks for the review! Please see inline below.
>>>>>>>
>>>>>>> On Sat, Aug 22, 2020, at 2:07 PM, Eric Rescorla wrote:
>>>>>>> > Document: draft-pauly-add-requirements-00.txt
>>>>>>> >
>>>>>>> > Tommy,
>>>>>>> >
>>>>>>> > Thanks for posting this. Two comments on the threat model,
>>>>>>> > requirements, and what mechanisms it leaves in scope. The points
>>>>>>> > below are primarily about local discovery.
>>>>>>> >
>>>>>>> >
>>>>>>> > 1. In S 4, you say you are assuming an RFC 3552 threat model that
>>>>>>> > includes on-path active attackers. However, in S 2.1 you indicate
>>>>>>> that
>>>>>>> > one of the benefits of this type of mechanism is to authenticate
>>>>>>> data
>>>>>>> > coming from the true resolver:
>>>>>>> >
>>>>>>> >    *  Verify that answers come from the selected DNS resolver
>>>>>>> >
>>>>>>> >    *  Authenticate that the DNS resolver is the one provisioned by
>>>>>>> the
>>>>>>> >       network
>>>>>>> >
>>>>>>> > As a side note, I would observe that these benefits derive from the
>>>>>>> > use of an authenticated channel, not from an encrypted channel.
>>>>>>> This
>>>>>>> > is sort of a nit in that modern TLS profiles discourage
>>>>>>> authentication
>>>>>>> > only, but I think it's still worth getting right.
>>>>>>>
>>>>>>> Agreed. Use of “encrypted” was referring to the use of authenticated
>>>>>>> DoH and DoT, but I can see how that’s confusing given that we later mention
>>>>>>> opportunistic encryption (as a contrasting approach).
>>>>>>>
>>>>>>> > More importantly, this is only really true if either (1) the client
>>>>>>> > can accurately determine the nonexistence of a secure resolver or
>>>>>>> (2)
>>>>>>> > the client somehow behaves meaningfully differently in cases where
>>>>>>> > it determines that there is no secure resolver. To lay this out in
>>>>>>> > more detail, assuming that it's possible to determine the identity
>>>>>>> > of a secure resolver if one is present (e.g., by the kind of SPAU
>>>>>>> > mechanism that Chrome uses), then there are three cases:
>>>>>>> >
>>>>>>> > 1. The client connects to a secure resolver
>>>>>>> > 2. No authenticated resolver is present
>>>>>>> > 3. There is an attack
>>>>>>> >
>>>>>>> > While it's straightforward to determine whether one is in case (1),
>>>>>>> > many users will be in case (2) and so as long as the client treats
>>>>>>> > (1), (2), and (3) identically, then this doesn't preclude attack by
>>>>>>> > on-path attackers. Thisisn't a new observation, of course, but I
>>>>>>> think
>>>>>>> > it points to the need to sharpen the requirements and potentially
>>>>>>> > S 4.2 if they are to be useful in the face of the threat model
>>>>>>> > you define.
>>>>>>>
>>>>>>> That’s a good point to raise. If clients don’t treat (3) and (2)
>>>>>>> differently, then the attacker can always win. And right now, given the
>>>>>>> threat model, it’s unclear *if* a client can differentiate between these
>>>>>>> cases. Or to put it differently (and I think this was how you phrased it
>>>>>>> once in the past): the client can’t distinguish between a network with no
>>>>>>> authenticated resolver and an active attack.
>>>>>>>
>>>>>>> Perhaps we need to relax the attacker’s capabilities here? If DoH is
>>>>>>> blocked, then, well, what is a client left to do? Section 4.2 punts that
>>>>>>> problem to the client’s policy, which seems (to me) to be the right way to
>>>>>>> deal with this type of attack.
>>>>>>>
>>>>>>> Perhaps it’s worth clarifying that one of the motivations for these
>>>>>>> requirements (and guidance text) is to allow for incremental improvements.
>>>>>>> For example, opportunistic encrypted DNS may be better than no encryption
>>>>>>> for some clients. Although clients can’t determine if this is an attack or
>>>>>>> not, there’s arguably some benefit to it. Or put differently: the attacker
>>>>>>> may easily win for opportunistic DNS, but there may be cases where the
>>>>>>> attacker loses, and that seems like an improvement.
>>>>>>>
>>>>>>> > 2. S 4 says that attackers must not be able to:
>>>>>>> >
>>>>>>> >    *  Redirect DNS traffic to themselves.
>>>>>>> >
>>>>>>> > If we try to map this onto the various proposed mechanisms, I
>>>>>>> think it
>>>>>>> > has to be softened to say something like "Redirect secure DNS
>>>>>>> traffic
>>>>>>> > to themselves when DNS traffic would not be" (again a 3552 attacker
>>>>>>> > can say whatever they want in DHCP). I think this then precludes
>>>>>>> this
>>>>>>> > mechanism having some kind of indicator of where the secure
>>>>>>> resolver
>>>>>>> > is other than at its own IP.
>>>>>>>
>>>>>>> I think that’s right. None of the current discovery mechanisms work
>>>>>>> well for local discovery when the attacker controls the network, since none
>>>>>>> of the current signals are authenticated.
>>>>>>>
>>>>>>
>>>>>> No, it is possible for the client to defend against an on-path
>>>>>> attacker spoofing/blocking encrypted
>>>>>> DNS server discovery, see
>>>>>> https://tools.ietf.org/html/draft-btw-add-home-08#section-10
>>>>>>
>>>>>
>>>>> You describe three mechanisms. The first two seem to involve some sort
>>>>> of external configuration, and so are not of use in the generic case.
>>>>>
>>>>
>>>> No, only the first mechanism requires external configuration. Please
>>>> clarify why you think the three mechanisms are not generic ?
>>>>
>>>
>>> " Cryptographically assert the DNS server identity to identify the DNS
>>> client is connecting to an encrypted DNS server hosted by a specific
>>> organization"
>>>
>>> The client has no way of knowing what organizations are acceptable.
>>>
>>> The reason these aren't generic is that clients in general will not be
>>> so configured.
>>>
>>
>> I see the confusion, and will fix the text. The intent is to say the
>> cryptographic assertion of the DNS server identity
>> proves to the client the encrypted server is hosted by a legal
>> organization/entity. It prevents the attack scenario where
>> an attacker hosts an encrypted server and claims the best DNS privacy
>> preservation policy.
>>
>> The client can then prompt the user to decide whether the encrypted DNS
>> server hosted by a specific organization is
>> acceptable or not. The resolver information published by the DNS server
>> also includes a privacy statement URL, optional audit URL,
>> whether the DNS server performs filtering and reasons for filtering.
>>
>
> As I said when you first proposed this in an ADD meeting, I do not believe
> that anything of this kind is viable.
>

> 1. Certificates tied to a legal entity have not been effective, which is
> why browsers are removing EV.
>

The draft does not propose using EV certificates for encrypted DNS servers,
please see
https://tools.ietf.org/html/draft-reddy-add-server-policy-selection-05#section-4
for
more details.

2. There is ample evidence that users do not read privacy policies.

The DNS server privacy statement is much more simpler compared to a typical
privacy statement by a
content service provider (see
https://tools.ietf.org/html/draft-ietf-dprive-bcp-op-14#section-6).

Further, automated analysis of a privacy statement is possible using deep
learning (https://pribot.org/files/Polisis_USENIX_Security_Paper.pdf). You
can explore polisis and pritbot at https://pribot.org to explore the
analysis of privacy statements by several organizations..

>
>
>>
>>>
>>>
>>>>
>>>>> I do not believe the third, STUN-based mechanism works. The attacker
>>>>> can make the client believe that it has any external IP of its choice by
>>>>> tunnelling the STUN traffic.
>>>>>
>>>>
>>>> Yes, it may be easy for an attacker to identify STUN traffic but
>>>> challenging to identify TURN server running on port 443 (TURN-over-TLS).
>>>>
>>>
>>> Well, it will be public information (because it's embedded in many
>>> clients) where the servers are.
>>>
>>
>> Yes, good point. If many services are hosted on the same IP address, it
>> will be challenging to identify the
>> TURN-over-TLS/STUN-over-TLS session.
>>
>
> They will also have a different ALPN value.
>

Yes but ALPN and SNI can be encrypted using TLS encrypted client hello.
Anyways, the client can also use HTTPS
(similar to https://ipinfo.io/ip-company-api).

>
>
>>
>>>
>>>
>>> Further, an attacker may or may not be always on-path and the client can
>>>> remember that an encrypted resolver is provided by the attached
>>>> network (e.g., associate the domain name/organization hosting the encrypted
>>>> resolver with the SSID:BSSID). If later the endpoint cannot discover the
>>>> network-provided resolver, it can assume an attacker blocked the discovery.
>>>>
>>>
>>> Or that network conditions changed in some way or other, which might
>>> result in unacceptable numbers of false positives.
>>> In any case, this is a weaker threat model than described in the draft.
>>>
>>
>> Agreed, if the client cannot take an action at least it can notify the
>> user that it cannot discover the previously seen
>> network-provided encrypted resolver.
>>
>
> A dialog which the user will see a lot and therefore likely click through.
>

The user should only get a notification if an attacker blocks the discovery
or the home network uses a different ISP that does not host an encrypted
DNS server.

I don't get why the user would get a frequent dialog ?

Cheers,
-Tiru

>
> -Ekr
>
>
>> -Tiru
>>
>>
>>>
>>> -Ekr
>>>
>>>
>>>> -Tiru
>>>>
>>>>
>>>>>
>>>>> -Ekr
>>>>>
>>>>>
>>>>>> -Tiru
>>>>>>
>>>>>>
>>>>>>>
>>>>>>> Best,
>>>>>>> Chris
>>>>>>>
>>>>>>> --
>>>>>>> Add mailing list
>>>>>>> [email-masked]
>>>>>>> https://www.ietf.org/mailman/listinfo/add
>>>>>>>
>>>>>> --
>>>>>> Add mailing list
>>>>>> [email-masked]
>>>>>> https://www.ietf.org/mailman/listinfo/add
>>>>>>
>>>>>

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 1 Sep 2020 09:46:20 -0700

On Tue, Sep 1, 2020 at 4:10 AM tirumal reddy <[email-masked]> wrote:

>>>>>> As I said when you first proposed this in an ADD meeting, I do not
>> believe that anything of this kind is viable.
>>
>
> The draft does not propose using EV certificates for encrypted DNS
> servers, please see
> https://tools.ietf.org/html/draft-reddy-add-server-policy-selection-05#section-4 for
> more details.
>

It proposes something similar, which I expect to have the same drawbacks.

>>
>
> The DNS server privacy statement is much more simpler compared to a
> typical privacy statement by a

I don't think that makes it significantly more likely that people will read
it.

> learning (https://pribot.org/files/Polisis_USENIX_Security_Paper.pdf).
> You can explore polisis and pritbot at https://pribot.org to explore the

I took a quick look at this tool and while it appears to be interesting
work, it does not produce output which I think is likely for users to
actually assimilate. For instance here is what it does with McAfee's policy:
https://pribot.org/polisis/?company_url=mcafee.com&_id=59d8f9c4e3dd0c4e24555c1d&category=first-party-collection-use

We've already run this experiment of machine readable privacy policies once
with P3P and I don't see a reason to think this will be any different

Taking a step back here: is there any client with significant usage that
would be interested in consuming this kind of policy when published by a
resolver? If so, I'd like to hear from them about their needs. If not, it
doesn't seem worth discussing further.

-Ekr

---

From: Tommy Jensen <[email-masked]>
Date: Tue, 1 Sep 2020 17:11:25 +0000

ekr> Taking a step back here: is there any client with significant usage that would be interested in consuming this kind of policy when published by a resolver?

Speaking for myself: no. The user either understands the implications and has pre-configured a resolver of their choice, or they don't and expect DNS to just work. Until DNS server choice is an everyday user concept akin to music streaming app choice (or at least wireless network choice), that will continue to be the case.

Thanks,
Tommy

________________________________
From: Add <[email-masked]> on behalf of Eric Rescorla <[email-masked]>
Sent: Tuesday, September 1, 2020 9:46 AM
To: tirumal reddy <[email-masked]>
Cc: ADD Mailing list <[email-masked]>; Christopher Wood <[email-masked]>
Subject: [EXTERNAL] Re: [Add] ADD Requirements Draft

On Tue, Sep 1, 2020 at 4:10 AM tirumal reddy <[email-masked]<mailto:[email-masked]>> wrote:
Hi Eric,

Please see inline

On Fri, 28 Aug 2020 at 19:08, Eric Rescorla <[email-masked]<mailto:[email-masked]>> wrote:

On Fri, Aug 28, 2020 at 12:35 AM tirumal reddy <[email-masked]<mailto:[email-masked]>> wrote:
On Thu, 27 Aug 2020 at 18:46, Eric Rescorla <[email-masked]<mailto:[email-masked]>> wrote:

On Wed, Aug 26, 2020 at 10:15 PM tirumal reddy <[email-masked]<mailto:[email-masked]>> wrote:
Hi Eric,

Please see inline

On Wed, 26 Aug 2020 at 16:50, Eric Rescorla <[email-masked]<mailto:[email-masked]>> wrote:

As I said when you first proposed this in an ADD meeting, I do not believe that anything of this kind is viable.

1. Certificates tied to a legal entity have not been effective, which is why browsers are removing EV.

The draft does not propose using EV certificates for encrypted DNS servers, please see https://tools.ietf.org/html/draft-reddy-add-server-policy-selection-05#section-4<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-reddy-add-server-policy-selection-05%23section-4&data=02%7C01%7CJensen.Thomas%40microsoft.com%7C4f39107a43f8461cc8c808d84e96ac6c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637345757215760305&sdata=zwTj9VSEumHDnBDlWRQySYQf2lljLOE7aG%2FcNJKWx%2Bk%3D&reserved=0> for more details.

The DNS server privacy statement is much more simpler compared to a typical privacy statement by a
content service provider (see https://tools.ietf.org/html/draft-ietf-dprive-bcp-op-14#section-6<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-ietf-dprive-bcp-op-14%23section-6&data=02%7C01%7CJensen.Thomas%40microsoft.com%7C4f39107a43f8461cc8c808d84e96ac6c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637345757215770297&sdata=Aon0Ne%2FXFeIqNAPGMS5g0t%2FpPaqrg9bs3OTDJzK3wn8%3D&reserved=0>).

I don't think that makes it significantly more likely that people will read it.

Further, automated analysis of a privacy statement is possible using deep learning (https://pribot.org/files/Polisis_USENIX_Security_Paper.pdf<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpribot.org%2Ffiles%2FPolisis_USENIX_Security_Paper.pdf&data=02%7C01%7CJensen.Thomas%40microsoft.com%7C4f39107a43f8461cc8c808d84e96ac6c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637345757215770297&sdata=btIZBlgmsG2b9zCE6pSjQt7q%2FteV6HVT8fakqd08sWQ%3D&reserved=0>). You can explore polisis and pritbot at https://pribot.org<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpribot.org%2F&data=02%7C01%7CJensen.Thomas%40microsoft.com%7C4f39107a43f8461cc8c808d84e96ac6c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637345757215780290&sdata=DluH1rTl9DL%2Blcmt0nb5jhy9H6i1QyJwGJhBkT3x%2FoM%3D&reserved=0> to explore the analysis of privacy statements by several organizations..

I took a quick look at this tool and while it appears to be interesting work, it does not produce output which I think is likely for users to actually assimilate. For instance here is what it does with McAfee's policy:
https://pribot.org/polisis/?company_url=mcafee.com&_id=59d8f9c4e3dd0c4e24555c1d&category=first-party-collection-use<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpribot.org%2Fpolisis%2F%3Fcompany_url%3Dmcafee.com%26_id%3D59d8f9c4e3dd0c4e24555c1d%26category%3Dfirst-party-collection-use&data=02%7C01%7CJensen.Thomas%40microsoft.com%7C4f39107a43f8461cc8c808d84e96ac6c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637345757215780290&sdata=gL%2BUOJ3dykOrd316WbZH5HpswalaWAKHscWQspcHM7w%3D&reserved=0>

We've already run this experiment of machine readable privacy policies once with P3P and I don't see a reason to think this will be any different

Taking a step back here: is there any client with significant usage that would be interested in consuming this kind of policy when published by a resolver? If so, I'd like to hear from them about their needs. If not, it doesn't seem worth discussing further.

-Ekr

---

From: Tommy Pauly <[email-masked]>
Date: Tue, 01 Sep 2020 12:57:28 -0700

Agreed. From my perspective as a client vendor, I don’t see a likely path to consuming this kind of policy. This is one of the reasons I’ve argued that we should have in our requirements a limitation that the entity that provides DNS should be one that the client already has a relationship with—we don’t need any new explanation of policy, we’re relying on existing relationships.

Thanks,
Tommy (Pauly)

> On Sep 1, 2020, at 10:11 AM, Tommy Jensen <Jensen.Thomas=[email-masked]> wrote:
> 
> From: Add <[email-masked] <mailto:[email-masked]>> on behalf of Eric Rescorla <[email-masked] <mailto:[email-masked]>>
> To: tirumal reddy <[email-masked] <mailto:[email-masked]>>
> Cc: ADD Mailing list <[email-masked] <mailto:[email-masked]>>; Christopher Wood <[email-masked] <mailto:[email-masked]>>
> On Tue, Sep 1, 2020 at 4:10 AM tirumal reddy <[email-masked] <mailto:[email-masked]>> wrote:
> Hi Eric,
> 
> Please see inline
> 
> On Fri, 28 Aug 2020 at 19:08, Eric Rescorla <[email-masked] <mailto:[email-masked]>> wrote:
> 
> 
> On Fri, Aug 28, 2020 at 12:35 AM tirumal reddy <[email-masked] <mailto:[email-masked]>> wrote:
> On Thu, 27 Aug 2020 at 18:46, Eric Rescorla <[email-masked] <mailto:[email-masked]>> wrote:
> 
> 
> On Wed, Aug 26, 2020 at 10:15 PM tirumal reddy <[email-masked] <mailto:[email-masked]>> wrote:
> Hi Eric,
> 
> Please see inline
> 
> On Wed, 26 Aug 2020 at 16:50, Eric Rescorla <[email-masked] <mailto:[email-masked]>> wrote:
> 
> 
> The draft does not propose using EV certificates for encrypted DNS servers, please see https://tools.ietf.org/html/draft-reddy-add-server-policy-selection-05#section-4 <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-reddy-add-server-policy-selection-05%23section-4&data=02%7C01%7CJensen.Thomas%40microsoft.com%7C4f39107a43f8461cc8c808d84e96ac6c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637345757215760305&sdata=zwTj9VSEumHDnBDlWRQySYQf2lljLOE7aG%2FcNJKWx%2Bk%3D&reserved=0> for more details. 
> 
> content service provider (see https://tools.ietf.org/html/draft-ietf-dprive-bcp-op-14#section-6 <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-ietf-dprive-bcp-op-14%23section-6&data=02%7C01%7CJensen.Thomas%40microsoft.com%7C4f39107a43f8461cc8c808d84e96ac6c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637345757215770297&sdata=Aon0Ne%2FXFeIqNAPGMS5g0t%2FpPaqrg9bs3OTDJzK3wn8%3D&reserved=0>). 
> 
> Further, automated analysis of a privacy statement is possible using deep learning (https://pribot.org/files/Polisis_USENIX_Security_Paper.pdf <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpribot.org%2Ffiles%2FPolisis_USENIX_Security_Paper.pdf&data=02%7C01%7CJensen.Thomas%40microsoft.com%7C4f39107a43f8461cc8c808d84e96ac6c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637345757215770297&sdata=btIZBlgmsG2b9zCE6pSjQt7q%2FteV6HVT8fakqd08sWQ%3D&reserved=0>). You can explore polisis and pritbot at https://pribot.org <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpribot.org%2F&data=02%7C01%7CJensen.Thomas%40microsoft.com%7C4f39107a43f8461cc8c808d84e96ac6c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637345757215780290&sdata=DluH1rTl9DL%2Blcmt0nb5jhy9H6i1QyJwGJhBkT3x%2FoM%3D&reserved=0> to explore the analysis of privacy statements by several organizations.. 
> 
> https://pribot.org/polisis/?company_url=mcafee.com&_id=59d8f9c4e3dd0c4e24555c1d&category=first-party-collection-use <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpribot.org%2Fpolisis%2F%3Fcompany_url%3Dmcafee.com%26_id%3D59d8f9c4e3dd0c4e24555c1d%26category%3Dfirst-party-collection-use&data=02%7C01%7CJensen.Thomas%40microsoft.com%7C4f39107a43f8461cc8c808d84e96ac6c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637345757215780290&sdata=gL%2BUOJ3dykOrd316WbZH5HpswalaWAKHscWQspcHM7w%3D&reserved=0>
> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/add <https://www.ietf.org/mailman/listinfo/add>

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 1 Sep 2020 13:00:34 -0700

In case it wasn't clear, I don't believe that we (Firefox) would want this
either.

-Ekr

On Tue, Sep 1, 2020 at 12:57 PM Tommy Pauly <[email-masked]> wrote:

> Agreed. From my perspective as a client vendor, I don’t see a likely path
> to consuming this kind of policy. This is one of the reasons I’ve argued
> that we should have in our requirements a limitation that the entity that
> provides DNS should be one that the client already has a relationship
> with—we don’t need any new explanation of policy, we’re relying on existing
> relationships.
>
> Thanks,
> Tommy (Pauly)
>
> On Sep 1, 2020, at 10:11 AM, Tommy Jensen <
> Jensen.Thomas=[email-masked]> wrote:
>
> ekr> Taking a step back here: is there any client with significant usage
> that would be interested in consuming this kind of policy when published by
> a resolver?
>
> Speaking for myself: no. The user either understands the implications and
> has pre-configured a resolver of their choice, or they don't and expect DNS
> to just work. Until DNS server choice is an everyday user concept akin to
> music streaming app choice (or at least wireless network choice), that will
> continue to be the case.
>
> Thanks,
> Tommy
>
> ------------------------------
> *From:* Add <[email-masked]> on behalf of Eric Rescorla <
> [email-masked]>
> *Sent:* Tuesday, September 1, 2020 9:46 AM
> *To:* tirumal reddy <[email-masked]>
> *Cc:* ADD Mailing list <[email-masked]>; Christopher Wood <
> [email-masked]>
> *Subject:* [EXTERNAL] Re: [Add] ADD Requirements Draft
>
>
>
> On Wed, Aug 26, 2020 at 10:15 PM tirumal reddy <[email-masked]> wrote:
>
> Hi Eric,
>
> Please see inline
>
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-reddy-add-server-policy-selection-05%23section-4&data=02%7C01%7CJensen.Thomas%40microsoft.com%7C4f39107a43f8461cc8c808d84e96ac6c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637345757215760305&sdata=zwTj9VSEumHDnBDlWRQySYQf2lljLOE7aG%2FcNJKWx%2Bk%3D&reserved=0> for
> more details.
>
>
> https://tools.ietf.org/html/draft-ietf-dprive-bcp-op-14#section-6
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-ietf-dprive-bcp-op-14%23section-6&data=02%7C01%7CJensen.Thomas%40microsoft.com%7C4f39107a43f8461cc8c808d84e96ac6c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637345757215770297&sdata=Aon0Ne%2FXFeIqNAPGMS5g0t%2FpPaqrg9bs3OTDJzK3wn8%3D&reserved=0>
> ).
>
>
> learning (https://pribot.org/files/Polisis_USENIX_Security_Paper.pdf
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpribot.org%2Ffiles%2FPolisis_USENIX_Security_Paper.pdf&data=02%7C01%7CJensen.Thomas%40microsoft.com%7C4f39107a43f8461cc8c808d84e96ac6c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637345757215770297&sdata=btIZBlgmsG2b9zCE6pSjQt7q%2FteV6HVT8fakqd08sWQ%3D&reserved=0>).
> You can explore polisis and pritbot at https://pribot.org
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpribot.org%2F&data=02%7C01%7CJensen.Thomas%40microsoft.com%7C4f39107a43f8461cc8c808d84e96ac6c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637345757215780290&sdata=DluH1rTl9DL%2Blcmt0nb5jhy9H6i1QyJwGJhBkT3x%2FoM%3D&reserved=0> to
> explore the analysis of privacy statements by several organizations..
>
>
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpribot.org%2Fpolisis%2F%3Fcompany_url%3Dmcafee.com%26_id%3D59d8f9c4e3dd0c4e24555c1d%26category%3Dfirst-party-collection-use&data=02%7C01%7CJensen.Thomas%40microsoft.com%7C4f39107a43f8461cc8c808d84e96ac6c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637345757215780290&sdata=gL%2BUOJ3dykOrd316WbZH5HpswalaWAKHscWQspcHM7w%3D&reserved=0>
>
> We've already run this experiment of machine readable privacy policies
> once with P3P and I don't see a reason to think this will be any different
>

---

From: Andrew Campling <[email-masked]>
Date: Tue, 1 Sep 2020 22:01:00 +0000

Tommy Pauly
That seems reasonable for a same provider auto upgrade-type scenario.  To look at it from the other perspective, if the client wants to change the DNS from the one that the client already has a relationship with then an explanation of policy is required together with user assent (possibly even indirect user assent in some cases, eg enterprise, parent etc, to borrow terminology from RFC 8890).

Andrew

From: Tommy Pauly <[email-masked]>
Sent: 01 September 2020 20:57
To: Tommy Jensen <Jensen.Thomas=[email-masked]>
Cc: Eric Rescorla <[email-masked]>; tirumal reddy <[email-masked]>; ADD Mailing list <[email-masked]>; Christopher Wood <[email-masked]>
Subject: Re: [Add] [EXTERNAL] Re: ADD Requirements Draft

Thanks,
Tommy (Pauly)

On Sep 1, 2020, at 10:11 AM, Tommy Jensen <Jensen.Thomas=[email-masked]<mailto:Jensen.Thomas=[email-masked]>> wrote:

Thanks,
Tommy

________________________________
From: Add <[email-masked]<mailto:[email-masked]>> on behalf of Eric Rescorla <[email-masked]<mailto:[email-masked]>>
Sent: Tuesday, September 1, 2020 9:46 AM
To: tirumal reddy <[email-masked]<mailto:[email-masked]>>
Cc: ADD Mailing list <[email-masked]<mailto:[email-masked]>>; Christopher Wood <[email-masked]<mailto:[email-masked]>>
Subject: [EXTERNAL] Re: [Add] ADD Requirements Draft

Please see inline

Please see inline

-Ekr

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

---

From: tirumal reddy <[email-masked]>
Date: Wed, 2 Sep 2020 18:01:59 +0530

Please see inline

> It proposes something similar, which I expect to have the same drawbacks.

Can you please explain the drawbacks for further discussion ?

> I don't think that makes it significantly more likely that people will

It varies from person to person. People may not read the privacy statements
because they visit several domains in a day. The DNS operators a user will
use will be very few, for example an user may want to use a
discovered resolver in selected networks like Enterprise or Home network.
Further, encrypted DNS resolver publishing the privacy statement URL is a
best practise similar to the way OS mandating apps to publish privacy
policy.

> https://pribot.org/polisis/?company_url=mcafee.com&_id=59d8f9c4e3dd0c4e24555c1d&category=first-party-collection-use

The summary page is quite easy for end users to review the
positives/negatives to watch out for and it also highlights the relevant
text in a large privacy document (see
https://pribot.org/polisis/?company_url=http%3A%2F%2Fmcafee.com&_id=59d8f9c4e3dd0c4e24555c1d&category=assessment).
The DNS server privacy statement is much more simpler compared to a typical
privacy statement for deep learning to identify if the server is
privacy-friendly.

> once with P3P and I don't see a reason to think this will be any different

No, the draft does not discuss any machine readable privacy policies other
than conveying the privacy statement URL.

> doesn't seem worth discussing further.

The draft only discusses conveying resolver information and does not
discuss any machine parsable privacy policy.

-Tiru

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 2 Sep 2020 18:23:42 -0700

Tirumal,

I think this conversation has gone beyond the point where it is productive.

I do not believe that users are going to be able to meaningfully consume
either real world identity information ("This is run by company X") or
privacy policy information about resolvers. We've tried that in several
other domains and it hasn't worked, and I don't think going through why in
a lot of detail is going to illuminate the situation here. But more to the
point, I think you're hearing that client vendors aren't interested, so
standardizing this would not help. If you want to continue to propose this,
I suggest that you find some set of clients which would consume it, at
which point a discussion of the merits of this idea will be more useful.

-Ekr

On Wed, Sep 2, 2020 at 5:32 AM tirumal reddy <[email-masked]> wrote:

> It varies from person to person. People may not read the privacy
> statements because they visit several domains in a day. The DNS operators a
> user will use will be very few, for example an user may want to use a
>>> You can explore polisis and pritbot at https://pribot.org to explore
>>> the analysis of privacy statements by several organizations..
>>>
>>

---

From: Michael Richardson <[email-masked]>
Date: Wed, 02 Sep 2020 21:45:56 -0400

> which point a discussion of the merits of this idea will be more useful.

Just want to be clear here: DNS is for browsers with humans attached only?

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 2 Sep 2020 18:58:28 -0700

> Just want to be clear here: DNS is for browsers with humans attached only?

I'm not following you here. I think it would be interesting if any
significant number of clients wanted to consume a given signal.

With that said:
1. What Tirumal is proposing seems to involve signals that users would have
to consume (privacy policy, real world name of the server operator...)
2. Two of the three people who have weighed in to express non-interest work
for OS vendors who have DoH at the OS level.

-Ekr

---

From: Tommy Jensen <[email-masked]>
Date: Thu, 3 Sep 2020 02:53:45 +0000

Hey Andrew,

Wrong Tommy, but I'll point out he specifically said "entity" and not "DNS server" most likely on purpose. While we do propose an auto-upgrade approach where we can attempt a TLS-confirmed upgrade from an IP address, the designated DoH server approach can also honor the same entity control, namely the designated server is the same entity as the domain names it resolves.

I'm not convinced clients require per-server policy to be communicated as part of discovery to power DNS server selection or configuration UX.

Thanks,
Tommy

================================================

The latest in Windows Internet Protocols:

  Native gRPC support: https://aka.ms/grpcblogpost

  DNS over HTTPS: https://aka.ms/dohblogpost

________________________________
From: Andrew Campling <[email-masked]>
Sent: Tuesday, September 1, 2020 3:01 PM
To: Tommy Pauly <[email-masked]>; Tommy Jensen <[email-masked]>
Cc: Eric Rescorla <[email-masked]>; tirumal reddy <[email-masked]>; ADD Mailing list <[email-masked]>; Christopher Wood <[email-masked]>
Subject: RE: [Add] [EXTERNAL] Re: ADD Requirements Draft

Tommy Pauly

Andrew

Thanks,

Tommy (Pauly)

Thanks,

Tommy

Hi Eric,

Please see inline

Hi Eric,

Please see inline

The draft does not propose using EV certificates for encrypted DNS servers, please see https://tools.ietf.org/html/draft-reddy-add-server-policy-selection-05#section-4<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-reddy-add-server-policy-selection-05%23section-4&data=02%7C01%7CJensen.Thomas%40microsoft.com%7C01875924c4144966755c08d84ec2883b%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637345945642599005&sdata=21UUejEVCqdnvjvYuJPKKuUeEvlboJ%2FNfU6r1Xkggsg%3D&reserved=0> for more details.

content service provider (see https://tools.ietf.org/html/draft-ietf-dprive-bcp-op-14#section-6<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-ietf-dprive-bcp-op-14%23section-6&data=02%7C01%7CJensen.Thomas%40microsoft.com%7C01875924c4144966755c08d84ec2883b%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637345945642609001&sdata=lePsGAUDQmK2FvUC9CfEkzIUDxAdTgYfPaxV9koxhdg%3D&reserved=0>).

Further, automated analysis of a privacy statement is possible using deep learning (https://pribot.org/files/Polisis_USENIX_Security_Paper.pdf<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpribot.org%2Ffiles%2FPolisis_USENIX_Security_Paper.pdf&data=02%7C01%7CJensen.Thomas%40microsoft.com%7C01875924c4144966755c08d84ec2883b%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637345945642609001&sdata=DjEJhUbWRSF6o%2FhiJCKUhkrhMvBatLlMpTHUYKw2mh0%3D&reserved=0>). You can explore polisis and pritbot at https://pribot.org<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpribot.org%2F&data=02%7C01%7CJensen.Thomas%40microsoft.com%7C01875924c4144966755c08d84ec2883b%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637345945642618991&sdata=dw0kcx9WdgyjNwyKIUrpZRPJp8m3Aw%2B9jI7vaQWLupM%3D&reserved=0> to explore the analysis of privacy statements by several organizations..

https://pribot.org/polisis/?company_url=mcafee.com&_id=59d8f9c4e3dd0c4e24555c1d&category=first-party-collection-use<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpribot.org%2Fpolisis%2F%3Fcompany_url%3Dmcafee.com%26_id%3D59d8f9c4e3dd0c4e24555c1d%26category%3Dfirst-party-collection-use&data=02%7C01%7CJensen.Thomas%40microsoft.com%7C01875924c4144966755c08d84ec2883b%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637345945642618991&sdata=xLlQi%2BhQFiFxRhnoEMSVBIOjg6D0FKBMtHy2ewr%2F2YQ%3D&reserved=0>

-Ekr

--
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=02%7C01%7CJensen.Thomas%40microsoft.com%7C01875924c4144966755c08d84ec2883b%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637345945642628987&sdata=FkyePIlYLclN%2BC5DVhNqUVYfhQsLXENMCaF4BrOl9gk%3D&reserved=0>

---

From: tirumal reddy <[email-masked]>
Date: Thu, 3 Sep 2020 14:53:34 +0530

Hi Eric,

I think you have misunderstood the purpose of the draft. I would like to
clarify the intent:

1) It prevents the client from connecting to an Encrypted DNS resolver
hosted by an attacker. It is useful when the Encrypted
DNS server is insecurely discovered (e.g., using DHCP/RA, SUDN) and the
discovered encrypted
server is not pre-configured in the OS/Browser. It resembles the
Background-Check Model discussed in Sections 5.2 and 5.3 of Remote
attestation procedure (RATS) Architecture
https://tools.ietf.org/html/draft-ietf-rats-architecture-05.

2)It does not require Encrypted DNS servers to use EV certificates.
However, the verifier creating the attestation results
may or may not use EV certificates depending on whether the Encrypted DNS
server will be discovered securely
or insecurely. For example, the verifier need not use EV certificate in the
following scenarios:

a. If the Encrypted DNS server will only be discovered securely (e.g.,
using IKEv2), the verifier need not
    use an OV/EV certificate.

b. Another scenario is bootstrapping a networking device to use the
encrypted DNS server in the local network. Secure Zero Touch Provisioning
(RFC8572) defines a bootstrapping strategy for enabling devices to securely
obtain the required configuration information with no user input. If the
encrypted DNS server is insecurely discovered and not pre-configured in the
networking device, the client can validate the Policy Assertion Token
signature using the owner certificate as per Section 3.2 of RFC8572. In
this case, the owner certificate
need not be an OV/EV certificate.

3. The draft also signals resolver information like whether the resolver
performs filtering, reasons for filtering and
URL to privacy/audit statement. It does not signal any machine-parsable
privacy policy and it does not intend to replace
the privacy statement provided by a legal attorney.  It is helpful in
scenarios where the discovered resolver is not
pre-configured in the OS/Browser. It aligns with the charter of ADD to
"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."

Hopefully it clarifies for further reviews.

Cheers,
-Tiru

On Thu, 3 Sep 2020 at 06:54, Eric Rescorla <[email-masked]> wrote:

>>> Further, automated analysis of a privacy statement is possible using
>>>> deep learning (
>>>> https://pribot.org/files/Polisis_USENIX_Security_Paper.pdf). You can
>>>> explore polisis and pritbot at https://pribot.org to explore the
>> No, the draft does not discuss any machine readable privacy policies
>> other than conveying the privacy statement URL.
>>
>>
>>>

---

From: tirumal reddy <[email-masked]>
Date: Thu, 3 Sep 2020 15:40:38 +0530

> with—we don’t need any new explanation of policy, we’re relying on existing

Existing relationships are definitely useful in certain scenarios but not
in all. For example:

a) I don't think it is possible for every ISP and Enterprise network in the
world to approach each and every Browser and OS vendor to be pre-configured
with network provided encrypted DNS servers.

b) Secure discovery most likely avoids the need to have the discovered DNS
server pre-configured in OS/Browser. However, as we all know secure
discovery is not possible in some deployments. If the discovered server is
not pre-configured, client/user needs to know the resolver information of
the discovered server. In case of insecure discovery, the client should
have checks to avoid connecting to an encrypted DNS server hosted by an
attacker.

Cheers,
-Tiru

---

From: Tommy Pauly <[email-masked]>
Date: Thu, 03 Sep 2020 08:00:03 -0700

> On Sep 3, 2020, at 3:10 AM, tirumal reddy <[email-masked]> wrote:
> 
> On Wed, 2 Sep 2020 at 01:27, Tommy Pauly <[email-masked] <mailto:[email-masked]>> wrote:
> Existing relationships are definitely useful in certain scenarios but not in all. For example:
> 
> a) I don't think it is possible for every ISP and Enterprise network in the world to approach each and every Browser and OS vendor to be pre-configured with network provided encrypted DNS servers. 

It’s not about the relationship of the OS or the browser with the entities that can provide DNS services, it’s the relationship of the *user* with those entities. I do not want to have any pre-configuration for any resolver in my OS.

> 
> b) Secure discovery most likely avoids the need to have the discovered DNS server pre-configured in OS/Browser. However, as we all know secure discovery is not possible in some deployments. If the discovered server is not pre-configured, client/user needs to know the resolver information of the discovered server. In case of insecure discovery, the client should have checks to avoid connecting to an encrypted DNS server hosted by an attacker.

Secure discovery—or at least authenticated discovery over a secure channel—is indeed the right way to do things. We should be designing and standardizing mechanisms that raise the bar for security over the status quo, and ensure that we are not making avenues of attack easier.

Tommy

> 
> Cheers,
> -Tiru
>  
> 
> Thanks,
> Tommy (Pauly)
> 
>> On Sep 1, 2020, at 10:11 AM, Tommy Jensen <Jensen.Thomas=[email-masked] <mailto:Jensen.Thomas=[email-masked]>> wrote:
>>

---

From: Tommy Pauly <[email-masked]>
Date: Thu, 03 Sep 2020 08:02:11 -0700

> On Sep 3, 2020, at 2:23 AM, tirumal reddy <[email-masked]> wrote:
> 
> Hi Eric,
> 
> I think you have misunderstood the purpose of the draft. I would like to clarify the intent:
> 
> 1) It prevents the client from connecting to an Encrypted DNS resolver hosted by an attacker. It is useful when the Encrypted
> DNS server is insecurely discovered (e.g., using DHCP/RA, SUDN) and the discovered encrypted 
> server is not pre-configured in the OS/Browser. It resembles the Background-Check Model discussed in Sections 5.2 and 5.3 of Remote attestation procedure (RATS) Architecture https://tools.ietf.org/html/draft-ietf-rats-architecture-05 <https://tools.ietf.org/html/draft-ietf-rats-architecture-05>.
> 
> 2)It does not require Encrypted DNS servers to use EV certificates. However, the verifier creating the attestation results 
> may or may not use EV certificates depending on whether the Encrypted DNS server will be discovered securely
> or insecurely. For example, the verifier need not use EV certificate in the following scenarios:
> 
> a. If the Encrypted DNS server will only be discovered securely (e.g., using IKEv2), the verifier need not  
> b. Another scenario is bootstrapping a networking device to use the encrypted DNS server in the local network. Secure Zero Touch Provisioning (RFC8572) defines a bootstrapping strategy for enabling devices to securely obtain the required configuration information with no user input. If the encrypted DNS server is insecurely discovered and not pre-configured in the networking device, the client can validate the Policy Assertion Token signature using the owner certificate as per Section 3.2 of RFC8572. In this case, the owner certificate 
> 3. The draft also signals resolver information like whether the resolver performs filtering, reasons for filtering and
> URL to privacy/audit statement. It does not signal any machine-parsable privacy policy and it does not intend to replace
> the privacy statement provided by a legal attorney.  It is helpful in scenarios where the discovered resolver is not
> pre-configured in the OS/Browser. It aligns with the charter of ADD to "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."

This charter point refers, I believe, to information like applicable or private domains, provider identity, etc. I think that filtering policy and auditing statements are not in scope: "Making any recommendations about specific policies for clients or servers is out of scope.”

Thanks,
Tommy
> On Thu, 3 Sep 2020 at 06:54, Eric Rescorla <[email-masked] <mailto:[email-masked]>> wrote:
> Tirumal, 
> 
> I do not believe that users are going to be able to meaningfully consume either real world identity information ("This is run by company X") or privacy policy information about resolvers. We've tried that in several other domains and it hasn't worked, and I don't think going through why in a lot of detail is going to illuminate the situation here. But more to the point, I think you're hearing that client vendors aren't interested, so standardizing this would not help. If you want to continue to propose this, I suggest that you find some set of clients which would consume it, at which point a discussion of the merits of this idea will be more useful.
> 
> -Ekr
> 
> 
> 
> On Wed, Sep 2, 2020 at 5:32 AM tirumal reddy <[email-masked] <mailto:[email-masked]>> wrote:
> Please see inline
> 
> On Tue, 1 Sep 2020 at 22:16, Eric Rescorla <[email-masked] <mailto:[email-masked]>> wrote:
> 
> 
> The draft does not propose using EV certificates for encrypted DNS servers, please see https://tools.ietf.org/html/draft-reddy-add-server-policy-selection-05#section-4 <https://tools.ietf.org/html/draft-reddy-add-server-policy-selection-05#section-4> for more details. 
> 
> content service provider (see https://tools.ietf.org/html/draft-ietf-dprive-bcp-op-14#section-6 <https://tools.ietf.org/html/draft-ietf-dprive-bcp-op-14#section-6>). 
> 
> It varies from person to person. People may not read the privacy statements because they visit several domains in a day. The DNS operators a user will use will be very few, for example an user may want to use a discovered resolver in selected networks like Enterprise or Home network. Further, encrypted DNS resolver publishing the privacy statement URL is a best practise similar to the way OS mandating apps to publish privacy policy.
>  
> 
> 
> Further, automated analysis of a privacy statement is possible using deep learning (https://pribot.org/files/Polisis_USENIX_Security_Paper.pdf <https://pribot.org/files/Polisis_USENIX_Security_Paper.pdf>). You can explore polisis and pritbot at https://pribot.org <https://pribot.org/> to explore the analysis of privacy statements by several organizations.. 
> 
> https://pribot.org/polisis/?company_url=mcafee.com&_id=59d8f9c4e3dd0c4e24555c1d&category=first-party-collection-use <https://pribot.org/polisis/?company_url=mcafee.com&_id=59d8f9c4e3dd0c4e24555c1d&category=first-party-collection-use>
> 
> The summary page is quite easy for end users to review the positives/negatives to watch out for and it also highlights the relevant text in a large privacy document (see https://pribot.org/polisis/?company_url=http%3A%2F%2Fmcafee.com&_id=59d8f9c4e3dd0c4e24555c1d&category=assessment <https://pribot.org/polisis/?company_url=http%3A%2F%2Fmcafee.com&_id=59d8f9c4e3dd0c4e24555c1d&category=assessment>). The DNS server privacy statement is much more simpler compared to a typical privacy statement for deep learning to identify if the server is privacy-friendly. 
>  
> 
> No, the draft does not discuss any machine readable privacy policies other than conveying the privacy statement URL. 
>  
> 
> The draft only discusses conveying resolver information and does not discuss any machine parsable privacy policy.
> 
> -Tiru
>  
> 
> -Ekr
> 
> -- 
> Add mailing list
> [email-masked]

---

From: Michael Richardson <[email-masked]>
Date: Thu, 03 Sep 2020 11:28:48 -0400

Eric Rescorla <[email-masked]> wrote:
    ekr> point, I think you're hearing that client vendors aren't interested,

    mcr> Just want to be clear here: DNS is for browsers with humans attached only?

    ekr> I'm not following you here. I think it would be interesting if any
    ekr> significant number of clients wanted to consume a given signal.

    > to consume (privacy policy, real world name of the server operator...)

Yes, I'm a co-author of that document.

It involves digitally signed statements that need to be interpreted by a
digital aparatus, in which there may be signals that can be compared to a
desired policy.  Many of the policies will initially be understable by humans
only <%>, but over time the number policies (like the number of open source
license), will be reduced to a small palette, and so will be probably be
machine interpretable.   Of course, it's a independant -00.
That's my interest.

    > for OS vendors who have DoH at the OS level.

Right... non-interest does not equal objection, according to my understanding
of consensus.  These are OS vendors that support humans attached to browsers.

It seems that it is being asserted that there are no other users of DNS, and that
browser-OS vendors are the only "vote" that counts.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Michael Richardson <[email-masked]>
Date: Thu, 03 Sep 2020 11:32:42 -0400

tirumal reddy <[email-masked]> wrote:
    > URL to privacy/audit statement.

It does some of this in a machine readable way.

    > It does not signal any machine-parsable
    > the privacy statement provided by a legal attorney.

I would love it to provide a machine-parseable privacy policy, but doing so
on revision 1 would be as disastrous rathole.

We need to let the lawyers converge in the legal sphere (which the IETF is not),
and then we may wind up with a small number of typical policies which can be
indicated by reference rather than value.

    > It is helpful in

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 3 Sep 2020 09:36:19 -0700

> machine interpretable.   Of course, it's a independant -00.

Well, that might be true, but as I said, we've tried this once with P3P and
failed, so I'm skeptical.

> browser-OS vendors are the only "vote" that counts.

Not by me at least.

My position is quite simple: the IETF shouldn't standardize technology
that's not going to get deployed. In order for this technology to get
deployed, some set of clients will need to consume this signal. Do you know
of any significant sized client-side vendor or deployment of any kind who
is interested?

-Ekr

---

From: Tommy Jensen <[email-masked]>
Date: Thu, 3 Sep 2020 17:37:23 +0000

> Right... non-interest does not equal objection, according to my understanding
of consensus.

This is a fair point, though I agree with ekr that non-interest is a good way to prioritize.

To answer this, I will also state my objection. I do not want to be in the business of evaluating anything about a DNS server other than its functionality and support for a given protocol. I want to leave DNS server choice up to my users/admins, or make non-policy based decisions for the default case when I have no user input. For the record, in cases like IoT, "user input" doesn't require a connected keyboard or even direct device connection.

> These are OS vendors that support humans attached to browsers.

That's only a subset of the truth. Windows is also an IoT platform, for example. My DNS client is used by headless components throughout the OS, first- and third-party. I want to be clear on this: I'm both opposed and not interested in this proposal as an OS DNS client with the various roles that encompasses. I think configuration of trusted servers is best left to out-of-band control channels per-platform that configure other networking settings as well. I never want my DNS client to reason on its own about the value of policy on the user's behalf.

+1 to Tommy Pauly's statement on another thread: policy is beyond the scope of this WG, and that's the part I object to.

Thanks,
Tommy

________________________________
From: Add <[email-masked]> on behalf of Michael Richardson <[email-masked]>
Sent: Thursday, September 3, 2020 8:28 AM
To: ADD Mailing list <[email-masked]>
Subject: [EXTERNAL] Re: [Add] ADD Requirements Draft

---

From: Paul Vixie <[email-masked]>
Date: Thu, 3 Sep 2020 18:52:37 +0000

On Thu, Sep 03, 2020 at 05:37:23PM +0000, Tommy Jensen wrote:
> +1 to Tommy Pauly's statement on another thread: policy is beyond the scope
> of this WG, and that's the part I object to.

thanks for including this. there are too many threads for me to watch them
all, and the discussion's speed of progress outstrips my parsing capability.

i think your summary above is unfair in a hidden way. i will try to illuminate.

DoH is a bypass protocol, according to its statement of purpose, designed to
prevent on-path interference with DNS operations. this is a policy, and it is
a major shift from "my network, my rules" which was the de facto prior policy.

any discovery policy must address this policy change. of course nothing can be
enforced other than at the firewall if any. policy is at heart advisory. what
i hear MCR asking for is what i also want: a way for a firewall operator to
know that if certain flows are seen, then certain on-network devices are not
following the policy of the network. for my part, it's so i can disconnect
them. MCR's purpose may differ.

to say that policy is outside the scope of this WG is to forget that DoH is at
heart a bypass protocol, and that its availability is itself a policy matter.

i am on-path and i intend to interfere. "my network, my rules." please don't
prevent cooperating devices from learning the policy of my network, even if
you and i know that intruders, malicious insiders, malware, and poisoned
supply chains won't follow policy. i need to differentiate those devices and
users from those who do follow policy.

-- 
Paul Vixie

---

From: Tommy Pauly <[email-masked]>
Date: Thu, 03 Sep 2020 12:01:40 -0700

> On Sep 3, 2020, at 11:52 AM, Paul Vixie <[email-masked]> wrote:
> 

That’s absolutely your network’s right to interfere and block. Clients must handle such scenarios. I think we’re only saying that we don’t want to, in this group, standardize a set of protocol mechanisms to communicate such network policy about use of DNS (be that restrictions or terms & conditions or privacy statements). Trying to make protocol decisions about policy, and trying to standardize the experience that a client presents when confronted with a network that has incompatible policies from the device user or administrator policies, is what is out of scope.

Best,
Tommy

---

From: Paul Vixie <[email-masked]>
Date: Thu, 3 Sep 2020 19:38:25 +0000

On Thu, Sep 03, 2020 at 12:01:40PM -0700, Tommy Pauly wrote:
> That???s absolutely your network???s right to interfere and block. Clients
> must handle such scenarios. I think we???re only saying that we don???t want
> to, in this group, standardize a set of protocol mechanisms to communicate
> such network policy about use of DNS (be that restrictions or terms &
> conditions or privacy statements).

some in this group are saying that. others are not. let's remain specific
about that; it would be misleading to declare even by implication consensus
at this early stage.

to be clear, your restatement is not accurate, or else, you would see that
you (and whatever "we" you are referring to) don't agree with your statement
of my rights as a private network operator.

DoH _intends not to be detectible_. please base all your interpretations of
any proposal or request i make on that fundamental new fact of IETF reality.

this means my costs in detecting it will be immense, by design and intent.
those costs are precisely why i am asking for what you say you (and "we")
don't want: standardize a set of protocol mechanisms to communicate such
network policy about use of DNS. others here may be interested in terms and
conditions, or privacy statements. i am Meh to that. i want to communicate
policy about restrictions.

> Trying to make protocol decisions about policy, and trying to standardize the
> experience that a client presents when confronted with a network that has
> incompatible policies from the device user or administrator policies, is what
> is out of scope.

i, and some unknown-precisely set of "we", disagree with your assessment of
the scope. because we're talking about discovery of an intentional-bypass
protocol whose design intent is to disintermediate network operators, it is
absolutely in-scope for me to be able to tell which DoH speakers followed my
network's policy and which did not.

-- 
Paul Vixie

---

From: Tommy Jensen <[email-masked]>
Date: Thu, 3 Sep 2020 20:14:08 +0000

>  i want to communicate policy about restrictions.

The last time we discussed this during the 108 meeting, I pointed out this needs to be authenticated or else we as clients can't distinguish it from network attacks. I brought up this topic on the SECDISPATCH list and got a variety of answers, including "this warrants a new area" and "you should use 802.1x" and "there's some research you may want to look into".

None of these are DNS specific, and that remains my position: this problem you're describing is a subset of a larger problem we shouldn't shoe-horn into DNS protocols. If there existed a secure mechanism by which a network and client could exchange information, we could solve the captive portal problem as well as this one, not to mention any other regarding network policy.

Note that the only portion of the charter talking about this (communicating network policy to clients) restricts this to informational documents about existing mechanisms and not "defining mechanisms":

> Develop an informational document that describes mechanisms for
> clients to detect specific network environments (such as captive portal
> and split horizon) and to use that information to inform their DNS
> configuration.

Thanks,
Tommy

________________________________
From: Paul Vixie <[email-masked]>
Sent: Thursday, September 3, 2020 12:38 PM
To: Tommy Pauly <[email-masked]>
Cc: Tommy Jensen <[email-masked]>; Michael Richardson <[email-masked]>; ADD Mailing list <[email-masked]>
Subject: Re: [Add] [EXTERNAL] Re: ADD Requirements Draft

--
Paul Vixie

---

From: Tommy Jensen <[email-masked]>
Date: Thu, 3 Sep 2020 20:23:00 +0000

I just saw this; I agree with the list parsing struggle. My apologies for contributing to the problem, but a unified thread would be far too monolithic.

> please don't
> supply chains won't follow policy.

I would say nobody is preventing that. That channel has never existed. Before DoT and DoH, I as a Windows DNS client took network advertised DNS servers as a recommendation, not a requirement. If my user/admin provided one of their own, I ignored the network recommendation. DoH doesn't change that paradigm.

Introducing a way for the network to tell clients "you cannot use other DNS servers on this network" would be a novel concept. Me making a DNS connection without querying through the network resolver isn't a new thing, really. In Windows, it has always been the case that you would need endpoint management such as Group Policy or locally-executed scripts to tell clients what DNS server to use (or to tell them to default to network recommendation).

Thanks,
Tommy

________________________________
From: Add <[email-masked]> on behalf of Paul Vixie <[email-masked]>
Sent: Thursday, September 3, 2020 11:52 AM
To: Tommy Jensen <Jensen.Thomas=[email-masked]>
Cc: Michael Richardson <[email-masked]>; ADD Mailing list <[email-masked]>
Subject: Re: [Add] [EXTERNAL] Re: ADD Requirements Draft

--
Paul Vixie

--
Add mailing list
[email-masked]
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fadd&amp;data=02%7C01%7CJensen.Thomas%40microsoft.com%7C4bab55a0c1d44c9e6afa08d8503ac5fc%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637347560670622112&amp;sdata=6pl61TCzNamLjY%2BWSfKwWa06S3iCTnlpyTyu2bPj0pw%3D&amp;reserved=0

---

From: Andrew Campling <[email-masked]>
Date: Thu, 3 Sep 2020 20:38:15 +0000

On Sep 3, 2020, at 20:02, Tommy Pauly <[email-masked]>  wrote:

> That’s absolutely your network’s right to interfere and block. Clients must

> handle such scenarios. I think we’re only saying that we don’t want to, in

> this group, standardize a set of protocol mechanisms to communicate such

> network policy about use of DNS (be that restrictions or terms & conditions

> or privacy statements). Trying to make protocol decisions about policy, and

> trying to standardize the experience that a client presents when confronted

> with a network that has incompatible policies from the device user or

> administrator policies, is what is out of scope.

Answering a different question to the one asked by Paul, I know that we’ve mainly been focused on resolver discovery but there is of course the part of the charter relating to resolver selection:

"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".

So there will ultimately be a protocol mechanism to communicate information from the resolver to client, and thus possibly through the client to the user.

Andrew

---

From: Andrew Campling <[email-masked]>
Date: Thu, 3 Sep 2020 21:05:32 +0000

On Sep 3, 2020, at 03:54, Tommy Jensen <[email-masked]>  wrote:

> Wrong Tommy, but I'll point out he specifically said "entity" and not "DNS server" most
> likely on purpose. While we do propose an auto-upgrade approach where we can attempt
> a TLS-confirmed upgrade from an IP address, the designated DoH server approach can
> also honor the same entity control, namely the designated server is the same entity as the
> domain names it resolves.
>
> I'm not convinced clients require per-server policy to be communicated as part of discovery
> to power DNS server selection or configuration UX.

That's a helpful clarification.  I don't believe that simply accessing a domain name signifies a "relationship" with the host, noting that, for example, I may be using a VPN with ad blockers, cookie settings etc set to protect my privacy when using my browser.  Also, it's easy to envisage a "bad actor" (which could be an entity with commercial data gathering intent rather than any malicious intent) triggering access from my device to a domain without my knowledge.

Therefore, taking access to a domain access, if that's what you meant (?) to assert that "we don't need any new explanation of policy, we're relying on existing relationships" is a real stretch.  If a client intends to move from my DNS settings as a user (or indirect user as per RFC 8890) then I'd expect that client to seek permission before doing so.  It's hard not to interpret any different behaviour as potentially malicious and certainly not driven by the best interests of the user (counter to RFC 8890).  It may also be contrary to GDPR etc although we'd need guidance on that (IANAL).

Andrew

---

From: Ted Hardie <[email-masked]>
Date: Thu, 3 Sep 2020 14:35:00 -0700

On Thu, Sep 3, 2020 at 12:38 PM Paul Vixie <[email-masked]> wrote:

> Hi Paul,

So, over the years we have seen a host of protocols move their substrates
because the existing substrate didn't have the right characteristics or
didn't work any more.  QUIC runs on UDP because UDP is already understood
by routers and (mostly) gets through firewalls, and that choice follows the
common deployments of  SCTP, RTP, and tons of VPN protocols that might
otherwise run on IP.  Similarly, a ton of application protocols moved to
the web because it was more deployable, and part of that, again was that it
got through firewalls more consistently than anything else.   Very few
people maintain their firewalls well enough that deploying brand new
protocols is easy; while some evaluate new protocols and make considered
decisions, the baseline of "default deny" lets too many of them sit in a
benign state of rule rot for fairly long intervals.

For some of us, the UDP and TCP substrates used by the DNS don't provide
the right characteristics any more--they don't provide confidentiality
against a known, pervasive set of attackers.  Attempting to move to one
that has that characteristic has explored a number of different approaches
including DNS over TLS, DNS over DTLS, and now DoH.  DoH is getting
traction beyond the initial two because it works better in more
environments.

DoH, as a wire protocol, doesn't intend anything. But the people who are
deploying it, unsurprisingly, want it to have the characteristics that they
feel UDP and TCP lack and, simply put, they want it to work once deployed.
Re-using the web stack to make something deployable was a well-trodden path
long before DoH got there.  At least from my perspective, the detectable
alternatives that provided the desirable characteristics didn't work in
real deployments because they were blocked, and moving to something that
does work looks like a natural next step.

The new reality is, in fact, a pretty old one.  People reuse things that
work, and this change looks to me a lot like the changes that occured when
blocked ports for SMTP, POP, and IMAP pushed webmail into growth mode.  The
webmail protocols weren't nearly as good in those days, but they worked
pretty much everywhere.  And that, it turns out, can push past a lot of
other considerations.

It may be useful to see this change in that context.  We all have to deal
with a semi-ossified Internet, and it may be more valuable to see that as
the origin of these choices than other, more specific intent.

best regards,

Ted

---

From: Tommy Jensen <[email-masked]>
Date: Thu, 3 Sep 2020 21:43:34 +0000

> If a client intends to move from my DNS settings as a user (or indirect user as per RFC 8890) then I’d expect that client to seek permission before doing so.  It’s hard not to interpret any different behaviour as potentially malicious and certainly not driven by the best interests of the user (counter to RFC 8890).

I totally disagree. In most cases, the user didn't have any manual or chosen settings. They were simply using the default, which today happens to be network recommendation. I think it's a stretch to say changing that paradigm, which most users are unaware of, would automatically be malicious or not in our users' interests.

I would say your feedback is focused on the side effects of implementation details rather than standard details. I agree this (or anyone else's draft) could be implemented in a way that is detrimental to a user experience. I don't think that's the same as the standard itself being detrimental to the users, and that includes other drafts I object to on other grounds.

> It may also be contrary to GDPR etc although we’d need guidance on that (IANAL).

I think you know by now what I'll say to this :) I have yet to hear a concrete requirement based on GDPR that says anything about how DNS servers are configured, chosen, or connected to. Until such time, this is too hand wavy for any document author to act upon. Please correct me if I'm wrong. Otherwise, I'd rather avoid statements like this. Until a lawyer says otherwise, _anything_ might run afoul of any law.

Thanks,
Tommy

________________________________
From: Andrew Campling <[email-masked]>
Sent: Thursday, September 3, 2020 2:05 PM
To: Tommy Jensen <[email-masked]>; Tommy Pauly <[email-masked]>
Cc: Eric Rescorla <[email-masked]>; tirumal reddy <[email-masked]>; ADD Mailing list <[email-masked]>; Christopher Wood <[email-masked]>
Subject: RE: [Add] [EXTERNAL] Re: ADD Requirements Draft

> to power DNS server selection or configuration UX.

That’s a helpful clarification.  I don’t believe that simply accessing a domain name signifies a “relationship” with the host, noting that, for example, I may be using a VPN with ad blockers, cookie settings etc set to protect my privacy when using my browser.  Also, it’s easy to envisage a “bad actor” (which could be an entity with commercial data gathering intent rather than any malicious intent) triggering access from my device to a domain without my knowledge.

Therefore, taking access to a domain access, if that’s what you meant (?) to assert that “we don’t need any new explanation of policy, we’re relying on existing relationships" is a real stretch.  If a client intends to move from my DNS settings as a user (or indirect user as per RFC 8890) then I’d expect that client to seek permission before doing so.  It’s hard not to interpret any different behaviour as potentially malicious and certainly not driven by the best interests of the user (counter to RFC 8890).  It may also be contrary to GDPR etc although we’d need guidance on that (IANAL).

Andrew

---

From: Rob Sayre <[email-masked]>
Date: Thu, 3 Sep 2020 23:57:26 -0700

On Thu, Sep 3, 2020 at 2:44 PM Tommy Jensen <Jensen.Thomas=
[email-masked]> wrote:

> > If a client intends to move from my DNS settings as a user (or indirect
> user as per RFC 8890) then I’d expect that client to seek permission before
> doing so.  It’s hard not to interpret any different behaviour as
> potentially malicious and certainly not driven by the best interests of the
> user (counter to RFC 8890).
>
> I totally disagree. In most cases, the user didn't have any manual or
> chosen settings. They were simply using the default, which today happens to
> be network recommendation. I think it's a stretch to say changing that
> paradigm, which most users are unaware of, would automatically be malicious
> or not in our users' interests.
>

Agree that it would be a stretch to call the default the "user's choice",
and I also agree this issue is outside of the charter: "Making any
recommendations about specific policies for clients or servers is out of
scope."

I think the best thing to do would be to leave extension field space
available for this space. Personally, I don't see how such a feature could
be distinguished from a downgrade attack, but maybe it could work.

thanks,
Rob

---

From: tirumal reddy <[email-masked]>
Date: Fri, 4 Sep 2020 12:36:27 +0530

Hi Tommy,

On Thu, 3 Sep 2020 at 20:30, Tommy Pauly <[email-masked]> wrote:

> a) I don't think it is possible for every ISP and Enterprise network in
> the world to approach each and every Browser and OS vendor to be
> pre-configured with network provided encrypted DNS servers.
>
>
> It’s not about the relationship of the OS or the browser with the entities
> that can provide DNS services, it’s the relationship of the *user* with
> those entities.
>

Agreed.

> I do not want to have any pre-configuration for any resolver in my OS.
>

Glad to hear. The benefit of conveying the privacy URL is the user does not
have to search to find the URL that points to the human-readable privacy
policy information of the DNS server. The other advantage is if the user
does not have the time/knowledge to understand the human-readable privacy
policy information of the DNS server, user can rely on tools which use AI
to provide summary of the policy (e.g.,
https://addons.mozilla.org/en-US/firefox/addon/polisis/).

It is very similar to Apple mandating apps to provide a link to the privacy
policy in an easily accessible manner within the app for users. It does not
discuss signaling any machine-parsable privacy policy and it does not
intend to replace the privacy statement provided by a legal attorney.

Why do you object to providing a privacy statement URL as resolver
information to the user/client ?

> Secure discovery—or at least authenticated discovery over a secure
> channel—is indeed the right way to do things. We should be designing and
> standardizing mechanisms that raise the bar for security over the status
> quo, and ensure that we are not making avenues of attack easier.
>

Agreed, secure discovery is possible in several scenarios like VPN (e.g.,
using IKEv2 Configuration Payload ), Enterprise networks for BYOD (e.g.,
EST) but not possible home networks.
https://tools.ietf.org/html/draft-btw-add-home-08#section-10 discusses how
all the threats in RFC3552 can be addressed in the presence of insecure
discovery.

Cheers,
-Tiru

---

From: tirumal reddy <[email-masked]>
Date: Fri, 4 Sep 2020 12:58:21 +0530

On Thu, 3 Sep 2020 at 20:32, Tommy Pauly <[email-masked]> wrote:

> This charter point refers, I believe, to information like applicable or
> private domains, provider identity, etc. I think that filtering policy and
> auditing statements are not in scope: "Making any recommendations about
> specific policies for clients or servers is out of scope.”
>

The draft does not recommend any specific policies for clients or servers.
For example, it does not discuss any "privacy policies'.

a) It explains DNS server identity and cryptographically attesting the
identity.
b) It also discusses whether the server performs filtering, reasons for
filtering (blocking malware/phishing etc.). We are considering the conveyed
resolver information as "resolver capabilities". It does not recommend any
specific policy for the server/client.

-Tiru

>>>>>>>>>> As I said when you first proposed this in an ADD meeting, I do
>>>>>> not believe that anything of this kind is viable.
>>>>>>
>>>>>
>>>> Taking a step back here: is there any client with significant usage
>>>> a resolver? If so, I'd like to hear from them about their needs. If not, it

---

From: tirumal reddy <[email-masked]>
Date: Fri, 4 Sep 2020 13:16:03 +0530

On Thu, 3 Sep 2020 at 23:07, Tommy Jensen <Jensen.Thomas=
[email-masked]> wrote:

> To answer this, I will also state my objection. I do not want to be in the
> business of evaluating anything about a DNS server other than its
> functionality and support for a given protocol. I want to leave DNS server
> choice up to my users/admins, or make non-policy based decisions for the
> default case when I have no user input.
>

https://docs.microsoft.com/en-us/windows/uwp/publish/store-policies says
apps should provide  privacy policy URL access to users. How do you expect
a user/admin to make a choice without knowing the discovered resolver
capabilities and access to the privacy policy URL ?

-Tiru

> For the record, in cases like IoT, "user input" doesn't require a
> connected keyboard or even direct device connection.
>
> That's only a subset of the truth. Windows is also an IoT platform, for
> example. My DNS client is used by headless components throughout the OS,
> first- and third-party. I want to be clear on this: I'm both opposed and
> not interested in this proposal as an OS DNS client with the various roles
> that encompasses. I think configuration of trusted servers is best left to
> out-of-band control channels per-platform that configure other networking
> settings as well. I never want my DNS client to reason on its own about the
> value of policy on the user's behalf.
>
> +1 to Tommy Pauly's statement on another thread: policy is beyond the
> scope of this WG, and that's the part I object to.
>

> *From:* Add <[email-masked]> on behalf of Michael Richardson <
> [email-masked]>
> *Sent:* Thursday, September 3, 2020 8:28 AM
> *To:* ADD Mailing list <[email-masked]>

---

From: Steffen Nurpmeso <[email-masked]>
Date: Fri, 04 Sep 2020 16:24:59 +0200

|I totally disagree. In most cases, the user didn't have any manual \
 |or chosen settings. They were simply using the default, which today \
 |happens to be network recommendation. I think it's a stretch to say \
 |changing that paradigm, which most users are unaware of, would automatic\
 |ally be malicious or not in our users' interests.
 |
 |I would say your feedback is focused on the side effects of implementation \
 |details rather than standard details. I agree this (or anyone else's \

Just some feedback from a small client.

The SMTP, IMAP etc standards are well maintained (different to
POP3) and stand as they are even though "enterprise" maybe blocked
them and forced people to go via a HTTP based proxy to reach out
for these services.  They may even force usage of specific CA
pools which effectively allow clear text inspection of data.
Noone can fight such rude enforcements unless you are rich and
work only for fun, in which case you can leave, or at least often
so.  And i trust TLSv1.3 has no backdoors.

Just this week i saw RFC 8880 (on Special Use Domain Name
'ipv4only.arpa') fly by and liked it just as i liked the neat PTR
reverse lookup.  The standard could very well introduce a similar
approach, important enough for special-casing it surely would be,
and return oneselfs IP address as well as an A/AAAA for a DNS
resolver which could be contacted immediately TLS encrypted on
domain not domain-s.  Ie initial automatic setup via DHCP maybe,
looking up the special name, which is handled by that party in the
DNS forward chain that actually can handle it, contacting the
response over secured transport.

The "enterprise split networks" require special software, i yet
have to see a normal user box stub resolver which is capable to
perform such filtering, let alone automatically configured, the
best you get is a sequential list of DNS IP addresses which is QoS
maintained, until now.  This is true even for more sophisticated
all-inclusice be-happy-in-your-net software like dnsmasq.  But
interesting pointers for a draft which defines a key payload
extension.  Or you go over a specific proxy which handles name
lookup, too, as in SOCKS (and i hope the firefox i use now
continues to use it exactly like that if i configure it so).  Or
you rely on the given resolver in a VPN to deal with just about
anything you give it correctly.

The enrollment (i just learned about RFC 7030 not too far back) of
initial TLS trust is a problem i have not yet seen an answer to
that i understand, but certificate transport via TLS connection
and regular DNS lookups is great?!  They can block domain as such,
they can deep-inspect traffic and forbid encrypted connections
only, but if this is the standard then they have to counteract it
and that can become a major effort if all the big players support
it.  I yet have to see this in use, mostly you get use-this-CA-
pool, fwiw, no?  Otherwise you could use the default CA pool or
try to verify against root servers.  Because surely, what else
could be used, anything else needs user interaction.  And if some
big player web browser distresses root servers, then amplifying
DNS is well worth it, in my opinion.

If you want to have a policy URL dispatched, a specific RR could
well be (requested and) received from our encrypted partner.  But
really, as a tiny programmer for even tinier client software, what
a mess.  JSON to deliver port numbers, HTTP for a few simply
commands, HTTPS in fact, for secured connections (heck if that
relies on a local CA pool for HTTPS connections, why are these
certificates not also used for DNS, i am too stupid, really).  The
dump little user stub just wants to replace the IP he is talking
to with one that can be contacted in an encrypted fashion, and
handle all that with a few kilobyte of code.  Out of the MUD, so
to say.

A good day i wish,

--steffen
|
|Der Kragenbaer,                The moon bear,
|der holt sich munter           he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

---

From: Tommy Jensen <[email-masked]>
Date: Fri, 4 Sep 2020 15:19:54 +0000

> https://docs.microsoft.com/en-us/windows/uwp/publish/store-policies<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.microsoft.com%2Fen-us%2Fwindows%2Fuwp%2Fpublish%2Fstore-policies&data=02%7C01%7CJensen.Thomas%40microsoft.com%7Cef3d0de77012475db10608d850a69c9d%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637348023810766874&sdata=2wHXet6kERz7X4BRer%2B7tlsbwFbFM2dnC0XSEG5oGzw%3D&reserved=0>says apps should provide  privacy policy URL access to users.

I'm glad you brought up our store app. It's a great example of how system pluggable components such as apps (or in future DNS server configurations?) can be distributed in a user-verifiable way. Perhaps DNS server profiles are something people package and install from app stores much like VPN profiles. There's a strong existing UX with the power to audit and validate what it distributes without building a whole new standardized way to attest policies automatically. This can be tightly managed and supervised without relying on AI or human review at discovery time.

It's not that I object to users being shown the privacy policy of their DNS servers. I object to a protocol making it a mandatory part of somehow approving a server at the protocol level. For example, websites don't have their policy approval such as allowed cookies built into HTTP; they display it as part of the HTML content they deliver.

In fact, running with that comparison... why not make the privacy policy of a server retrievable as part of the server's own metadata via SUDN (resolver.arpa) or a well-known path? DNS clients could then choose to not send queries to a given server until they go through an approval process specific to their UX fed by this server metadata. The point is that shouldn't block protocol connection. User trust or policy agreement/approval must not be conflated with the automated process of a protocol negotiating the security/authentication of a connection.

Whether the user/admin trusts example.com and whether the server sending me bits is indeed example.com need to be separated, whether the connection's content is HTML, DNS, or anything else. Once I acquire the address to connect to, decisions about whether I should connect have already been made at a layer above me. This could have been UI, script, configuration, or defaults such as network discovery.

Thanks,
Tommy

________________________________
From: tirumal reddy <[email-masked]>
Sent: Friday, September 4, 2020 12:46 AM
To: Tommy Jensen <[email-masked]>
Cc: Michael Richardson <[email-masked]>; ADD Mailing list <[email-masked]>
Subject: Re: [Add] [EXTERNAL] Re: ADD Requirements Draft

of consensus.

To answer this, I will also state my objection. I do not want to be in the business of evaluating anything about a DNS server other than its functionality and support for a given protocol. I want to leave DNS server choice up to my users/admins, or make non-policy based decisions for the default case when I have no user input.

https://docs.microsoft.com/en-us/windows/uwp/publish/store-policies<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.microsoft.com%2Fen-us%2Fwindows%2Fuwp%2Fpublish%2Fstore-policies&data=02%7C01%7CJensen.Thomas%40microsoft.com%7Cef3d0de77012475db10608d850a69c9d%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637348023810766874&sdata=2wHXet6kERz7X4BRer%2B7tlsbwFbFM2dnC0XSEG5oGzw%3D&reserved=0> says apps should provide  privacy policy URL access to users. How do you expect a user/admin to make a choice without knowing the discovered resolver capabilities and access to the privacy policy URL ?

-Tiru

For the record, in cases like IoT, "user input" doesn't require a connected keyboard or even direct device connection.

Thanks,
Tommy

________________________________
From: Add <[email-masked]<mailto:[email-masked]>> on behalf of Michael Richardson <[email-masked]<mailto:[email-masked]>>
Sent: Thursday, September 3, 2020 8:28 AM
To: ADD Mailing list <[email-masked]<mailto:[email-masked]>>
Subject: [EXTERNAL] Re: [Add] ADD Requirements Draft

Eric Rescorla <[email-masked]<mailto:[email-masked]>> wrote:
    ekr> point, I think you're hearing that client vendors aren't interested,

--
Michael Richardson <[email-masked]<mailto:[email-masked]>>, Sandelman Software Works
 -= IPv6 IoT consulting =-
--
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=02%7C01%7CJensen.Thomas%40microsoft.com%7Cef3d0de77012475db10608d850a69c9d%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637348023810776866&sdata=PUnu3v2bFKaWjSof9TtoQHAu%2BZFTPn5IgVixPk8MlTI%3D&reserved=0>

---

From: Tommy Jensen <[email-masked]>
Date: Fri, 4 Sep 2020 15:27:22 +0000

> well be (requested and) received from our encrypted partner.

+1. I didn't see this before I sent my last list reply alluding to the same thing.

> The dump little user stub just wants to replace the IP he is talking

+1. Stubs securing the connection is separate from users/admins trusting and choosing the connection.

Thanks,
Tommy

________________________________
From: Add <[email-masked]> on behalf of Steffen Nurpmeso <[email-masked]>
Sent: Friday, September 4, 2020 7:24 AM
To: ADD Mailing list <[email-masked]>
Cc: Steffen Nurpmeso <[email-masked]>
Subject: Re: [Add] [EXTERNAL] Re: ADD Requirements Draft

A good day i wish,

--steffen
|

--
Add mailing list
[email-masked]
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fadd&amp;data=02%7C01%7CJensen.Thomas%40microsoft.com%7Cbb0137797b1f4ab5428808d850de56a7%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637348263158009469&amp;sdata=qixxcP5%2Fseonaf8gzi2aaNzIF47LD4PMdNhCAI0cZ20%3D&amp;reserved=0

---

From: Jim Reid <[email-masked]>
Date: Fri, 4 Sep 2020 16:59:55 +0100

On 4 Sep 2020, at 16:19, Tommy Jensen <Jensen.Thomas=[email-masked]> wrote:
> 
> It's not that I object to users being shown the privacy policy of their DNS servers. I object to a protocol making it a mandatory part of somehow approving a server at the protocol level.  

Nobody’s suggesting such a thing - at least I hope not.

What could/should be part of this WG’s discovery efforts is a way for a DNS server to signal to its clients what privacy options, if any, it offers. Or perhaps for clients to signal to the server what privacy options it will/won’t accept. This could (handwave) be something comparable to the extended EDNS error codes, albeit dressed up in XML or JSON syntactic sugar or whatever else the WG ultimately agrees as the way of publishing that info.

> Whether the user/admin trusts example.com and whether the server sending me bits is indeed example.com need to be separated, whether the connection's content is HTML, DNS, or anything else. Once I acquire the address to connect to, decisions about whether I should connect have already been made at a layer above me.

How can that be made to work for DNS discovery? Who/what is making the decision at that higher level about the DNS server you “connect” to? How? Isn’t this the problem that this WG is meant to address?

PS: apologies for a meaningful and relevant Subject: header. :-)

---

From: Paul Wouters <[email-masked]>
Date: Fri, 4 Sep 2020 12:52:41 -0400 (EDT)

> What could/should be part of this WG’s discovery efforts is a way for a DNS server to signal to its clients what privacy options, if any, it offers. Or perhaps for clients to signal to the server w…

Or a DHCP option if youmight want to offer ones different from the
regular DNS servers obtained via DHCP.

> How can that be made to work for DNS discovery? Who/what is making the decision at that higher level about the DNS server you “connect” to? How? Isn’t this the problem that this WG is meant to addr…

And this is why some people like me believe the last mile network DNS
should only be used to obtain access. Once obtained, you use your own
encrypted DNS services that you love and trust.

Any mechanisms conveying encrypted dns server policies are either
untrustworthy or yet another PKI waiting to happen with its own
bootstrap.

Paul

---

From: Tommy Jensen <[email-masked]>
Date: Fri, 4 Sep 2020 17:15:16 +0000

Totally agree Jim, with the caveat that these are un-attestable signals. Therefore, they shouldn't be part of the server authentication workflow. They should be treated as other server metadata discovered after a connection is established. This is comparable to websites and their cookie policies: connect first and then deliver the policy over the connection to inform user decisions to continue remaining connected.

>> Nobody’s suggesting such a thing - at least I hope not.

The draft driving my feedback is this one, which authenticates local network DNS servers and their policies: https://datatracker.ietf.org/doc/draft-reddy-add-server-policy-selection/

The second half of the abstract highlights my concerns:

"The document defines a mechanism that allows communication of DNS
   resolver information to DNS clients for use in server selection
   decisions.  In particular, the document defines a mechanism for a DNS
   server to communicate its filtering policy and privacy statement URL
   to DNS clients. This information is cryptographically signed to
   attest its authenticity.  Such information is used for the selection
   of DNS resolvers.  Typically, evaluating the DNS privacy statement,
   filtering policy, and the signatory, DNS clients with minimum human
   intervention can select the DNS server that best supports the user's
   desired privacy and filtering policy."

Thank you, Paul; this is a succinct summary of the not succinct email I was drafting.

Thanks,
Tommy

________________________________
From: Paul Wouters <[email-masked]>
Sent: Friday, September 4, 2020 9:52 AM
To: Jim Reid <[email-masked]>
Cc: Tommy Jensen <[email-masked]>; ADD Mailing list <[email-masked]>
Subject: [EXTERNAL] Re: [Add] discovery of DNS server privacy policy

Paul

---

From: Dan Wing <[email-masked]>
Date: Fri, 4 Sep 2020 10:47:24 -0700

> Totally agree Jim, with the caveat that these are un-attestable signals. Therefore, they shouldn't be part of the server authentication workflow. They should be treated as other server metadata dis…

I don't want to draw analogies with DNS based on the state storage of HTTP cookies and existing user interaction of HTML.  That browsers do this in HTML today, most times in a language understood by the visitor (visit some .eu sites where you don't speak the language for fun and games with setting your cookie preferences), is because there exists no way to convey these policies in a protocol.  And the cookies are owned and managed by applications which already deliveries HTML so it's easiest to ask over HTML and store the user's preference in a cookie -- rather than coordinating with .well_known, DNS, or otherwise.

That said, I agree connecting and then retrieving DoH policy works just as well for the end user as retrieving policy prior to connecting to the DoH server.

-d

---

From: "Martin Thomson" <[email-masked]>
Date: Sat, 05 Sep 2020 20:23:03 +1000

On Sat, Sep 5, 2020, at 03:47, Dan Wing wrote:
> I don't want to draw analogies with DNS based on the state storage of 
> HTTP cookies and existing user interaction of HTML.  That browsers do 
> this in HTML today, most times in a language understood by the visitor 
> (visit some .eu sites where you don't speak the language for fun and 
> games with setting your cookie preferences), is because there exists no 
> way to convey these policies in a protocol.

P3P was, I understand, an effort to do this.  It was not exactly a roaring success.

---

From: Michael Richardson <[email-masked]>
Date: Sun, 06 Sep 2020 12:53:25 -0400

Tommy Jensen <[email-masked]> wrote:
    > It's not that I object to users being shown the privacy policy of their
    > DNS servers. I object to a protocol making it a mandatory part of
    > somehow approving a server at the protocol level. For example, websites
    > don't have their policy approval such as allowed cookies built into
    > HTTP; they display it as part of the HTML content they deliver.

That sure seems like a bug to me!
Web sites are being forced to annoy users to communicate a policy, because we
didn't standardize a way to do so.   For some web sites, it's not easy, and
they simply deny-list all of Europe.

THis means that the browser can not collect the cookie policy, can't store it
where the user can review it easily (changing their policy), and the user is
often bothered with re-establishing policies that they already set.
(This is my experience)

    > In fact, running with that comparison... why not make the privacy
    > policy of a server retrievable as part of the server's own metadata via
    > SUDN (resolver.arpa) or a well-known path? DNS clients could then

I suspected, in your other responses, that you hadn't read the document.
Now I'm sure :-)
Perhaps you could actually read what the document says?

Because, section 10 is about using RESINFO, pointing at pp-add-resinfo.
Which is where resolver-info.arpa comes from.

I think that we have a problem mixing things together involving IANA
registries and JWT claims, but that can be resolved if the WG adopts both.

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

---

From: tirumal reddy <[email-masked]>
Date: Mon, 7 Sep 2020 17:22:45 +0530

On Fri, 4 Sep 2020 at 21:30, Jim Reid <[email-masked]> wrote:

> DNS servers. I object to a protocol making it a mandatory part of somehow
> approving a server at the protocol level.
>

Yes, the resolver information (e.g., DNS server identity, cryptographically
asserted DNS server identity, filtering capability, privacy statement URL)
are provided in RESINFO RRTYPE defined in
https://tools.ietf.org/html/draft-pp-add-resinfo-02 to convey the resolver
information in a JSON object.

The client can use any of the mechanisms (DHCP/RA, PvD and SUDN) to
discover and connect to the Encrypted DNS server, it can then use
https://tools.ietf.org/html/draft-reddy-add-server-policy-selection-05 to
learn the discovered DNS server resolver information to help in the
selection decision.

-Tiru

>
> What could/should be part of this WG’s discovery efforts is a way for a
> DNS server to signal to its clients what privacy options, if any, it
> offers. Or perhaps for clients to signal to the server what privacy options
> it will/won’t accept. This could (handwave) be something comparable to the
> extended EDNS error codes, albeit dressed up in XML or JSON syntactic sugar
> or whatever else the WG ultimately agrees as the way of publishing that
> info.
>

>
> > Whether the user/admin trusts example.com and whether the server
> sending me bits is indeed example.com need to be separated, whether the
> connection's content is HTML, DNS, or anything else. Once I acquire the
> address to connect to, decisions about whether I should connect have
> already been made at a layer above me.
>
> How can that be made to work for DNS discovery? Who/what is making the
> decision at that higher level about the DNS server you “connect” to? How?
> Isn’t this the problem that this WG is meant to address?
>

---

From: tirumal reddy <[email-masked]>
Date: Mon, 7 Sep 2020 18:00:38 +0530

> P3P was, I understand, an effort to do this.  It was not exactly a roaring

https://ietf.org/rfc/rfc6462.html discusses the challenges faced by P3P.

-Tiru

---

From: Tommy Jensen <[email-masked]>
Date: Tue, 8 Sep 2020 16:30:35 +0000

> Perhaps you could actually read what the document says?

Your suspicion is incorrect. However, I did indeed miss the nuance that policy was retrievable from a server after connection establishment (as opposed to just the strictly necessary connection metadata such as DoH template). While I obviously am in favor of the ability to retrieve server metadata, I‘m still opposed to this draft for all the reasons I’ve repeatedly given and others have brought up about its threat model.

> they simply deny-list all of Europe.

The “how do I confirm this endpoint conforms to legal policy my locale requires” problem is worthy of solving. However, it’s much bigger than DNS or this WG’s charter and I will continue opposing policy-related protocol work specific to DNS. This ties in closely with (albeit not identical to) my conversation with Paul Vixie on a fork of this thread.

In addition, in context of my opposition to your draft, such a mechanism would need to have all of its policy options rigidly standardized. This allows full automation based on locale (GDPR) or platform defaults (DNS client marketed promises). This is important because users will almost always click through any policy UX standing between them and internet connectivity.

Thanks,
Tommy Jensen

________________________________
From: Michael Richardson <[email-masked]>
Sent: Sunday, September 6, 2020 9:53 AM
To: Tommy Jensen <[email-masked]>; tirumal reddy <[email-masked]>; ADD Mailing list <[email-masked]>
Subject: Re: [Add] [EXTERNAL] Re: ADD Requirements Draft

---

From: Andrew Campling <[email-masked]>
Date: Tue, 8 Sep 2020 17:01:07 +0000

On Sep 3, 2020, at 22:44, Tommy Jensen <[email-masked]<mailto:[email-masked]>>  wrote:

> On Sep 3, 2020, at 14:05, Andrew Campling <[email-masked]<mailto:[email-masked]>>  wrote:
>> If a client intends to move from my DNS settings as a user (or indirect user as per RFC 8890) then I'd expect that client to seek permission before doing so.  It's hard not to interpret any different behaviour as potentially malicious and certainly not driven by the best interests of the user (counter to RFC 8890).

> I totally disagree. In most cases, the user didn't have any manual or chosen settings. They were simply
> using the default, which today happens to be network recommendation. I think it's a stretch to say
> changing that paradigm, which most users are unaware of, would automatically be malicious or not in
> our users' interests.

Some scenarios:

  *   My DNS may have been provided as part of a signed contract with my ISP
  *   I may have configured my operating system or browser DNS settings to set my preferred ISP
  *   My parents (assuming I'm a minor) may have configured DNS preferences to provide filtering
  *   My employer may have DNS policies implemented for all devices across its estate and/or using its networks

In all of these cases, changing that paradigm in the manner suggested would be counter to stated or implied user preferences.  If the user is European, it may, for example, also allow personal data to be exported beyond the boundaries of the EU; if the company involved is US-based then Privacy Shield has already been found to be inferior to the protections offered by GDPR.  Also, if the company is US-based then, for any non-US citizen not resident in the US, FISA 702 and the Cloud Act combine to remove privacy irrespective of the location of the servers.   This could certainly be argued as counter to the users' interests, would seem to be at odds with RFC 8890.

>> It may also be contrary to GDPR etc although we'd need guidance on that (IANAL).

> I think you know by now what I'll say to this :) I have yet to hear a concrete requirement based on GDPR
> that says anything about how DNS servers are configured, chosen, or connected to. Until such time, this
> is too hand wavy for any document author to act upon. Please correct me if I'm wrong. Otherwise, I'd rather
> avoid statements like this. Until a lawyer says otherwise, _anything_ might run afoul of any law.

To expand on GDPR, let's assume that my current DNS service works.  By moving the DNS elsewhere and counter to my settings/preferences in this manner you would not have my informed consent.  In my view, you could not reasonably argue that:

  *   Processing is necessary to satisfy a contract to which the data subject is a party.
  *   You need to process the data to comply with a legal obligation.
  *   You need to process the data to save somebody's life.
  *   Processing is necessary to perform a task in the public interest or to carry out some official function.
  *   You have a legitimate interest to process someone's personal data. This is the most flexible lawful basis, though the "fundamental rights and freedoms of the data subject" always override your interests, especially if it's a child's data.

In short, I think that it would be incredibly difficult to argue that this change in the way that DNS operates, which is not driven by technical necessity, meets the requirements of GDPR.

It would be good to get some additional input here, perhaps from some of the government / regulatory people on the list.

Andrew

---

From: Tommy Jensen <[email-masked]>
Date: Tue, 8 Sep 2020 17:27:22 +0000

In any scenario where users have provided some config, I agree deviating from that config would be against the user's interests.

However, in the default scenario (no manual DNS config of any kind), there's no way for a client to know whether the DNS server the network recommends is a provider of user-requested value. You can't say this scenario has "stated or implied user preferences" as a result. This can be solved by endpoint control (ISPs instruct customers to make endpoint configuration changes to opt into their DNS features), or by network control.

With DNS now being encrypted, network control will require a new mechanism to communicate policy. Which bring us back to the ongoing debate about what part of this topic belongs in this WG.

> To expand on GDPR...

We're still not lawyers, and again, I see our draft becoming GDPR compliant or defiant based on how an implementation enables the feature, not that the feature exists at all.

> It would be good to get some additional input here, perhaps from some of the government / regulatory people on the list.

I agree.

Thanks,
Tommy

Sent: Tuesday, September 8, 2020 10:01 AM

Some scenarios:

  *   My DNS may have been provided as part of a signed contract with my ISP
  *   I may have configured my operating system or browser DNS settings to set my preferred ISP
  *   My parents (assuming I’m a minor) may have configured DNS preferences to provide filtering
  *   My employer may have DNS policies implemented for all devices across its estate and/or using its networks

In all of these cases, changing that paradigm in the manner suggested would be counter to stated or implied user preferences.  If the user is European, it may, for example, also allow personal data to be exported beyond the boundaries of the EU; if the company involved is US-based then Privacy Shield has already been found to be inferior to the protections offered by GDPR.  Also, if the company is US-based then, for any non-US citizen not resident in the US, FISA 702 and the Cloud Act combine to remove privacy irrespective of the location of the servers.   This could certainly be argued as counter to the users’ interests, would seem to be at odds with RFC 8890.

> avoid statements like this. Until a lawyer says otherwise, _anything_ might run afoul of any law.

To expand on GDPR, let’s assume that my current DNS service works.  By moving the DNS elsewhere and counter to my settings/preferences in this manner you would not have my informed consent.  In my view, you could not reasonably argue that:

  *   Processing is necessary to satisfy a contract to which the data subject is a party.
  *   You need to process the data to comply with a legal obligation.
  *   You need to process the data to save somebody’s life.
  *   Processing is necessary to perform a task in the public interest or to carry out some official function.
  *   You have a legitimate interest to process someone’s personal data. This is the most flexible lawful basis, though the “fundamental rights and freedoms of the data subject” always override your interests, especially if it’s a child’s data.

Andrew

---

From: "Deen, Glenn" <[email-masked]>
Date: Tue, 8 Sep 2020 17:32:41 +0000

I’d like to remind everyone in this thread that ADD’s scope is limited to the mechanisms for discovery.  Part of this thread is drifting into HCI, user choices, legal, and policy decisions which are out of scope.

There are other mail lists where that conversation would be more appropriate.

It is in scope to propose a requirement for a means to convey information needed for such choices, but please stay away from discussing how such information should/must be used.

Regards
Glenn Deen – ADD co-chair.

---

From: Eric Orth <[email-masked]>
Date: Tue, 8 Sep 2020 13:47:33 -0400

This thread keeps venturing into obviously out-of-scope-for-this-WG policy
areas, and I will not comment on those subthreads.

Regarding mechanisms for resolvers to programmatically communicate
information such as privacy policies, as long as no policy is given
mandating use of that information, seems reasonable to me as long as
clients can be found interested in using the information.  If the interest
is not there right now, probably better to just ensure any resolver
information mechanisms are expandable to add it if found useful in the
future.

As for whether or not Chrome would make use of privacy policy links, I'm
not seeing an obvious use right now, but maybe that could change in the
future as this WG further refines discovery mechanisms and Chrome refines
its plans around them.

On Tue, Sep 8, 2020 at 1:33 PM Deen, Glenn <[email-masked]> wrote:

> I’d like to remind everyone in this thread that ADD’s scope is limited to
> the mechanisms for discovery.  Part of this thread is drifting into HCI,
> user choices, legal, and policy decisions which are out of scope.
>
>
>
> It is in scope to propose a requirement for a means to convey information
> needed for such choices, but please stay away from discussing how such
> information should/must be used.
>
>
>
>
>
>
>
> Regards
>

---

From: Ted Lemon <[email-masked]>
Date: Tue, 8 Sep 2020 13:52:00 -0400

On Sep 8, 2020, at 1:47 PM, Eric Orth <ericorth=[email-masked]> wrote:
> Regarding mechanisms for resolvers to programmatically communicate information such as privacy policies, as long as no policy is given mandating use of that information, seems reasonable to me as long as clients can be found interested in using the information.  If the interest is not there right now, probably better to just ensure any resolver information mechanisms are expandable to add it if found useful in the future.

The problem with this is that if the group spends time doing this work without identifying _any circumstance_ in which it would actually be used, that’s a lot of time wasted and more chaff in the RFC database.

---

From: Eric Orth <[email-masked]>
Date: Tue, 8 Sep 2020 14:08:55 -0400

Further refining my statement about Chrome maybe having use for privacy
policy links in the future but not definitely yet:
Chrome's DoH configuration UI displays a privacy policy link (stored in the
hard-coded provider list) when explicitly selecting a DoH server.  I could
see us using a discovered privacy policy similarly if discovered DoH
servers ever become options in that selection menu.  Vs if discovered DoH
servers are only ever used for silent autoupgrade, I'm not seeing much use
for privacy policy.

It really depends on plans that are all still TBD and pending on figuring
out more specifics of the discovery mechanisms themselves.

On Tue, Sep 8, 2020 at 1:52 PM Ted Lemon <[email-masked]> wrote:

> On Sep 8, 2020, at 1:47 PM, Eric Orth <
> ericorth=[email-masked]> wrote:
>
> The problem with this is that if the group spends time doing this work
> without identifying _any circumstance_ in which it would actually be used,
> that’s a lot of time wasted and more chaff in the RFC database.
>
>
>

---

From: "Vinny Parla (vparla)" <[email-masked]>
Date: Tue, 8 Sep 2020 22:34:02 +0000

>> With DNS now being encrypted, network control will require a new
mechanism to communicate policy. 
>> Which bring us back to the ongoing debate about what part of this topic
belongs in this WG.

I think that part of what needs to be solved is when User-Preference and
Network-Preference (the Discovered resolver) are at odds with each other and
having a mechanism that lets the user choose to accept the Discovered
outcome or not use the Network.   Maybe this is implementation and outside
the scope of a discovery protocol and the charter of this WG.
 
To me the solution is incomplete and user experience will not be optimal if
this is left unsolved.

-Vinny

From: Add <[email-masked]> On Behalf Of Tommy Jensen
Sent: Tuesday, September 8, 2020 1:27 PM
To: Andrew Campling <[email-masked]>; Tommy Pauly
<[email-masked]>
Cc: Eric Rescorla <[email-masked]>; ADD Mailing list <[email-masked]>;
Christopher Wood <[email-masked]>; tirumal reddy <[email-masked]>
Subject: Re: [Add] [EXTERNAL] Re: ADD Requirements Draft

In any scenario where users have provided some config, I agree deviating
from that config would be against the user's interests.

However, in the default scenario (no manual DNS config of any kind), there's
no way for a client to know whether the DNS server the network recommends is
a provider of user-requested value. You can't say this scenario has "stated
or implied user preferences" as a result. This can be solved by endpoint
control (ISPs instruct customers to make endpoint configuration changes to
opt into their DNS features), or by network control. 

With DNS now being encrypted, network control will require a new mechanism
to communicate policy. Which bring us back to the ongoing debate about what
part of this topic belongs in this WG.

> To expand on GDPR...

We're still not lawyers, and again, I see our draft becoming GDPR compliant
or defiant based on how an implementation enables the feature, not that the
feature exists at all.

> It would be good to get some additional input here, perhaps from some of
the government / regulatory people on the list. 

I agree.

Thanks,
Tommy

________________________________________
From: Andrew Campling <mailto:[email-masked]>
Sent: Tuesday, September 8, 2020 10:01 AM
To: Tommy Jensen <mailto:[email-masked]>; Tommy Pauly
<mailto:[email-masked]>
Cc: Eric Rescorla <mailto:[email-masked]>; tirumal reddy
<mailto:[email-masked]>; ADD Mailing list <mailto:[email-masked]>;
Christopher Wood <mailto:[email-masked]>
Subject: RE: [Add] [EXTERNAL] Re: ADD Requirements Draft 
 
On Sep 3, 2020, at 22:44, Tommy Jensen <mailto:[email-masked]>
 wrote:
 
> On Sep 3, 2020, at 14:05, Andrew Campling
user as per RFC 8890) then I’d expect that client to seek permission before
doing so.  It’s hard not to interpret any different behaviour as potentially
malicious and certainly not driven by the best interests of the user
(counter to RFC 8890). 
 
> I totally disagree. In most cases, the user didn't have any manual or
chosen settings. They were simply 
> changing that paradigm, which most users are unaware of, would
automatically be malicious or not in 
 
Some scenarios:
• My DNS may have been provided as part of a signed contract with my ISP  
• I may have configured my operating system or browser DNS settings to set
my preferred ISP
• My parents (assuming I’m a minor) may have configured DNS preferences to
provide filtering
• My employer may have DNS policies implemented for all devices across its
estate and/or using its networks
 
In all of these cases, changing that paradigm in the manner suggested would
be counter to stated or implied user preferences.  If the user is European,
it may, for example, also allow personal data to be exported beyond the
boundaries of the EU; if the company involved is US-based then Privacy
Shield has already been found to be inferior to the protections offered by
GDPR.  Also, if the company is US-based then, for any non-US citizen not
resident in the US, FISA 702 and the Cloud Act combine to remove privacy
irrespective of the location of the servers.   This could certainly be
argued as counter to the users’ interests, would seem to be at odds with RFC
8890.  

> avoid statements like this. Until a lawyer says otherwise, _anything_
might run afoul of any law.
 
To expand on GDPR, let’s assume that my current DNS service works.  By
moving the DNS elsewhere and counter to my settings/preferences in this
manner you would not have my informed consent.  In my view, you could not
reasonably argue that:
• Processing is necessary to satisfy a contract to which the data subject is
a party.
• You need to process the data to comply with a legal obligation.
• You need to process the data to save somebody’s life.
• Processing is necessary to perform a task in the public interest or to
carry out some official function.
• You have a legitimate interest to process someone’s personal data. This is
the most flexible lawful basis, though the “fundamental rights and freedoms
of the data subject” always override your interests, especially if it’s a
child’s data.
 
In short, I think that it would be incredibly difficult to argue that this
change in the way that DNS operates, which is not driven by technical
necessity, meets the requirements of GDPR.  

It would be good to get some additional input here, perhaps from some of the
government / regulatory people on the list.  

Andrew

---

From: Rob Sayre <[email-masked]>
Date: Tue, 8 Sep 2020 16:11:02 -0700

> the scope of a discovery protocol and the charter of this WG.

I believe this is explicitly out of scope: "Making any recommendations
about specific policies for clients or servers is out of scope."

> To me the solution is incomplete and user experience will not be optimal if

Surely this situation already exists. My 2018 Android phone uses a built-in
VPN at all times, and I would not support a clear text mechanism to disable
it (also, it wouldn't work).

https://www.rfc-editor.org/rfc/rfc8890.html

thanks,
Rob

---

From: "Vinny Parla (vparla)" <[email-masked]>
Date: Wed, 9 Sep 2020 02:13:26 +0000

Hi,

Thanks for the response.

I just wanted to share the use case so it is considered.  A discovery protocol is not worth much if it doesn’t work in a way that is successful end to end.

I don’t view this as a policy issue as much as it is a user experience issue (and maybe as such, should be left to implementors to solve).

There is already an existing model with Captive Portal workflows where a user that declines the policies of the network is not able to join that network.

I think that if a discovered DNS resolver is the intent of the network and the user declines to use it, then the behavior should be similar.

As you state, it might be outside the charter of the WG.  I did want to share it with the team nonetheless.

-Vinny

From: Rob Sayre <[email-masked]> 
Sent: Tuesday, September 8, 2020 7:11 PM
To: Vinny Parla (vparla) <[email-masked]>
Cc: Tommy Jensen <[email-masked]>; Andrew Campling <[email-masked]>; Tommy Pauly <[email-masked]>; Eric Rescorla <[email-masked]>; ADD Mailing list <[email-masked]>; Christopher Wood <[email-masked]>; tirumal reddy <[email-masked]>
Subject: Re: [Add] [EXTERNAL] Re: ADD Requirements Draft

belongs in this WG.

I believe this is explicitly out of scope: "Making any recommendations about specific policies for clients or servers is out of scope."

Surely this situation already exists. My 2018 Android phone uses a built-in VPN at all times, and I would not support a clear text mechanism to disable it (also, it wouldn't work).

thanks,

Rob

---

From: tirumal reddy <[email-masked]>
Date: Wed, 9 Sep 2020 15:35:40 +0530

On Tue, 8 Sep 2020 at 22:00, Tommy Jensen <[email-masked]>
wrote:

> Your suspicion is incorrect. However, I did indeed miss the nuance that
> policy was retrievable from a server after connection establishment (as
> opposed to just the strictly necessary connection metadata such as DoH
> template). While I obviously am in favor of the ability to retrieve server
> metadata, I‘m still opposed to this draft for all the reasons I’ve
> repeatedly given and others have brought up about its threat model.
>

Michael and I have already clarified the objections you raised. As I have
repeatedly said, the draft does not discuss any machine-parsable privacy
claims (like the work in P3P).

I am not sure what threats you are referring to and what your concerns are
to retrieve resolver information like cryptographic assertion of the DNS
server identity, filtering capability and several other attributes
discussed in the draft. For example, the cryptographic assertion (based on
RATS) helps the client to identify it not connecting to an encrypted DNS
server hosted by an attacker (especially when the DNS server is discovered
using insecure mechanisms).

-Tiru

> The “how do I confirm this endpoint conforms to legal policy my locale
> requires” problem is worthy of solving. However, it’s much bigger than DNS
> or this WG’s charter and I will continue opposing policy-related protocol
> work specific to DNS. This ties in closely with (albeit not identical to)
> my conversation with Paul Vixie on a fork of this thread.
>
> In addition, in context of my opposition to your draft, such a mechanism
> would need to have all of its policy options rigidly standardized. This
> allows full automation based on locale (GDPR) or platform defaults (DNS
> client marketed promises). This is important because users will almost
> always click through any policy UX standing between them and internet
> connectivity.
>
> Thanks,
> Tommy Jensen
>
> *From:* Michael Richardson <[email-masked]>
> *Sent:* Sunday, September 6, 2020 9:53 AM
> *To:* Tommy Jensen <[email-masked]>; tirumal reddy <
> [email-masked]>; ADD Mailing list <[email-masked]>
> *Subject:* Re: [Add] [EXTERNAL] Re: ADD Requirements Draft
>
>

---

From: tirumal reddy <[email-masked]>
Date: Wed, 9 Sep 2020 15:57:34 +0530

On Tue, 8 Sep 2020 at 23:39, Eric Orth <ericorth=[email-masked]>
wrote:

> Chrome's DoH configuration UI displays a privacy policy link (stored in
> the hard-coded provider list) when explicitly selecting a DoH server.  I
> could see us using a discovered privacy policy similarly if discovered DoH

Yes, the benefit of conveying the privacy URL for the discovered DNS server
is the user does not have to search to find the URL that points to the
privacy policy information of the DNS server.

It is very similar to the ask from OS for apps to provide a privacy link,
for example Apple privacy guidelines for apps says "*All apps must include
a link to their privacy policy in the App Store Connect metadata field and
within the app in an easily accessible manner. "*

> out more specifics of the discovery mechanisms themselves.

The resolver information like a privacy link is retrieved after the
encrypted DNS server is discovered. It has no dependency on the discovery
mechanism.

Cheers,
-Tiru

---

From: Steffen Nurpmeso <[email-masked]>
Date: Wed, 09 Sep 2020 15:29:31 +0200

tirumal reddy wrote in
 <CAFpG3gdAj_va1ox=NNmXeVXOLL7Ub+JxW0v3oAPJc7w=[email-masked]>:
 |On Tue, 8 Sep 2020 at 22:00, Tommy Jensen <[email-masked]>
 |wrote:
 ...
 |discussed in the draft. For example, the cryptographic assertion (based on
 |RATS) helps the client to identify it not connecting to an encrypted DNS

You know, all that makes me sad all the time.  I cannot read that
much out of RATS in the end, doesn't it just define stacked trust
relationships with nice words like "carrier-grade" etc.?  Where is
the meat, so to say (i am vegetarian)?  The appendix on time is
interesting, but it is also nothing new not to compare clocks of
different boxes, but to just work with time deltas.  To me little
one this looks like a big nothing, really.  Come on.  So you can
henceforth create applications and hardware and report this as
RATS and then you have a label, fine.  If an expert has physical
access to hardware then all bets are off.  If there is
a (hypothetical) backdoor than all bets are off.

At times where on CPU level entire operating systems run
concurrently to the operating system that runs the computer, no?
I mean, i am finally looking forward for buying my first
smartphone in a not too distant future (you know, all the rare
earth is digged in and under terrible conditions for earth and
human, i just cannot bear that responsibility), a PinePhone, and
they explicitly document that the actual network chip is connected
via USB, and that by design of this transport that single network
chip at least cannot access the rest of the device.  That
strengthens my trust in this PinePhone.

(I actually do own a used smartphone since a few months, but not
longer than that.  My mother bought herself a new one, and would
have thrown that thing away!!  But i do not and would not do
trusted stuff with it.  I had one of those Nokias with lamp and
SMS but nothing else for way over a decade, a mobile phone.)

 |server hosted by an attacker (especially when the DNS server is discovered
 |using insecure mechanisms).

I would think for a foreseeable future DNS will have to live with
the security of certificates alone, so either you have a CA pool,
and then you trust interesting parties, and all the free software
world furthermore Mozilla and their decisions on what enters their
pool[1] or not -- it really boils down to that, at least here!
And just look into it!! --, or with the entirely different level
of certificates dispatched via DNS aka the chain of interest which
comes down via root certificates, or on zone level, then you
surely need some interaction with the one who drives the zone for
security, or have a bypass that then in turn goes over the CA pool
used in browsers, and here we are again.  That enrollment RFC
i like however, but nonetheless.  Maybe Microsoft or Apple or
Google have further approaches based on business handshakes and
integrated into their software, i do not know.

  [1] https://hg.mozilla.org/releases/mozilla-release/raw-file/default/security/nss/lib/ckfw/builtins/certdata.txt

--steffen
|

---

From: Michael Richardson <[email-masked]>
Date: Wed, 09 Sep 2020 14:45:19 -0400

Steffen Nurpmeso <[email-masked]> wrote:
    > relationships with nice words like "carrier-grade" etc.?  Where i

The words "carrier-grade" appear only when describing an example routers that
might have multiple line cards.   As one of the editors of the architecture
document, I find it odd that you would latch onto that word.
Can you help us make the document clearer?

    > one this looks like a big nothing, really.  Come on.

I am so pleased that you find nothing interesting here.
It's all old, been done before.
That means that we've done a good job of engineering.
In trusted computing, the biggest problem has been that there are 14
non-interoperable specifications.  The goals of the WG have always been
mostly akin to https://xkcd.com/927/.

    > So you can

The question as to who has access to what key, and what they can do with is
indeed a big concern.   Thank you for noticing this.

Standardizing remote attestation certainly will open up the potential for
physical and supply chains hacks to be comodified.  This is part of the basis
for the work I'm trying to do in draft-richardson-t2trg-idevid-considerations.
My goal is that rather than "all bets are off", we will be able to
intelligently give informed odds.

In all of our DNS privacy efforts, someone with physical access to the DNS
server hardware, or a hypothetical backdoor can reveal everything!

The PinePhone is indeed a very nice choice when it comes to full ownership.
But, the last information I got at FOSDEM was that they did not yet access to
the secure enclave of that CPU.
Imagine if we could extend your same privilege of complete ownership to
everyone worldwide?  Until we can get there, it would be great if we could at
least qualify the degree to which their privacy will be respected?

---

From: Tommy Jensen <[email-masked]>
Date: Wed, 9 Sep 2020 19:54:35 +0000

Apologies in advance for the novel below. I'm gathering you want me to be more specific, and I want to honor that.

> Michael and I have already clarified the objections you raised. As I have repeatedly said, the draft does not discuss any machine-parsable privacy claims (like the work in P3P).

My concerns weren't that the policies were machine parsable (though others did bring that up); my concern was and is you're expecting the user to understand it, or an AI to interpret it, for the DNS client to make final decisions about which server to use. In fact, machine parsable would make it more palatable for me (unlike others). Let me back up and be more specific as I'm probably slipping into too many generalities. For this objection, I'm referring to this draft: https://tools.ietf.org/html/draft-reddy-add-server-policy-selection-05

There are other technical objections, but I'll forgo that as it seems to be randomizing my underlying main point: I don't think DNS is the right place to communicate server policy. This statement refers to the policies defined in Section 6.2.2. Here is a breakdown of the DNS scenarios my client faces that lead me to that conclusion:

Scenario 1) the user has taken no configuration action at all, and as a DNS client, I have no knowledge of any servers. When the user joins Network A, it will recommend a DNS server to me. Regardless of its encryption support, regardless of its policies, I will use it. The alternative is to essentially not connect to the Internet. I'm saying this is unacceptable given the user asked me to connect to Network A. You and I may differentiate between "negotiate network connection" and "rely on DNS server for resolutions" but ours users don't. The Internet either works or it doesn't. The policy decision ("do I trust this network") happened _before_ the DNS client was asked to make a server decision.

Scenario 2) the user has configured the DNS client to use a public resolver for all network connections. When the user joins Network A, it will recommend a DNS server to me. Regardless of its encryption support, regardless of its policies, I will not use it. This is because the user has already given me a clear signal to use a different server.

Scenario 3) the user has configured the DNS client to find the DNS server closest to the zone being queried to cut down on recursive server dependencies, but has not given me a DNS server to bootstrap with. When the user joins Network A, it will recommend a DNS server to me. Regardless of its encryption support, regardless of its policies, I will use it to bootstrap my designated server discoveries by sending it all queries then remembering designated servers as I discover them.

Scenario 4) the user has configured the DNS client to find the DNS server closest to the zone being queried to cut down on recursive server dependencies, and has given me a DNS server to bootstrap with. When the user joins Network A, it will recommend a DNS server to me. Regardless of its encryption support, regardless of its policies, I will not use it. This is because I already have a server to bootstrap my designated server discoveries by sending it all queries then remembering designated servers as I discover them.

Scenario 5) I'm in Scenario 2) or 4) meaning I already have DNS servers I will use in favor of the network recommendation, but the network blocks connection to those servers. Regardless of its encryption support, regardless of its policies, I will hard fail and my Internet connectivity will be compromised. My user told me to use specific servers, and allowing blocked connections to make me then use other servers would be a downgrade attack from my point of view.

Scenarios 1) and 2) are identical to 3) and 4) where the first two don't try to find designated zone servers but 3) and 4) do.

The first two two scenario pairs pivot by zone. For example, they could be the general case ("."), or they could be more specific ("*.employer.com"). I may be in Scenario 2) or 4) for "*.employer.com" and Scenario 1) or 3) for ".". This also pivots by network interface, but still can be boiled down to these two scenarios.

That said, I do agree users should be provided the needed information to have made decisions about who to trust. The nuance I think I failed to articulate is that I don't see this as a DNS-specific problem; this is a network problem. By the time I'm connected to Network A, it's too late (in my opinion) to be trying to decide if the network recommendation can be trusted. I decided to trust it when I connected to the network (or decided not to by bringing my own configured DNS server). The only thing left to decide is whether there's a server I trust more. That is trivially answered by whether the user configured my client with a different server to use.

This bring us back to that larger problem of having a network authoritatively articulate its own policies. I would support this draft being repurposed for that goal. I'd even follow it to whatever WG necessary to discuss the problem. I do agree there's value in a network communicating its policies to clients. I think DNS is the wrong place to solve it.

If we can solve it in a more general mechanism, it could be reused to make captive portals far more user friendly and communicate other policies not specific to the DNS ("VPNs are forbidden" or "Internet is only accessible from 8AM to 9PM"). That mechanism does not belong in this WG.

The only thing I see value in at the DNS-specific level is ownership of a zone. That can be readily verified without needing to create a whole new chain of trust. Even claiming to filter a zone you don't own isn't really useful to me, since as illustrated above, it won't influence my server choice. I'll just have to consume the extended DNS error code and inform my user of the occurrence to let them decide if I should be using a different server.

Related to this objection is this draft: https://tools.ietf.org/html/draft-btw-add-home-08

>From Section 7.2:

   > If the discovered encrypted DNS server information is not pre-
   > configured in the OS or the browser, the DNS client needs evidence
   > about the encrypted server to assess its trustworthiness and a way to
   > appraise such evidence.

I totally disagree. Per my scenarios outlined above, I don't need evidence of anything about a network recommendation because I won't need to act on it. I decided to trust the network recommendation the moment I joined the network without bringing my own DNS server. Hence I object to that draft as well.

Formatting the DHCP and RA options to advertise support for encryption on a server, sure, but see below that this isn't strictly necessary (we can try DoT with no information beyond the IP address).

Per Section 5.1 of the latest requirements draft, found here: https://www.ietf.org/id/draft-box-add-requirements-00.html#name-on-opportunistic-encryption

> Performing opportunistic encrypted DNS does not require specific discovery mechanisms. > Section 4.1 of [RFC7858<https://www.ietf.org/id/draft-box-add-requirements-00.html#RFC7858>] already describes how to use DNS-over-TLS opportunistically.

Now securing the network recommendation so I know it didn't come from a local attacker... that's again interesting. However, in line with my objections above on the previous draft, this is not a DNS problem. This is a network problem far bigger than this WG. I do not support solving this problem at the DNS level because a more general mechanism is by far and away the cleaner answer.

tl;dr: Trust in local network resources is a problem of far larger scope that DNS, and doesn't belong in this WG. In addition, I don't need the server policy info your draft describes to decide which server to send queries to. I already have the user controls I need to get their weigh in on that.

Thanks,
Tommy

Sent: Wednesday, September 9, 2020 3:05 AM

Michael and I have already clarified the objections you raised. As I have repeatedly said, the draft does not discuss any machine-parsable privacy claims (like the work in P3P).

I am not sure what threats you are referring to and what your concerns are to retrieve resolver information like cryptographic assertion of the DNS server identity, filtering capability and several other attributes discussed in the draft. For example, the cryptographic assertion (based on RATS) helps the client to identify it not connecting to an encrypted DNS server hosted by an attacker (especially when the DNS server is discovered using insecure mechanisms).

-Tiru

Thanks,
Tommy Jensen

________________________________
From: Michael Richardson <[email-masked]<mailto:[email-masked]>>
Sent: Sunday, September 6, 2020 9:53 AM
To: Tommy Jensen <[email-masked]<mailto:[email-masked]>>; tirumal reddy <[email-masked]<mailto:[email-masked]>>; ADD Mailing list <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Add] [EXTERNAL] Re: ADD Requirements Draft

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

---

From: Steffen Nurpmeso <[email-masked]>
Date: Thu, 10 Sep 2020 00:40:29 +0200

Michael Richardson wrote in
 <13813.1599677119@localhost>:
 |Steffen Nurpmeso <[email-masked]> wrote:
 |> You know, all that makes me sad all the time.  I cannot read that
 |> much out of RATS in the end, doesn't it just define stacked trust
 |> relationships with nice words like "carrier-grade" etc.?  Where i
 |
 |The words "carrier-grade" appear only when describing an example routers \
 |that
 |might have multiple line cards.   As one of the editors of the architecture
 |document, I find it odd that you would latch onto that word.
 |Can you help us make the document clearer?

Well not really.  It is very densily written, meaning content and
language.  With people from Intel, Huawei and Microsoft being
involved i would not really expect talk about clusters of
RaspberryPie's.  I understood that in the second step multiple
such where combined under a larger umbrella.

 |> the meat, so to say (i am vegetarian)?  The appendix on time is
 |> interesting, but it is also nothing new not to compare clocks of
 |> different boxes, but to just work with time deltas.  To me little
 |> one this looks like a big nothing, really.  Come on.
 |
 |I am so pleased that you find nothing interesting here.

Yes, i have understood it as a formalization of what already
exists.  Though, it is not a real formalization, or a "best
practices" RFC.

 |It's all old, been done before.
 |That means that we've done a good job of engineering.

Hm.  I personally really adore many of the old (and very old)
RFCs.  I like the spirit.  And it worked also commercially.  I was
enlightened by the wonderful Licklider, and how he/they
intellectually penetrated what will happen in the far future.

 |In trusted computing, the biggest problem has been that there are 14
 |non-interoperable specifications.  The goals of the WG have always been
 |mostly akin to https://xkcd.com/927/.

Yes.  Maybe.  :)

But like i said, TPM, hardware watchdogs, FIDO, and i really have
read that document in its entirety, .. despite that practical
issues are not really covered, i think companies and whatever
agencies which drive nuclear plants etc etc etc live in war and
fight daily to prevent whatever attackers, maybe even those which
just impersonate so, from doing (maybe then) evil things.  This is
a daily fight for QoS and against the opposite, as well as
penetration.  And then there are lost keys of someone with
security clearance.  And then there is a child with a very rare
illness who needs a treatment which costs millions, and you are in
America.  Or or or.  Isn't that reality?

So what does referencing this repeatedly and insistingly mean for
the discovery of encrypted resolvers?  That was my comment, no?
TLS is about certificates, and there are only so-and-so many
options to get and use certificates, and bootstrapping /
enrollment of initial trust requires user interaction, that is
even standardized.  I could think about lots of possibilities to
get that initial trust, barcode scanning, certificate fingerprint,
whatever, but it isn't automatic, and it is not there, in RATS.

Rats, however, i know, they are very emphatic and have a very
dense social life, they educate their children well, Rats aerate
the earth (if they can), are also health police, and the men are
very brave and tough fighters indeed.  (This is about free ones
living a free but very dangerous life in the forest.)
In sofar i can understand.

 |> So you can
 |> henceforth create applications and hardware and report this as
 |> RATS and then you have a label, fine.  If an expert has physical
 |> access to hardware then all bets are off.  If there is
 |> a (hypothetical) backdoor than all bets are off.
 |
 |The question as to who has access to what key, and what they can do with is
 |indeed a big concern.   Thank you for noticing this.

Oh not me, i am just reading the newsletter of a famous
cryptographer for many years, that is all.

 |Standardizing remote attestation certainly will open up the potential for
 |physical and supply chains hacks to be comodified.  This is part of \
 |the basis
 |for the work I'm trying to do in draft-richardson-t2trg-idevid-considera\
 |tions.

That is a very interesting document.

For free software, some EFI loaders support and use certificates.
refind for example.  But here the best and easiest bet for now
seems to be to have the kernel on an external stick and use block
level encryption for the disk, setting up secure boot is a painful
task.  I even know of at least one FreeBSD user/developer which
has such a secure boot environment.  It requires trust in the EFI
and the CPU and other hardware of the box nonetheless.  If cold
security is required.  It would be easier if the firmware could
come in via a stick, like a yubikey or so, then the root of trust
would be in the hand of the user, and anything on the laptop for
example would be useless with that.  But that surely will not
happen.

 |My goal is that rather than "all bets are off", we will be able to
 |intelligently give informed odds.
 |
 |In all of our DNS privacy efforts, someone with physical access to the DNS
 |server hardware, or a hypothetical backdoor can reveal everything!

The secret keys must be available to the server software.
Some servers/TLS software allow loading them early and once, and
even keeping them in secured memory of sandboxed processes.  This
is as good as it gets i think (the files could even be removed and
their blocks zeroes/randomized, for example), but crashes and
reboots are a problem, and it must of course be physical hardware,
and a root login/exploit must not be possible.  (Unless there are
other options to break this "warm" security of which i have no
idea.)

 |The PinePhone is indeed a very nice choice when it comes to full ownership.
 |But, the last information I got at FOSDEM was that they did not yet \
 |access to
 |the secure enclave of that CPU.

Of the network chip?

 |Imagine if we could extend your same privilege of complete ownership to
 |everyone worldwide?  Until we can get there, it would be great if we \
 |could at
 |least qualify the degree to which their privacy will be respected?

I am all in favour.

--steffen
|

---

From: tirumal reddy <[email-masked]>
Date: Wed, 16 Sep 2020 13:13:19 +0530

Hi Tommy,

Appreciate the detailed feedback. Please see inline

> more specific, and I want to honor that.

No issues, Thanks for sharing your thoughts.

>
> > Michael and I have already clarified the objections you raised. As I
> have repeatedly said, the draft does not discuss any machine-parsable
> privacy claims (like the work in P3P).
>
> My concerns weren't that the policies were machine parsable (though others
> did bring that up); my concern was and is you're expecting the user to
> understand it, or an AI to interpret it, for the DNS client to make final
> decisions about which server to use. In fact, machine parsable would make
> it more palatable for me (unlike others).
>

We removed machine-parsable privacy policies as it is not part of the
charter (please see the previous version of the draft
https://tools.ietf.org/html/draft-reddy-dprive-dprive-privacy-policy-01#section-6.2.2).
The privacy statements of content providers are much more complex than the
privacy statements by DNS server providers. The P3P policy expression
language is designed to allow sites to make complex assertions about how
they intended to make use of data related to users. I don't think such
complex assertions are required for DNS servers. The DNS server would have
a limited set of policies (see
https://tools.ietf.org/html/draft-ietf-dprive-bcp-op-12#section-6.1.1).

> Let me back up and be more specific as I'm probably slipping into too many
> generalities. For this objection, I'm referring to this draft:
> https://tools.ietf.org/html/draft-reddy-add-server-policy-selection-05
>
> There are other technical objections, but I'll forgo that as it seems to
> be randomizing my underlying main point: I don't think DNS is the right
> place to communicate server policy. This statement refers to the policies
> defined in Section 6.2.2. Here is a breakdown of the DNS scenarios my
> client faces that lead me to that conclusion:
>

Thanks for listing several DNS scenarios, it helps to explain the
usefulness of this draft.

>
> Scenario 1) the user has taken no configuration action at all, and as a
> DNS client, I have no knowledge of any servers. When the user joins Network
> A, it will recommend a DNS server to me. Regardless of its encryption
> support, regardless of its policies, I will use it. The alternative is to
> essentially not connect to the Internet. I'm saying this is unacceptable
> given the user asked me to connect to Network A. You and I may
> differentiate between "negotiate network connection" and "rely on DNS
> server for resolutions" but ours users don't. The Internet either works or
> it doesn't. The policy decision ("do I trust this network") happened
> _before_ the DNS client was asked to make a server decision.
>

A DNS server provisioned by Network A can be discovered securely or
insecurely. If the discovery mechanism is insecure, the DNS client can
validate the Policy Assertion Token signature (see Section 7) to
cryptographically assert the DNS server identity to identify it is
connecting to an encrypted DNS server hosted by a legal organization and
the user can also identify the encrypted DNS server hosted by a specific
organization (e.g.,ISP).  For example, an attacker can easily get a domain
name, domain-validated public certificate from a CA, host an Encrypted DNS
server and claim the best DNS privacy preservation policy.

The proposed technique prevents the client from connecting to an attacker’s
DNS server. In addition, the user can access the privacy link to determine
if the DNS server is privacy-friendly. If it is not privacy-friendly or
Encrypted DNS server is not discovered or the DNS server identity is not
cryptographically asserted , the user can take several actions like a) opt
not to visit privacy-sensitive domains b) switch to a different network.

>
> Scenario 2) the user has configured the DNS client to use a public
> resolver for all network connections. When the user joins Network A, it
> will recommend a DNS server to me. Regardless of its encryption support,
> regardless of its policies, I will not use it. This is because the user has
> already given me a clear signal to use a different server.
>

In Scenario 2), I don’t think any of the discovery mechanisms discussed in
the WG are of use.  The client can turn-off the DNS server discovery
mechanisms.

>
> Scenario 3) the user has configured the DNS client to find the DNS server
> closest to the zone being queried to cut down on recursive server
> dependencies, but has not given me a DNS server to bootstrap with.
>

I presume opportunistic encryption should meet the use case of scenario 3.

> When the user joins Network A, it will recommend a DNS server to me.
> Regardless of its encryption support, regardless of its policies, I will
> use it to bootstrap my designated server discoveries by sending it all
> queries then remembering designated servers as I discover them.
>

> Scenario 4) the user has configured the DNS client to find the DNS server
> closest to the zone being queried to cut down on recursive server
> dependencies, and has given me a DNS server to bootstrap with. When the
> user joins Network A, it will recommend a DNS server to me. Regardless of
> its encryption support, regardless of its policies, I will not use it. This
> is because I already have a server to bootstrap my designated server
> discoveries by sending it all queries then remembering designated servers
> as I discover them.
>

> Scenario 5) I'm in Scenario 2) or 4) meaning I already have DNS servers I
> will use in favor of the network recommendation, but the network blocks
> connection to those servers. Regardless of its encryption support,
> regardless of its policies, I will hard fail and my Internet connectivity
> will be compromised. My user told me to use specific servers, and allowing
> blocked connections to make me then use other servers would be a downgrade
> attack from my point of view.
>

Agreed but the user can be notified (for example using
draft-ietf-dnsop-extended-error) to decide whether to use the network
provided resolver or to switch to a different network. The user may want to
use the network provided resolver of an enterprise/home network because it
is privacy friendly and blocks access to malicious domains. The user may
opt to use a public server like Quad9 in a free Wi-Fi (like coffee shop) to
filter malware domains.

>
> Scenarios 1) and 2) are identical to 3) and 4) where the first two don't
> try to find designated zone servers but 3) and 4) do.
>
> The first two two scenario pairs pivot by zone. For example, they could be
> the general case ("."), or they could be more specific ("*.employer.com").
> I may be in Scenario 2) or 4) for "*.employer.com" and Scenario 1) or 3)
> for ".". This also pivots by network interface, but still can be boiled
> down to these two scenarios.
>

> That said, I do agree users should be provided the needed information to
> have made decisions about who to trust. The nuance I think I failed to
> articulate is that I don't see this as a DNS-specific problem; this is a
> network problem. By the time I'm connected to Network A, it's too late (in
> my opinion) to be trying to decide if the network recommendation can be
> trusted. I decided to trust it when I connected to the network (or decided
> not to by bringing my own configured DNS server).
>

The client needs evidence that the DNS server is indeed hosted by the
network and not by an attacker (especially when insecure discovery
mechanisms are used).

> The only thing left to decide is whether there's a server I trust more.
> That is trivially answered by whether the user configured my client with a
> different server to use.
>

We purposefully did not venture into the network policies (like to not
allow the client to use any other public server) and limited the policies
to resolver capabilities to assist in the selection decisions.

>
> This bring us back to that larger problem of having a network
> authoritatively articulate its own policies. I would support this draft
> being repurposed for that goal. I'd even follow it to whatever WG necessary
> to discuss the problem. I do agree there's value in a network communicating
> its policies to clients. I think DNS is the wrong place to solve it.
>
> If we can solve it in a more general mechanism, it could be reused to make
> captive portals far more user friendly and communicate other policies not
> specific to the DNS ("VPNs are forbidden" or "Internet is only accessible
> from 8AM to 9PM"). That mechanism does not belong in this WG.
>

If a DNS server blocks access to specific
domains, draft-ietf-dnsop-extended-error can be used to provide an error
response.

>
> The only thing I see value in at the DNS-specific level is ownership of a
> zone. That can be readily verified without needing to create a whole new
> chain of trust. Even claiming to filter a zone you don't own isn't really
> useful to me, since as illustrated above, it won't influence my server
> choice. I'll just have to consume the extended DNS error code and inform my
> user of the occurrence to let them decide if I should be using a different
> server.
>
> Related to this objection is this draft:
> https://tools.ietf.org/html/draft-btw-add-home-08
>
> From Section 7.2:
>
> I totally disagree. Per my scenarios outlined above, I don't need evidence
> of anything about a network recommendation because I won't need to act on
> it. I decided to trust the network recommendation the moment I joined the
> network without bringing my own DNS server. Hence I object to that draft as
> well.
>

Section 7.2 is added to address the threat model discussed in RFC3552 (see
https://tools.ietf.org/html/draft-btw-add-home-08#section-10.1).

>
> Formatting the DHCP and RA options to advertise support for encryption on
> a server, sure, but see below that this isn't strictly necessary (we can
> try DoT with no information beyond the IP address).
>
> Per Section 5.1 of the latest requirements draft, found here:
> https://www.ietf.org/id/draft-box-add-requirements-00.html#name-on-opportunistic-encryption
>
> > Performing opportunistic encrypted DNS does not require specific
> discovery mechanisms. > Section 4.1 of [RFC7858
> <https://www.ietf.org/id/draft-box-add-requirements-00.html#RFC7858>] already
> describes how to use DNS-over-TLS opportunistically.
>

I don't get the above response, the opportunistic profile is selected by
the user and has nothing to do with the discovery mechanism. The client can
detect the possibility of an attack in an opportunistic profile (see Table
1 and associated text in https://tools.ietf.org/html/rfc8310).

Cheers,

-Tiru

>
>
> Now securing the network recommendation so I know it didn't come from a
> local attacker... that's again interesting. However, in line with my
> objections above on the previous draft, this is not a DNS problem. This is
> a network problem far bigger than this WG. I do not support solving this
> problem at the DNS level because a more general mechanism is by far and
> away the cleaner answer.
>
> tl;dr: Trust in local network resources is a problem of far larger scope
> that DNS, and doesn't belong in this WG. In addition, I don't need the
> server policy info your draft describes to decide which server to send
> queries to. I already have the user controls I need to get their weigh in
> on that.
>

> *From:* tirumal reddy <[email-masked]>
> *Sent:* Wednesday, September 9, 2020 3:05 AM
> *To:* Tommy Jensen <[email-masked]>
> *Cc:* Michael Richardson <[email-masked]>; ADD Mailing list <
> [email-masked]>

---

From: Tommy Jensen <[email-masked]>
Date: Mon, 21 Sep 2020 19:13:11 +0000

Hey Tirumal,

Thanks for the responses.

> I don't think such complex assertions are required for DNS servers. The DNS server would have a limited set of policies

This limited list is still too complex for me, a DNS client, to go asking my user at run time about preference. In the "ISP needs users to use ISP servers for legal reasons" scenario, the ISP should have that conversation with customers out of band. Same goes for employer networks. Unknown networks such as those found traveling (hotels, airports, shops, etc.) should be untrusted by default and not promoted to trusted just because the network claims to have positive policies.

> Agreed but the user can be notified (for example using draft-ietf-dnsop-extended-error) to decide whether to use the network provided resolver or to switch to a different network.

> If a DNS server blocks access to specific domains, draft-ietf-dnsop-extended-error can be used to provide an error response.

I agree the extended error draft is useful in communicating a connected server's behavior. I guess in combination with my explanations about not needing server policy to make decisions about local servers, my opinion is the server-policy-selection draft isn't needed or at least goes way too far (for my use cases). I'll rest my feedback there as this would drive my responses to the other items redundantly.

Thanks,
Tommy

Sent: Wednesday, September 16, 2020 12:43 AM

Hi Tommy,

On Thu, 10 Sep 2020 at 01:24, Tommy Jensen <[email-masked]<mailto:[email-masked]>> wrote:
Apologies in advance for the novel below. I'm gathering you want me to be more specific, and I want to honor that.

> Michael and I have already clarified the objections you raised. As I have repeatedly said, the draft does not discuss any machine-parsable privacy claims (like the work in P3P).

My concerns weren't that the policies were machine parsable (though others did bring that up); my concern was and is you're expecting the user to understand it, or an AI to interpret it, for the DNS client to make final decisions about which server to use. In fact, machine parsable would make it more palatable for me (unlike others).

We removed machine-parsable privacy policies as it is not part of the charter (please see the previous version of the draft https://tools.ietf.org/html/draft-reddy-dprive-dprive-privacy-policy-01#section-6.2.2<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-reddy-dprive-dprive-privacy-policy-01%23section-6.2.2&data=02%7C01%7CJensen.Thomas%40microsoft.com%7Cef7fede74fd64c5fa27f08d85a1435c7%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637358390139138514&sdata=sOAD21UZlgTG4gkG3QfrmSUGDxmND2OlZndnPwuHyr8%3D&reserved=0>). The privacy statements of content providers are much more complex than the privacy statements by DNS server providers. The P3P policy expression language is designed to allow sites to make complex assertions about how they intended to make use of data related to users. I don't think such complex assertions are required for DNS servers. The DNS server would have a limited set of policies (see https://tools.ietf.org/html/draft-ietf-dprive-bcp-op-12#section-6.1.1<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-ietf-dprive-bcp-op-12%23section-6.1.1&data=02%7C01%7CJensen.Thomas%40microsoft.com%7Cef7fede74fd64c5fa27f08d85a1435c7%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637358390139148508&sdata=R3EJDO5YjZRR%2By80Vu7mqUGx6cIce77BfrPqcnilv%2Bk%3D&reserved=0>).

Let me back up and be more specific as I'm probably slipping into too many generalities. For this objection, I'm referring to this draft: https://tools.ietf.org/html/draft-reddy-add-server-policy-selection-05<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-reddy-add-server-policy-selection-05&data=02%7C01%7CJensen.Thomas%40microsoft.com%7Cef7fede74fd64c5fa27f08d85a1435c7%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637358390139148508&sdata=5KN4rbCRIotgFsLs8xrwzDAYl%2FHJYoU%2Bf%2BVN75tbcdo%3D&reserved=0>

Thanks for listing several DNS scenarios, it helps to explain the usefulness of this draft.

A DNS server provisioned by Network A can be discovered securely or insecurely. If the discovery mechanism is insecure, the DNS client can validate the Policy Assertion Token signature (see Section 7) to cryptographically assert the DNS server identity to identify it is connecting to an encrypted DNS server hosted by a legal organization and the user can also identify the encrypted DNS server hosted by a specific organization (e.g.,ISP).  For example, an attacker can easily get a domain name, domain-validated public certificate from a CA, host an Encrypted DNS server and claim the best DNS privacy preservation policy.

The proposed technique prevents the client from connecting to an attacker’s DNS server. In addition, the user can access the privacy link to determine if the DNS server is privacy-friendly. If it is not privacy-friendly or Encrypted DNS server is not discovered or the DNS server identity is not cryptographically asserted , the user can take several actions like a) opt not to visit privacy-sensitive domains b) switch to a different network.

In Scenario 2), I don’t think any of the discovery mechanisms discussed in the WG are of use.  The client can turn-off the DNS server discovery mechanisms.

Scenario 3) the user has configured the DNS client to find the DNS server closest to the zone being queried to cut down on recursive server dependencies, but has not given me a DNS server to bootstrap with.

When the user joins Network A, it will recommend a DNS server to me. Regardless of its encryption support, regardless of its policies, I will use it to bootstrap my designated server discoveries by sending it all queries then remembering designated servers as I discover them.

Agreed but the user can be notified (for example using draft-ietf-dnsop-extended-error) to decide whether to use the network provided resolver or to switch to a different network. The user may want to use the network provided resolver of an enterprise/home network because it is privacy friendly and blocks access to malicious domains. The user may opt to use a public server like Quad9 in a free Wi-Fi (like coffee shop) to filter malware domains.

The first two two scenario pairs pivot by zone. For example, they could be the general case ("."), or they could be more specific ("*.employer.com<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Femployer.com%2F&data=02%7C01%7CJensen.Thomas%40microsoft.com%7Cef7fede74fd64c5fa27f08d85a1435c7%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637358390139158500&sdata=6YP6lzhMiJ1yhoTfYAa42uJSoKUC5O%2FCTgAK08u%2BwEk%3D&reserved=0>"). I may be in Scenario 2) or 4) for "*.employer.com<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Femployer.com%2F&data=02%7C01%7CJensen.Thomas%40microsoft.com%7Cef7fede74fd64c5fa27f08d85a1435c7%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637358390139158500&sdata=6YP6lzhMiJ1yhoTfYAa42uJSoKUC5O%2FCTgAK08u%2BwEk%3D&reserved=0>" and Scenario 1) or 3) for ".". This also pivots by network interface, but still can be boiled down to these two scenarios.

That said, I do agree users should be provided the needed information to have made decisions about who to trust. The nuance I think I failed to articulate is that I don't see this as a DNS-specific problem; this is a network problem. By the time I'm connected to Network A, it's too late (in my opinion) to be trying to decide if the network recommendation can be trusted. I decided to trust it when I connected to the network (or decided not to by bringing my own configured DNS server).

The client needs evidence that the DNS server is indeed hosted by the network and not by an attacker (especially when insecure discovery mechanisms are used).

The only thing left to decide is whether there's a server I trust more. That is trivially answered by whether the user configured my client with a different server to use.

We purposefully did not venture into the network policies (like to not allow the client to use any other public server) and limited the policies to resolver capabilities to assist in the selection decisions.

If a DNS server blocks access to specific domains, draft-ietf-dnsop-extended-error can be used to provide an error response.

Related to this objection is this draft: https://tools.ietf.org/html/draft-btw-add-home-08<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-btw-add-home-08&data=02%7C01%7CJensen.Thomas%40microsoft.com%7Cef7fede74fd64c5fa27f08d85a1435c7%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637358390139168494&sdata=DPw78xJ1KZFTKUBNRtMXTovIIkcMP%2BZKxr%2F9OydXsrI%3D&reserved=0>

Section 7.2 is added to address the threat model discussed in RFC3552 (see https://tools.ietf.org/html/draft-btw-add-home-08#section-10.1<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-btw-add-home-08%23section-10.1&data=02%7C01%7CJensen.Thomas%40microsoft.com%7Cef7fede74fd64c5fa27f08d85a1435c7%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637358390139168494&sdata=c8FVssc%2FkcYR8DVhao3haBCP2yBdDRofrmMW4msxI%2Fg%3D&reserved=0>).

Per Section 5.1 of the latest requirements draft, found here: https://www.ietf.org/id/draft-box-add-requirements-00.html#name-on-opportunistic-encryption<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fid%2Fdraft-box-add-requirements-00.html%23name-on-opportunistic-encryption&data=02%7C01%7CJensen.Thomas%40microsoft.com%7Cef7fede74fd64c5fa27f08d85a1435c7%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637358390139178488&sdata=1I785mascsJtdilheyWiBjQZBJcqPkEziKuNk6SkaW8%3D&reserved=0>

> Performing opportunistic encrypted DNS does not require specific discovery mechanisms. > Section 4.1 of [RFC7858<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fid%2Fdraft-box-add-requirements-00.html%23RFC7858&data=02%7C01%7CJensen.Thomas%40microsoft.com%7Cef7fede74fd64c5fa27f08d85a1435c7%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637358390139178488&sdata=OrZboTE%2F3hz5WhW45tpeJPgjbnvPlky8ZgI5ZHVT5Mw%3D&reserved=0>] already describes how to use DNS-over-TLS opportunistically.

I don't get the above response, the opportunistic profile is selected by the user and has nothing to do with the discovery mechanism. The client can detect the possibility of an attack in an opportunistic profile (see Table 1 and associated text in https://tools.ietf.org/html/rfc8310<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Frfc8310&data=02%7C01%7CJensen.Thomas%40microsoft.com%7Cef7fede74fd64c5fa27f08d85a1435c7%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637358390139188485&sdata=d3ubKkJIU%2FHW50ShKmFRV3bWPZaL9UVsrF8sFAULliM%3D&reserved=0>).

Cheers,

-Tiru

Thanks,
Tommy

  DNS over HTTPS: https://aka.ms/dohblogpost<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Faka.ms%2Fdohblogpost&data=02%7C01%7CJensen.Thomas%40microsoft.com%7Cef7fede74fd64c5fa27f08d85a1435c7%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637358390139188485&sdata=dqRJ1mRmvmyxKKjcGLhT9YAEomCDzDibQKYKQRNT57w%3D&reserved=0>

________________________________
From: tirumal reddy <[email-masked]<mailto:[email-masked]>>
Sent: Wednesday, September 9, 2020 3:05 AM
To: Tommy Jensen <[email-masked]<mailto:[email-masked]>>
Cc: Michael Richardson <[email-masked]<mailto:[email-masked]>>; ADD Mailing list <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Add] [EXTERNAL] Re: ADD Requirements Draft

-Tiru

Thanks,
Tommy Jensen

---

From: tirumal reddy <[email-masked]>
Date: Wed, 23 Sep 2020 13:13:27 +0530

Hi Tommy,

Please see inline

On Tue, 22 Sep 2020 at 00:43, Tommy Jensen <[email-masked]>
wrote:

> > I don't think such complex assertions are required for DNS servers. The
> DNS server would have a limited set of policies
>
> This limited list is still too complex for me, a DNS client, to go asking
> my user at run time about preference. In the "ISP needs users to use ISP
> servers for legal reasons" scenario, the ISP should have that conversation
> with customers out of band. Same goes for employer networks.
>

The user need not be asked at run time, the user can instruct the client
about his/her preferences for DNS server selection. For example, if the
discovered encrypted DNS server does not meet the filtering requirements of
the user, the DNS client can take appropriate actions.  For example, the
action can be: use the discovered DNS server only to access internal-only
DNS names
and use another DNS server for public domains.

> Unknown networks such as those found traveling (hotels, airports, shops,
> etc.) should be untrusted by default and not promoted to trusted just
> because the network claims to have positive policies.
>

Agreed and the user has no way of identifying legitimate verses evil-twin.
Evil-twin is also possible in any well-known
network using a common/shared password and the cryptographic assertion
helps the client identify it connecting to an encrypted DNS server hosted
by a legal organization and the user can also identify the encrypted DNS
server hosted by a
specific organization (e.g.,ISP).

> provided resolver or to switch to a different network.
>
> I agree the extended error draft is useful in communicating a connected
> server's behavior. I guess in combination with my explanations about not
> needing server policy to make decisions about local servers, my opinion is
> the server-policy-selection draft isn't needed or at least goes way too far
> (for my use cases).
>

I'll rest my feedback there as this would drive my responses to the other
> items redundantly.
> *Sent:* Wednesday, September 16, 2020 12:43 AM
> https://tools.ietf.org/html/draft-reddy-dprive-dprive-privacy-policy-01#section-6.2.2
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-reddy-dprive-dprive-privacy-policy-01%23section-6.2.2&data=02%7C01%7CJensen.Thomas%40microsoft.com%7Cef7fede74fd64c5fa27f08d85a1435c7%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637358390139138514&sdata=sOAD21UZlgTG4gkG3QfrmSUGDxmND2OlZndnPwuHyr8%3D&reserved=0>).
> https://tools.ietf.org/html/draft-ietf-dprive-bcp-op-12#section-6.1.1
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-ietf-dprive-bcp-op-12%23section-6.1.1&data=02%7C01%7CJensen.Thomas%40microsoft.com%7Cef7fede74fd64c5fa27f08d85a1435c7%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637358390139148508&sdata=R3EJDO5YjZRR%2By80Vu7mqUGx6cIce77BfrPqcnilv%2Bk%3D&reserved=0>
> ).
>
>
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-reddy-add-server-policy-selection-05&data=02%7C01%7CJensen.Thomas%40microsoft.com%7Cef7fede74fd64c5fa27f08d85a1435c7%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637358390139148508&sdata=5KN4rbCRIotgFsLs8xrwzDAYl%2FHJYoU%2Bf%2BVN75tbcdo%3D&reserved=0>
>
> organization (e.g.,ISP).  For example, an attacker can easily get a
> domain name, domain-validated public certificate from a CA, host an
> Encrypted DNS server and claim the best DNS privacy preservation policy.
>
>
> The proposed technique prevents the client from connecting to an
> attacker’s DNS server. In addition, the user can access the privacy link to
> determine if the DNS server is privacy-friendly. If it is not
> privacy-friendly or Encrypted DNS server is not discovered or the DNS
> server identity is not cryptographically asserted , the user can take
> several actions like a) opt not to visit privacy-sensitive domains b)
> switch to a different network.
>
>
>
> the general case ("."), or they could be more specific ("*.employer.com
> <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Femployer.com%2F&data=02%7C01%7CJensen.Thomas%40microsoft.com%7Cef7fede74fd64c5fa27f08d85a1435c7%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637358390139158500&sdata=6YP6lzhMiJ1yhoTfYAa42uJSoKUC5O%2FCTgAK08u%2BwEk%3D&reserved=0>").
> I may be in Scenario 2) or 4) for "*.employer.com
> <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Femployer.com%2F&data=02%7C01%7CJensen.Thomas%40microsoft.com%7Cef7fede74fd64c5fa27f08d85a1435c7%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637358390139158500&sdata=6YP6lzhMiJ1yhoTfYAa42uJSoKUC5O%2FCTgAK08u%2BwEk%3D&reserved=0>"
> and Scenario 1) or 3) for ".". This also pivots by network interface, but
> still can be boiled down to these two scenarios.
>
>
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-btw-add-home-08&data=02%7C01%7CJensen.Thomas%40microsoft.com%7Cef7fede74fd64c5fa27f08d85a1435c7%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637358390139168494&sdata=DPw78xJ1KZFTKUBNRtMXTovIIkcMP%2BZKxr%2F9OydXsrI%3D&reserved=0>
>
> From Section 7.2:
>
> https://tools.ietf.org/html/draft-btw-add-home-08#section-10.1
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-btw-add-home-08%23section-10.1&data=02%7C01%7CJensen.Thomas%40microsoft.com%7Cef7fede74fd64c5fa27f08d85a1435c7%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637358390139168494&sdata=c8FVssc%2FkcYR8DVhao3haBCP2yBdDRofrmMW4msxI%2Fg%3D&reserved=0>
> ).
>
>
>
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fid%2Fdraft-box-add-requirements-00.html%23name-on-opportunistic-encryption&data=02%7C01%7CJensen.Thomas%40microsoft.com%7Cef7fede74fd64c5fa27f08d85a1435c7%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637358390139178488&sdata=1I785mascsJtdilheyWiBjQZBJcqPkEziKuNk6SkaW8%3D&reserved=0>
>
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fid%2Fdraft-box-add-requirements-00.html%23RFC7858&data=02%7C01%7CJensen.Thomas%40microsoft.com%7Cef7fede74fd64c5fa27f08d85a1435c7%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637358390139178488&sdata=OrZboTE%2F3hz5WhW45tpeJPgjbnvPlky8ZgI5ZHVT5Mw%3D&reserved=0>
> ] already describes how to use DNS-over-TLS opportunistically.
>
>
> 1 and associated text in https://tools.ietf.org/html/rfc8310
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Frfc8310&data=02%7C01%7CJensen.Thomas%40microsoft.com%7Cef7fede74fd64c5fa27f08d85a1435c7%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637358390139188485&sdata=d3ubKkJIU%2FHW50ShKmFRV3bWPZaL9UVsrF8sFAULliM%3D&reserved=0>
> ).
>
>
> Cheers,
>
> -Tiru
>
>
>
>
>
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Faka.ms%2Fdohblogpost&data=02%7C01%7CJensen.Thomas%40microsoft.com%7Cef7fede74fd64c5fa27f08d85a1435c7%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637358390139188485&sdata=dqRJ1mRmvmyxKKjcGLhT9YAEomCDzDibQKYKQRNT57w%3D&reserved=0>
>
>