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

[tirumal reddy <[e-mail]>]

Hi Tommy,

Please see inline

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

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

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


> > 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]>
> 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]>
> *Sent:* Wednesday, September 9, 2020 3:05 AM
> *To:* Tommy Jensen <[e-mail]>
> *Cc:* Michael Richardson <[e-mail]>; ADD Mailing list <
> [e-mail]>
> *Subject:* Re: [Add] [EXTERNAL] Re: ADD Requirements Draft
>
> On Tue, 8 Sep 2020 at 22:00, Tommy Jensen <[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]>
> *Sent:* Sunday, September 6, 2020 9:53 AM
> *To:* Tommy Jensen <[e-mail]>; tirumal reddy <
> [e-mail]>; ADD Mailing list <[e-mail]>
> *Subject:* Re: [Add] [EXTERNAL] Re: ADD Requirements Draft
>
>
> Tommy Jensen <[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]>   . o O ( IPv6 IøT consulting )
>            Sandelman Software Works Inc, Ottawa and Worldwide
>
>
>
>
>