Subject: [Add] Fwd: New Version Notification for draft-reddy-dprive-dprive-privacy-policy-00.txt

From: tirumal reddy <[email-masked]>
Date: Sat, 5 Oct 2019 13:17:59 +0530

Hi all,

We have published
https://tools.ietf.org/html/draft-reddy-dprive-dprive-privacy-policy-00 that
discusses a mechanism for the DNS server to communicate its
cryptographically signed privacy policy information to a DNS client. By
evaluating the DNS privacy policy and the signatory, the DNS client can
choose to  select or avoid a DoT/DoH server if it doesn't comply with the
client's privacy expectations.

Comments, suggestions and questions are more than welcome.

Cheers,
-Tiru

---------- Forwarded message ---------
From: <[email-masked]>
Date: Thu, 3 Oct 2019 at 15:59
Subject: New Version Notification for
draft-reddy-dprive-dprive-privacy-policy-00.txt
To: Tirumaleswar Reddy <[email-masked]>, Dan Wing <[email-masked]>,
Michael C. Richardson <[email-masked]>

A new version of I-D, draft-reddy-dprive-dprive-privacy-policy-00.txt
has been successfully submitted by Tirumaleswar Reddy and posted to the
IETF repository.

Name:           draft-reddy-dprive-dprive-privacy-policy
Revision:       00
Title:          DNS server privacy policy with assertion token
Document date:  2019-10-03
Group:          Individual Submission
Pages:          24
URL:
https://www.ietf.org/internet-drafts/draft-reddy-dprive-dprive-privacy-policy-00.txt
Status:
https://datatracker.ietf.org/doc/draft-reddy-dprive-dprive-privacy-policy/
Htmlized:
https://tools.ietf.org/html/draft-reddy-dprive-dprive-privacy-policy-00
Htmlized:
https://datatracker.ietf.org/doc/html/draft-reddy-dprive-dprive-privacy-policy

Abstract:
   Users want to control how their DNS queries are handled by DNS
   servers so they can configure their system to use DNS servers that
   comply with their privacy expectations.

   This document defines a mechanism for a DNS server to communicate its
   privacy policy to a DNS client.  This communication is
   cryptographically signed to attest to its authenticity.  By
   evaluating the DNS privacy policy and the signatory, the DNS client
   can choose a DNS server that best supports its desired privacy
   policies.  The privacy assertion token is particularly useful for
   DNS-over-TLS and DNS-over-HTTPS servers, both public resolvers and
   those discovered on the local network.

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

---

From: Paul Wouters <[email-masked]>
Date: Sat, 5 Oct 2019 13:58:01 -0400 (EDT)

On Sat, 5 Oct 2019, tirumal reddy wrote:

> We have published https://tools.ietf.org/html/draft-reddy-dprive-dprive-privacy-policy-00 that discusses a mechanism for the
> DNS server to communicate its cryptographically signed privacy policy information to a DNS client. By evaluating the DNS
> privacy policy and the signatory, the DNS client can choose to  select or avoid a DoT/DoH server if it doesn't comply with
> the client's privacy expectations.

Section 10 Security Considerations describes well why I think this is
not a good idea. Publishing a privacy policy in a computer consumable
way has no relationship to the actual DNS server's privacy policy
used.

This is not a technical wire problem to solve with an RFC. It is a
social-economic issue. Can we trust vendor X? And vendor X making
claims in JSON about this isn't useful from a technical point of
view, no matter how or where and with what such statements are
(self)signed.

It's a great topic for consumer advocay organisations, the EFF or
ACLU or EU commisioners. I do not think this is a technical problem
needing a technical standard from the IETF. And any automated
consumption of this leading to changed DNS client behaviour would
be dangerous.

Paul

---

From: tirumal reddy <[email-masked]>
Date: Mon, 7 Oct 2019 15:21:26 +0530

Hi Paul,

Please see inline

On Sat, 5 Oct 2019 at 23:28, Paul Wouters <[email-masked]> wrote:

> discusses a mechanism for the
> > DNS server to communicate its cryptographically signed privacy policy
> information to a DNS client. By evaluating the DNS
> > privacy policy and the signatory, the DNS client can choose to  select
> or avoid a DoT/DoH server if it doesn't comply with

No, the privacy policy also conveys a URL that points to the human readable
privacy policy formation of the DNS server. Public DNS resolvers have
published privacy policy statements (for example, see
https://developers.cloudflare.com/1.1.1.1/commitment-to-privacy/privacy-policy/firefox/).
If a firm violates the privacy claims, it will most likely face penalty
(similar to FTC imposing fine on facebook).

> view, no matter how or where and with what such statements are

Not really, you probably missed the privacy consideration section. User
consent is mandatory to use the discovered DoT/DoH servers, the section
says the following:

   Users are expected to indicate to their system in some way that they
   trust certain PAT signers (e.g., if working for Example, Inc., the
   user's system is configured to trust example.com signing the PAT).
   Separately, the user is expected to indicate to their system their
   PAT privacy requirements (e.g., logging, etc.).  By doing so, thee DNS
   client can automatically discover local DNS-over-TLS or DNS-over-
   HTTPS server, validate the PAT signature and check if the PAT
   complies with user's privacy needs, prior to using that DNS-over-TLS
   or DNS-over-HTTPS server for DNS queries.

Cheers,

-Tiru

---

From: Michael Richardson <[email-masked]>
Date: Mon, 07 Oct 2019 11:58:19 +0200

Paul Wouters <[email-masked]> wrote:
    >> We have
    >> published https://tools.ietf.org/html/draft-reddy-dprive-dprive-privacy-policy-00 that
    >> cryptographically signed privacy policy information to a DNS
    >> client. By evaluating the DNS privacy policy and the signatory, the
    >> DNS client can choose to  select or avoid a DoT/DoH server if it
    >> doesn't comply with the client's privacy expectations.

    > way has no relationship to the actual DNS server's privacy policy used.

    > claims in JSON about this isn't useful from a technical point of view,
    > no matter how or where and with what such statements are (self)signed.

Of course vendor X probably can't say anything trust-worthy about itself.
Depending upon one's relationship with X one may be in a position to believe
statements from it and take appropriate action.  For instance, if X is your
employer and your BYOD is paying attention to this statement, then you might
decide to refrain from visiting NSFW site FOO. Or decide to use LTE.

But, we anticipate that vendor X would have the implementation of their
policy reviewed regularly by some other endorser Y.  We have been in contact
with a few entities that have done these kinds of reviews of DoT systems in
the past, but at this point I don't think we have a shared understanding of
goals yet. 

Section 6...

   The PAT is cryptographically signed by the domain hosting the DNS
   server and OPTIONALLY BY A THIRD PARTY WHO PERFORMED PRIVACY AND
   SECURITY AUDIT OF THE DNS SERVER.  The privacy policy information
   will be attested using "Organization Validation" (OV) or "Extended
   Validation" (EV) certificates to avoid bad actors taking advantage of
   this mechanism to advertise DNS-over-TLS and DNS-over-HTTPS servers
   for illegitimate and fraudulent purposes meant to trick DNS clients
   into believing that they are using a legitimate DNS-over-TLS or DNS-
   over-HTTPS server hosted to provide privacy for DNS transactions.
   Alternatively, the DNS client will have to be configured to trust the
   leaf of the signer of the PAT object.  That is, trust of the signer
   MUST NOT be determined by validating the signer via the OS or browser
   trust chain because that would allow any arbitrary entity to operate
   a DNS server and assert any sort of privacy policy.

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

---

From: Paul Wouters <[email-masked]>
Date: Mon, 7 Oct 2019 09:32:34 -0400 (EDT)

On Mon, 7 Oct 2019, tirumal reddy wrote:

> No, the privacy policy also conveys a URL that points to the human readable privacy policy formation of the DNS
> server. Public DNS resolvers have published privacy policy statements (for example, see
> https://developers.cloudflare.com/1.1.1.1/commitment-to-privacy/privacy-policy/firefox/). If a firm violates the privacy
> claims, it will most likely face penalty (similar to FTC imposing fine on facebook). 

How and how would any enforcement system work for a variety of DNS
providers all over the world? ISPs? hotels? coffeeshops? Mobile
providers? Will there be an industry standard org? How will this
not devolve into government sanctioned mandatory DNS providers on
my mobile device?

> Not really, you probably missed the privacy consideration section. User consent is mandatory to use the discovered DoT/DoH
> servers, the section says the following:

How would that not become another "we use cookies, are you okay" screen for which I have no choice but to say "yes"?

>    user's system is configured to trust example.com signing the PAT).

How is that done on my iphone? If I install vendor X application, I
already have to trust them (and google or android, etc). Another screen
of "terms and services" the enduser is forced to scroll through?

>    or DNS-over-HTTPS server for DNS queries.

All of these things come down to one thing. Do you trust the DNS
provider or not. It's really a binary decision. Dividing this up
in a dozen options isn't helping the average user.

>       consumption of this leading to changed DNS client behaviour would

I'm still not convinced this statement is wrong. And additionally can
see some serious harmful effects into mandatory censorship if this kind
of system becomes mandatory on people's devices.

Paul

---

From: Michael Richardson <[email-masked]>
Date: Mon, 07 Oct 2019 16:56:40 +0200

> in a dozen options isn't helping the average user.

The purpose of this system is to unambiguously (and cryptographically)
identify the DNS provider for you, so that if you are an informed user, you
can make that binary decision.

Who will sign?  That's definitely a layer-8 problem, but it still needs to be
solved.

---

From: tirumal reddy <[email-masked]>
Date: Tue, 8 Oct 2019 16:26:45 +0100

On Mon, 7 Oct 2019 at 14:32, Paul Wouters <[email-masked]> wrote:

> > No, the privacy policy also conveys a URL that points to the human
> readable privacy policy formation of the DNS
> If a firm violates the privacy

Users may or may not trust the attached network and the DNS server provided
by the network (e.g, a public network). It is similar to the way users
disable VPN in specific trusted networks (e.g., Enterprise network) and VPN
is enabled by default in all other networks.

> consent is mandatory to use the discovered DoT/DoH
> How would that not become another "we use cookies, are you okay" screen
> for which I have no choice but to say "yes"?
>

No. If the privacy requirements of the endpoint are not met, the DNS client
can discard using the discovered DNS server in the attached network, and
connect to a public DNS resolver meeting the endpoint privacy preserving
data policy requirements.

The proposed mechanism also helps the DNS client to automatically learn
updates to the privacy claims by a DNS server and avoids the need for users
to periodically manually review the privacy statement.

> in a dozen options isn't helping the average user.

The privacy policy information helps make the decision whether the DNS
provider can be trusted or not.

> of system becomes mandatory on people's devices.

I disagree, the proposal helps the user to choose a DNS server that best
supports the desired privacy policies. DNS clients do not need to fallback
to clear text DNS, and can use the DoT/DoH server provided by the local
network. Further, it also provides a mechanism to securely signal to the
DNS client that the attached network performs DNS filtering.

Cheers,
-Tiru

---

From: Paul Wouters <[email-masked]>
Date: Wed, 9 Oct 2019 10:05:06 -0400 (EDT)

On Tue, 8 Oct 2019, tirumal reddy wrote:

> Users may or may not trust the attached network and the DNS server provided by the network (e.g, a public
> network). It is similar to the way users disable VPN in specific trusted networks (e.g., Enterprise network)
> and VPN is enabled by default in all other networks.  

The user can already do that, without any help from the local network.
If someone configures a VPN or a DoT/DoH, they do not need the local
network for anything except passing a captive portal. I don't understand
what you are adding here.

Trust relationships of networks are:

1) I don't need to trust them, so I don't
2) I am forced to trust them, so I do.

In the case of an enterprise network like 2) they can already
pre-install the CA certs I need to trust on connecting to the
network (see the IETF network do something similar there)

> No. If the privacy requirements of the endpoint are not met, the DNS client can discard using the discovered
> DNS server in the attached network, and connect to a public DNS resolver meeting the endpoint privacy
> preserving data policy requirements. 

Again, it is the other way around. Users should not need or want to
trust the local network. My laptop mostly connects to completely unknown
networks with zero trust _or_ a trusted enterprise network. What are
these networks that a user should "trust to filter or log their DNS for
them" ?

> The proposed mechanism also helps the DNS client to automatically learn updates to the privacy claims by a DNS
> server and avoids the need for users to periodically manually review the privacy statement. 

Again, this is fixing a problem that I do not think exists. Why should I
trust or not trust this network with DNS to begin with? Their privacy
policy update will not change that for me. Either, they were already too
weak for me to trust, so I don't care about their DNS privacy policy
update, or I trusted them already, in which case it seems I trust them
more than my own trusted DNS - AKA I'm forced to trust them (an
enterprise network).

> The privacy policy information helps make the decision whether the DNS provider can be trusted or not. 

No it does not. It can only tell me when I for sure cannot trust them.
Since I did not audit their logging, I can never be sure to trust them.

It's like saying a privacy policy will select whether I use HTTP:// or
HTTPS://. That is not the question. The question is why would I ever
use HTTP:// ?

> I disagree, the proposal helps the user to choose a DNS server that best supports the desired privacy
> policies.

I either have a really good DNS provider that I fully trust up my
sleeve, or I don't. If I do, I don't need the local network one.
If I don't, I have no choice but the use the local network one.

> DNS clients do not need to fallback to clear text DNS, and can use the DoT/DoH server provided by
> the local network.

Then why should I ever take a risk that this local network has a privacy
policy that does not actually match its implementation?

> Further, it also provides a mechanism to securely signal to the DNS client that the
> attached network performs DNS filtering. 

You cannot signal securely unless I have a trust anchor already on my
device that would be used. If this is a CA-type store of hundreds of
trust anchors, I cannot really trust them for this decision over a
personally selected known safe choice. If it is enterprise specific,
we already have mechanisms in place for securely obtaining updated DNS
mechanisms. Like via VPN using RFC 8598.

Paul

---

From: tirumal reddy <[email-masked]>
Date: Thu, 10 Oct 2019 16:03:41 +0100

> network (see the IETF network do something similar there)

I am referring to BYOD devices, BYOD will not have Enterprise root
certificate and cannot be provisioned with the Enterprise DoT/DoH server
using AD. The owner of the the BYOD has a choice whether to use the
Enterprise network provided DoT/DoH server or not.

> updates to the privacy claims by a DNS

I disagree, user needs to know whether his privacy requirements are met by
the local DNS server or public DNS server. If the public DNS server decides
to change the policy to sell user data to third-parties, the user would
want to move to a different DNS server.

> Since I did not audit their logging, I can never be sure to trust them.

An end-user cannot audit the privacy claims by any DNS provider including
the public DNS revolvers, and can possibility rely on the audits performed
by third parties (similar to way VPN providers use third party audits).
How does the user know the public DNS server has not made false privacy
claims ?

> supports the desired privacy
> > policies.
>

Local DNS server for several reasons, blocking malware and phishing,
enforce MUD rules to only allow intended communications to and from the IoT
devices. Several other reasons like "CDN endpoint selection" are listed in
https://tools.ietf.org/html/draft-reid-doh-operator-00

> policy that does not actually match its implementation?

Firefox falls back to clear text DNS because the local network has parental
control or DNS filtering. Android has an option to automatically use to the
local DoT server (opportunistic mode).

> personally selected known safe choice.

You may want to re-look into the Security and Privacy considerations
sections, we are not suggesting to rely on the hundreds of trusted anchors
on the browser/OS.

> If it is enterprise specific,

No, it is not specific to Enterprise IT manged devices. Managed network
security can be provided by ISPs, Home router integrated with security
service, BYOD policies in Enterprise networks etc.

Cheers,
-Tiru

---

From: Paul Wouters <[email-masked]>
Date: Thu, 10 Oct 2019 11:44:47 -0400 (EDT)

On Thu, 10 Oct 2019, tirumal reddy wrote:

> I am referring to BYOD devices, BYOD will not have Enterprise root certificate and cannot be provisioned with the
> Enterprise DoT/DoH server using AD. The owner of the the BYOD has a choice whether to use the Enterprise network
> provided DoT/DoH server or not. 

I have a BYOD device. My enterprise insists that they have limited
control via Google Mobile Device Management. They could dictate
to use certain DNS servers when connecting to certain wifi networks.

> I disagree, user needs to know whether his privacy requirements are met by the local DNS server or public DNS server.

The user cannot know if their privacy requirements are met, with or
without a signed XML statement from those parties. The user can only
hope. And since the user can only hope, it is by far safer to pick
a few or a single trusted party, than to hope each time they connect
to a new wifi network.

> If the public DNS server decides to change the policy to sell user data to third-parties, the user would want to move
> to a different DNS server. 

Sure. But a DNS server that is going to betray the user like that,
wouldn't be stopped by a signed XML file either.

> An end-user cannot audit the privacy claims by any DNS provider including the public DNS revolvers, and can possibility
> rely on the audits performed by third parties (similar to way VPN providers use third party audits).  How does the user
> know the public DNS server has not made false privacy claims ?

The user gains trust through a variety of non-technical, non-protocol
ways. News items, journalism, company reputation, prefering a non-profit
over an advertisetment company, entity history, people they know, etc.
Perhaps even through third party audits similar to mandated CAB/Forum
audits. Why do I not trust Sony or LinkedIn? Because they proved to
not deserve it in the past. Why do I trust cloudflare or PCH? Because
until now, they have proven to commit to their publicly announced
policies on their websites and as reported by other experts.

> Local DNS server for several reasons, blocking malware and phishing

How relevant is this in reality. Linux and OSX people and all mobile
phones do not run anti-malware software. Phising happens mostly via
email, which is unaffected by DoH/DoT and can still be done serverside,
and search engine results - which are curated by both search engines
(google filtering bad stuff) and browsers (eg mozilla preventing me to
go to a known malware site). None of this puts any requirements on my
DNS provider selection.

> , enforce MUD rules to only allow intended
> communications to and from the IoT devices.

non-mobile IoT devices hardly have a use for encrypted DNS to begin
with, and their MUD profiles should not allow it. Those should clearly
state "DNS to DHCP supplied resolver only" and "these domains related to my
services". Note that this isn't secure unless you could trust the DNS
answers, by either local transport or DNSSEC integrity.

> Several other reasons like "CDN endpoint selection" are listed
> in https://tools.ietf.org/html/draft-reid-doh-operator-00

CDN endpoint tracking is pretty risky from a privacy point of view. The
operator might want that, but the user that desires privacy might not.

> Firefox falls back to clear text DNS because the local network has parental control or DNS filtering. Android has an
> option to automatically use to the local DoT server (opportunistic mode). 

Sure, to support the enterprise/parental case voluntarilly. Again, there
is hardly a need to codify this in XML. Their users are forced to
comply. If I am at starbucks, I am not going to let firefox downgrade me
because of "parental control" desire, whether the instructions are XML
signed or not.

> You may want to re-look into the Security and Privacy considerations sections, we are not suggesting to rely on the
> hundreds of trusted anchors on the browser/OS. 

If it is a fundamental design item, it should have its own Section on
how to implement it. Not just waive some Security and Privacy
considerations.

> No, it is not specific to Enterprise IT manged devices. Managed network security can be provided by ISPs, Home router
> integrated with security service, BYOD policies in Enterprise networks etc. 

ISPs that are not a utility are defacto an enterprise network. Home
routers are parental control or 'enterprise' networks. BYOD devices
already have their methods to enforce various things on their respective
mobile OS platforms requiring no IETF standards. So your cases are still
really enterprise/parental control, where there are tight and mandatory
trust relationships. No signed XML needed.

As I said before, I haven't seen much upside on this. I do see downsides
when this kind of mandatory reconfiguring of my device privacy settings
are being forced at the ISP or national level to circumvent my privacy.
Maybe think of a Human Rights Consideration Section in the document too
as per RFC 8280 ?

Paul

---

From: Michael Richardson <[email-masked]>
Date: Fri, 11 Oct 2019 11:11:42 +0200

>> certificate and cannot be provisioned with the Enterprise DoT/DoH
    >> server using AD. The owner of the the BYOD has a choice whether to use
    >> the Enterprise network provided DoT/DoH server or not. 

    > control via Google Mobile Device Management. They could dictate to use
    > certain DNS servers when connecting to certain wifi networks.

And when you visit my enterprise as a consultant, you will permit my company
to do the same to your devices?

Maybe I should ask that different: will RedHat IT Security let me do that to
your company device, which is effectively a BYOD when it visits?

---

From: Paul Wouters <[email-masked]>
Date: Fri, 11 Oct 2019 09:54:31 -0400 (EDT)

> to do the same to your devices?

Either I don't need your network, and I won't. Or I need your network,
and I have no choice. No signed xml will change that.

> your company device, which is effectively a BYOD when it visits?

That is all defined in their mobile device management solution. They can
or cannot. Your signed xml will surely not make a difference to their
configuration they pushed onto my phone.

Paul

---

From: tirumal reddy <[email-masked]>
Date: Tue, 15 Oct 2019 16:31:46 +0530

On Thu, 10 Oct 2019 at 16:44, Paul Wouters <[email-masked]> wrote:

> certificate and cannot be provisioned with the
> > Enterprise DoT/DoH server using AD. The owner of the the BYOD has a
> choice whether to use the Enterprise network

No, Enterprise BYOD policy may not mandate MDM on the device. On the other
extreme, Enterprise BYOD policy can mandate the MDM on the BYOD to install
Enterprise root certificate.

> > I disagree, user needs to know whether his privacy requirements are met
> by the local DNS server or public DNS server.
>
> without a signed XML statement from those parties.

No, the proposed mechanism conveys signed privacy policy information to the
DNS client and the privacy policy contains a URL that points to the human
readable privacy policy formation of the DNS server. The privacy policy can
also be signed by a third party who performed privacy and security audit of
the DoT/DoH server.

Most importantly, user has to select specific networks to learn the privacy
claims of local DoT/DoH server and user
consent is required to use a locally-discovered DoT/DoH server. Further,
the client can learn updates to the privacy claims by the public DNS
server, and the user does not have to periodically manually review the
privacy statement of the DNS server.

> The user can only

The draft is not proposing to select the local DoT/DoH server in all
connected networks, see
https://tools.ietf.org/html/draft-reddy-dprive-dprive-privacy-policy-00#section-9

> > If the public DNS server decides to change the policy to sell user data
> to third-parties, the user would want to move

The point is the DNS provider becomes liable to penalties and will act as a
deterrent to lie (similar to the way FTC has imposed fine on Facebook).

>
> > An end-user cannot audit the privacy claims by any DNS provider
> including the public DNS revolvers, and can possibility
> > rely on the audits performed by third parties (similar to way VPN
> providers use third party audits).  How does the user

I suggest we stick the discussion to technical points, ISPs and Enterprise
networks can also publish DNS privacy policies. If you look into the
privacy claims from popular public DNS resolvers (see
https://dnsprivacy.org/wiki/display/DP/Comparison+of+policy+and+privacy+statements),
several claims like client IP address is not treated as PII, client IP
address is logged and identifiable data shared with partners may not meet
the privacy requirements of the user.

> phones do not run anti-malware software.

It is very much relevant today, Android and Windows run anti-malware
software, and the operating systems are suseptible to several attacks
including ransomware, crypto mining, data leakage etc. Several working
groups at IETF discuss endpoint and network security (sacm, i2snf, sfc,
dots etc.). On a side note, recently malware is discovered on iPhone, see
https://blog.malwarebytes.com/mac/2019/08/unprecedented-new-iphone-malware-discovered/
.

> Phising happens mostly via

No, see https://news.gandi.net/en/2019/07/how-to-fight-dns-hijacking/

> go to a known malware site). None of this puts any requirements on my

Several networks today use network security to filter malware, and do not
rely on the browser filtering capability.
What is the efficacy of these browsers to block malware sites ?

> answers, by either local transport or DNSSEC integrity.

The DNS requests from IoT devices are also privacy sensitive. For example,
domain names can be used to identify the IoT device type, make and model.
IoT devices would want to use DoT/DoH server capable of enforcing MUD rules
based on domain names.

> operator might want that, but the user that desires privacy might not.

The users may desire both privacy and performance, public revolvers like
google and opendns support edns-client-subnet.

> > Firefox falls back to clear text DNS because the local network has
> parental control or DNS filtering. Android has an
> is hardly a need to codify this in XML.

An attacker can spoof NXDOMAIN response to the canary domain, and the DNS
client will assume the network performs DNS filtering, and falls back to
clear text DNS. Further, the client does not know the privacy claims of the
network performing DNS filtering, and when the client falls back to clear
text DNS, DNS messages are susceptible to pervasive monitoring and spoofed
responses.

The proposed mechanism allows the client to use the local DoT/DoH server,
and avoids the need to fall back to clear text DNS.

> Their users are forced to

I don't think Firefox prompts the user to decide whether the DNS client can
fallback to clear text DNS or not. Anyways, our proposal expects user
consent is obtained to use the discovered DoT/DoH server.

Further, as discussed in
https://tools.ietf.org/html/draft-grover-add-policy-detection-00 it seems
network operator can mandate its resolver to be used as a condition of
using the network.

> sections, we are not suggesting to rely on the

Sure, will add a new section.

> security can be provided by ISPs, Home router

As I have explained previously BYOD with MDM is not used in several
Enterprise deployments and I have not seen MDM used by Home network
security. The proposal equips both the DNS client and user to learn the
privacy claims by the DNS server (both local and public) and choose to use
the DNS server or not.

> are being forced at the ISP or national level to circumvent my privacy.

I disagree, the draft is not proposing re-configuring the device privacy
settings. The client learns the DNS server privacy claims, and decides
whether to use the server or not.  The intent of the draft is meet the
user's privacy requirements, and not to circumvent them. The proposed
mechanism also helps the DNS client to automatically learn updates to the
privacy claims by a public DNS server and avoids the need for users
to periodically manually review the privacy statement.

> as per RFC 8280 ?

I don't understand why the above Section is required in the first place ?
If you can propose text, we can evaluate and update the draft.

Cheers,
-Tiru