Re: [Add] [EXTERNAL] Re: ADD Requirements Draft

[Tommy Jensen <[e-mail]>]

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

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

The latest in Windows Internet Protocols:

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

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

________________________________
From: tirumal reddy <[e-mail]>
Sent: Wednesday, September 16, 2020 12:43 AM
To: Tommy Jensen <[e-mail]>
Cc: Michael Richardson <[e-mail]>; ADD Mailing list <[e-mail]>
Subject: Re: [Add] [EXTERNAL] Re: ADD Requirements Draft


Hi Tommy,


Appreciate the detailed feedback. Please see inline

On Thu, 10 Sep 2020 at 01:24, Tommy Jensen <[e-mail]<mailto:[e-mail]>> wrote:
Apologies in advance for the novel below. I'm gathering you want me to be 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<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>

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


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<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:

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


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



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




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

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

The latest in Windows Internet Protocols:

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

  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 <[e-mail]<mailto:[e-mail]>>
Sent: Wednesday, September 9, 2020 3:05 AM
To: Tommy Jensen <[e-mail]<mailto:[e-mail]>>
Cc: Michael Richardson <[e-mail]<mailto:[e-mail]>>; ADD Mailing list <[e-mail]<mailto:[e-mail]>>
Subject: Re: [Add] [EXTERNAL] Re: ADD Requirements Draft

On Tue, 8 Sep 2020 at 22:00, Tommy Jensen <[e-mail]<mailto:[e-mail]>> wrote:
> 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?

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



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

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 <[e-mail]<mailto:[e-mail]>>
Sent: Sunday, September 6, 2020 9:53 AM
To: Tommy Jensen <[e-mail]<mailto:[e-mail]>>; tirumal reddy <[e-mail]<mailto:[e-mail]>>; ADD Mailing list <[e-mail]<mailto:[e-mail]>>
Subject: Re: [Add] [EXTERNAL] Re: ADD Requirements Draft


Tommy Jensen <[e-mail]<mailto:[e-mail]>> 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 <[e-mail]<mailto:[e-mail]>>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide