Subject: [Add] Fwd: New Version Notification for draft-schinazi-httpbis-doh-preference-hints-02.txt

From: Nick Sullivan <[email-masked]>
Date: Mon, 13 Jul 2020 13:25:53 -0700

ADD Working Group,

This is to inform you of a new submission of the doh-preference-hints
document. This document was originally intended for the HTTPbis working
group, but we were directed to the ADD group as a more appropriate venue to
discuss it. Our intention is to put this document up for consideration to
be adopted as a working group item.

Nick, David, Jesse

---------- Forwarded message ---------
From: <[email-masked]>
Date: Mon, Jul 13, 2020 at 12:36 PM
Subject: New Version Notification for
draft-schinazi-httpbis-doh-preference-hints-02.txt
To: Jesse Kipp <[email-masked]>, Nick Sullivan <[email-masked]>,
David Schinazi <[email-masked]>

A new version of I-D, draft-schinazi-httpbis-doh-preference-hints-02.txt
has been successfully submitted by David Schinazi and posted to the
IETF repository.

Name:           draft-schinazi-httpbis-doh-preference-hints
Revision:       02
Title:          DoH Preference Hints for HTTP
Document date:  2020-07-13
Group:          Individual Submission
Pages:          8
URL:
https://www.ietf.org/internet-drafts/draft-schinazi-httpbis-doh-preference-hints-02.txt
Status:
https://datatracker.ietf.org/doc/draft-schinazi-httpbis-doh-preference-hints/
Htmlized:
https://tools.ietf.org/html/draft-schinazi-httpbis-doh-preference-hints-02
Htmlized:
https://datatracker.ietf.org/doc/html/draft-schinazi-httpbis-doh-preference-hints
Diff:
https://www.ietf.org/rfcdiff?url2=draft-schinazi-httpbis-doh-preference-hints-02

Abstract:
   When using a publicly available DNS-over-HTTPS (DoH) server, some
   clients may suffer poor performance when the authoritative DNS server
   is located far from the DoH server.  For example, a publicly
   available DoH server provided by a Content Delivery Network (CDN)
   should be able to resolve names hosted by that CDN with good
   performance but might take longer to resolve names provided by other
   CDNs, or might provide suboptimal results if that CDN is using DNS-
   based load balancing and returns different address records depending
   or where the DNS query originated from.  This document attempts to
   lessen these issues by allowing the web server to indicate to the
   client which DoH server can best resolve its addresses.  This
   document defines an HTTP header field that enables web host operators
   to inform user agents of the preferred DoH servers to use for
   subsequent DNS lookups for the host's domain.

   Discussion of this work is encouraged to happen on the ADD IETF
   mailing list [email-masked] or on the GitHub repository which contains
   the draft: https://github.com/DavidSchinazi/draft-httpbis-doh-
   preference-hints.

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: Tommy Pauly <[email-masked]>
Date: Sun, 26 Jul 2020 13:43:47 -0700

Hi Nick,

I definitely like the optimizations that this mechanism is looking for—specifically, binding resolutions to a DoH server that is hosted by the same CDN that provides the desired web content. This not only allows for faster resolution (based on being near the authoritative) and faster connections (based on tailoring DNS answers for the client’s subnet) as you describe, but has some privacy benefits in limiting the number of parties involved in subsequent resolutions.

The specific mechanism does cause some concerns for me, however.

I know this is just a hint, but the weak relationship between this hint and the DNS may cause issues. The DoH preference hint is one-way only, and determined only by the entity that is generating HTTP headers for a given URL. This means that neither the operator of the DNS zone for the origin, nor the target DoH resolver, have any way to influence or validate this hint. It is possible that these are all the same entity (Google content in a google.com zone pointing to 8.8.8.8), but that’s not guaranteed. Nothing stops any website from providing a hint to direct clients to whichever DoH server it wants, for as long as it wants. I have no problem with HTTPS content helping to confirm that the owner of the cert for a name agrees to using a specific DoH server (see https://www.ietf.org/id/draft-pauly-add-resolver-discovery-01.html#name-confirmation-of-designation), but the primary control over DNS routing should lie with the operator of the DNS zone in order to get the optimizations described in the document.

It also seems like it would be more optimal for this indication of DoH server to be expressed for a set of names (names within a zone, or all subdomains, etc), rather than just a single host name. The text limits any hint to only apply to one name, which is good because the hint could otherwise cause problems for an entire zone, but means that the benefit is limited. If every YouTube video has a unique hostname that is only resolved once, wouldn’t it be better to learn that I should use 8.8.8.8 for all YouTube names?

What would the client behavior for this header be if there is a redirect? For any content that uses redirects, I assume these hints must be ignored?

Best,
Tommy

> On Jul 13, 2020, at 1:25 PM, Nick Sullivan <nick=[email-masked]> wrote:
> 
> ADD Working Group,
> 
> This is to inform you of a new submission of the doh-preference-hints document. This document was originally intended for the HTTPbis working group, but we were directed to the ADD group as a more appropriate venue to discuss it. Our intention is to put this document up for consideration to be adopted as a working group item.
> 
> Nick, David, Jesse
> 
> From: <[email-masked] <mailto:[email-masked]>>
> Subject: New Version Notification for draft-schinazi-httpbis-doh-preference-hints-02.txt
> To: Jesse Kipp <[email-masked] <mailto:[email-masked]>>, Nick Sullivan <[email-masked] <mailto:[email-masked]>>, David Schinazi <[email-masked] <mailto:[email-masked]>>
> 
> 
> 
> URL:            https://www.ietf.org/internet-drafts/draft-schinazi-httpbis-doh-preference-hints-02.txt <https://www.ietf.org/internet-drafts/draft-schinazi-httpbis-doh-preference-hints-02.txt>
> Status:         https://datatracker.ietf.org/doc/draft-schinazi-httpbis-doh-preference-hints/ <https://datatracker.ietf.org/doc/draft-schinazi-httpbis-doh-preference-hints/>
> Htmlized:       https://tools.ietf.org/html/draft-schinazi-httpbis-doh-preference-hints-02 <https://tools.ietf.org/html/draft-schinazi-httpbis-doh-preference-hints-02>
> Htmlized:       https://datatracker.ietf.org/doc/html/draft-schinazi-httpbis-doh-preference-hints <https://datatracker.ietf.org/doc/html/draft-schinazi-httpbis-doh-preference-hints>
> Diff:           https://www.ietf.org/rfcdiff?url2=draft-schinazi-httpbis-doh-preference-hints-02 <https://www.ietf.org/rfcdiff?url2=draft-schinazi-httpbis-doh-preference-hints-02>
> 
> Abstract:
>    mailing list [email-masked] <mailto:[email-masked]> or on the GitHub repository which contains
>    the draft: https://github.com/DavidSchinazi/draft-httpbis-doh- <https://github.com/DavidSchinazi/draft-httpbis-doh->
>    preference-hints.
> 
> 
> 
> 
> until the htmlized version and diff are available at tools.ietf.org <http://tools.ietf.org/>.
> 
> The IETF Secretariat
> 
> 
> -- 
> Add mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/add

---

From: David Schinazi <[email-masked]>
Date: Sun, 26 Jul 2020 16:02:57 -0700

Hi Tommy,

Thanks for your comments! Responses inline.

On Sun, Jul 26, 2020 at 1:43 PM Tommy Pauly <[email-masked]> wrote:

> Hi Nick,
>
> I definitely like the optimizations that this mechanism is looking
> for—specifically, binding resolutions to a DoH server that is hosted by the
> same CDN that provides the desired web content. This not only allows for
> faster resolution (based on being near the authoritative) and faster
> connections (based on tailoring DNS answers for the client’s subnet) as you
> describe, but has some privacy benefits in limiting the number of parties
> involved in subsequent resolutions.
>
> I know this is just a hint, but the weak relationship between this hint
> and the DNS may cause issues. The DoH preference hint is one-way only,
> and determined only by the entity that is generating HTTP headers for a
> given URL. This means that neither the operator of the DNS zone for the
> origin, nor the target DoH resolver, have any way to influence or validate
> this hint. It is possible that these are all the same entity (Google
> content in a google.com zone pointing to 8.8.8.8), but that’s not
> guaranteed. Nothing stops any website from providing a hint to direct
> clients to whichever DoH server it wants, for as long as it wants. I have
> no problem with HTTPS content helping to confirm that the owner of the cert
> for a name agrees to using a specific DoH server (see
> https://www.ietf.org/id/draft-pauly-add-resolver-discovery-01.html#name-confirmation-of-designation),
> but the primary control over DNS routing should lie with the operator of
> the DNS zone in order to get the optimizations described in the document.
>

Your statement that "the primary control over DNS routing should lie with
the operator of the DNS zone" contradicts existing best practices. Today,
when my devices connect to a first hop network (Wi-Fi, cellular, etc.),
that network will almost always provide me with a list of DNS servers,
using mechanisms such as IPv6 RAs or DHCP. My device then proceeds to route
its DNS based on that information. This control over DNS routing does not
lie with the operator of the DNS zone, it lies with the first hop network
operator - or with the device administrator who can override DNS
configuration. Our proposal allows HTTP server operators to influence DNS
routing, and your proposal allows DNS zone operators to influence DNS
routing, but neither of those solutions is "more correct" based on how DNS
works today.

> It also seems like it would be more optimal for this indication of DoH
> server to be expressed for a set of names (names within a zone, or
> all subdomains, etc), rather than just a single host name. The text limits
> any hint to only apply to one name, which is good because the hint
> could otherwise cause problems for an entire zone, but means that the
> benefit is limited. If every YouTube video has a unique hostname that is
> only resolved once, wouldn’t it be better to learn that I should use
> 8.8.8.8 for all YouTube names?
>

Definitely agree. We could change the draft to allow these hints to
influence other hostnames that are covered by the same TLS certificate,
though we'd have to consider the security implications carefully.

> What would the client behavior for this header be if there is a redirect?
> For any content that uses redirects, I assume these hints must be ignored?
>

I don't think HTTP redirects should have any impact on the DoH-Preference
header. If https://foo.example.com/abc returns a 301 redirect to
https://bar.example.net/def it can still tell the client that subsequent
resolutions for foo.example.com can be made to a given DoH server. The key
distinction here is that the DoH-Preference operates at the scope of a
hostname, whereas an HTTP redirect operates at the scope of a given request
(i.e. it's specific to the full path, not just the hostname).

Cheers,
David

Best,
> Tommy
>
> On Jul 13, 2020, at 1:25 PM, Nick Sullivan <
> nick=[email-masked]> wrote:
>
> ADD Working Group,
>

---

From: Paul Vixie <[email-masked]>
Date: Sun, 26 Jul 2020 23:33:17 +0000

On Sunday, 26 July 2020 23:02:57 UTC David Schinazi wrote:
> ...

i am not tommy, but i have a comment.

> the operator of the DNS zone" contradicts existing best practices. ...

this is the hardest truth i've seen in this forum. please disagree out loud if 
you disagree, because it's the fundamental difference between user-centric, 
app-centric, and service-centric networking "on one side", and 
decentralization and autonomy "on the other side".

we who secure things, do it by controlling what an app can reach. sometimes we 
do it with a "dns firewall". we will continue, at any and all costs, even if 
it means fighting an unwanted cold war against app makers, dns zone operators, 
service providers, governments, and activists.

dns in particular is a distributed, hierarchical, autonomous, reliable, and 
coherent database. operators of dns zones will not, at the end of the day, 
reduce the autonomy of recursive server operators, edge network operators, or 
system administrators. that's where we are now, and that's where this ends. we 
should talk about how we remain here, because that can be more costly or less.

see also: http://www.circleid.com/posts/20100728_taking_back_the_dns/

and this: https://www.youtube.com/watch?v=ChyrkCFpkNg

and maybe this: https://dnsrpz.info/

-- 
Paul

---

From: Rob Sayre <[email-masked]>
Date: Sun, 26 Jul 2020 19:18:06 -0700

> service providers, governments, and activists.

Whatever one might think of these aims, they don't actually work.

Either you can install PKI software on a device, or you can't. The rest of
this is stupid.

thanks,
Rob

---

From: Adam Roach <[email-masked]>
Date: Sun, 26 Jul 2020 21:30:05 -0500

On 7/26/2020 6:33 PM, Paul Vixie wrote:
> you disagree

Only because you asked: the status quo is, of course, more nuanced than 
this. Onion routing, VPNs, HTTP proxies, and SOCKS proxies provide some 
of the most obvious counterexamples.

/a

---

From: Ted Lemon <[email-masked]>
Date: Sun, 26 Jul 2020 22:40:30 -0400

On Jul 26, 2020, at 10:30 PM, Adam Roach <[email-masked]> wrote:
> Only because you asked: the status quo is, of course, more nuanced than this. Onion routing, VPNs, HTTP proxies, and SOCKS proxies provide some of the most obvious counterexamples.

Let’s be honest here: the error is in asserting that there is such a thing as primary control over DNS routing. In fact, various entities have control over DNS routing. These controls may interact well, or poorly. These may accomplish the goals of some combination of the device owner, the network operator, the totalitarian government, the advertising service, the malware, etc.

Personally I think the IETF has a strong interest in serving the needs of the end user. Different mechanisms may accomplish different aspects of what the end user wants. In some cases these will be in conflict, even without trying to imagine that someone other than the end user ought to be the primary stakeholder.

Our job is not to pretend that things exist that do not. It’s to deal with the situation as it actually is.

---

From: Rob Sayre <[email-masked]>
Date: Sun, 26 Jul 2020 19:48:07 -0700

On Sun, Jul 26, 2020 at 7:40 PM Ted Lemon <[email-masked]> wrote:

> Let’s be honest here: the error is in asserting that there is such a thing
> as primary control over DNS routing.

Yes. And, conflating "security" with this imaginary power is also magical
thinking.

thanks,
Rob

---

From: Tommy Pauly <[email-masked]>
Date: Sun, 26 Jul 2020 22:52:12 -0700

> On Jul 26, 2020, at 4:03 PM, David Schinazi <[email-masked]> wrote:
> 
> Hi Tommy,
> 
> Your statement that "the primary control over DNS routing should lie with the operator of the DNS zone" contradicts existing best practices.
> Today, when my devices connect to a first hop network (Wi-Fi, cellular, etc.), that network will almost always provide me with a list of DNS servers, using mechanisms such as IPv6 RAs or DHCP. My device then proceeds to route its DNS based on that information. This control over DNS routing does not lie with the operator of the DNS zone, it lies with the first hop network operator - or with the device administrator who can override DNS configuration. Our proposal allows HTTP server operators to influence DNS routing, and your proposal allows DNS zone operators to influence DNS routing, but neither of those solutions is "more correct" based on how DNS works today.

Yes, of course the first hop network operator generally provides the actual view of DNS content. And many other entities influence the actual view. That’s not the kind of control I was referring to. 

To clarify this point, which I see has been taken a bit out of context, I was referring to the choice between having the owner of a name indicate its DNS resolver designation via information in its DNS records and having that entity indicate this designation purely through an HTTP response to a non-DNS request. If “example.com” wants to indicate that DNS queries can be optimized if they are directed to “doh.example.com”, this control should generally be given to the DNS zone for example.com instead of the content HTTP server, since the DNS zone operator knows more context about its own DNS configuration.

One of the premises your document describes us that there can be optimization if the preferred DoH server is closer to or related to the authoritative DNS server. This is the kind of information that makes sense to keep related to DNS records. Let’s say that I have a large number of names under example.com. Every name under example.com originally indicates a preference for doh.dns.example.com. Then, at some point, I change how names under foo.example.com are managed such that another DoH server should be preferred (maybe a change of CDN, etc). If the preference had been previously marked using HTTP headers, this DNS-centric change could mean I need to track down every HTTP server and make sure the response is updated; and since this hint is entirely request-specific, there could be paths that redirect in non-obvious ways, and updates could be missed. If the preference is communicated in DNS records, however, I can perform the update across all the records in the appropriate zone.

I totally understand that there are deployments, like Google’s, for which it is more convenient to use a hint in HTTP, since you can update that easily and uniformly, and you can ignore multi-CDN concerns, etc. But a standard mechanism that is based in the DNS might avoid a lot of headache and misconfiguration risks for other common deployments.

> Definitely agree. We could change the draft to allow these hints to influence other hostnames that are covered by the same TLS certificate, though we'd have to consider the security implications carefully.
>  
> I don't think HTTP redirects should have any impact on the DoH-Preference header. If https://foo.example.com/abc returns a 301 redirect to https://bar.example.net/def it can still tell the client that subsequent resolutions for foo.example.com can be made to a given DoH server. The key distinction here is that the DoH-Preference operates at the scope of a hostname, whereas an HTTP redirect operates at the scope of a given request (i.e. it's specific to the full path, not just the hostname).

Okay, that’s good to clarify—you may want to mention that in the doc. The fact that the DoH preference operates at the scope of the hostname and not the request is another reason I’d prefer to see it tied to something about the hostname (a DNS record, or at the very least, a well-known URL off the hostname). What happens if the client receives different preference headers across different responses?

Best,
Tommy

>>> To: Jesse Kipp <[email-masked]>, Nick Sullivan <[email-masked]>, David Schinazi <[email-masked]>
>>> 
>>> 
>>> 
>>> URL:            https://www.ietf.org/internet-drafts/draft-schinazi-httpbis-doh-preference-hints-02.txt
>>> Status:         https://datatracker.ietf.org/doc/draft-schinazi-httpbis-doh-preference-hints/
>>> Htmlized:       https://tools.ietf.org/html/draft-schinazi-httpbis-doh-preference-hints-02
>>> Htmlized:       https://datatracker.ietf.org/doc/html/draft-schinazi-httpbis-doh-preference-hints
>>> Diff:           https://www.ietf.org/rfcdiff?url2=draft-schinazi-httpbis-doh-preference-hints-02
>>> 
>>> Abstract:

---

From: Paul Vixie <[email-masked]>
Date: Mon, 27 Jul 2020 07:54:20 +0000

On Monday, 27 July 2020 02:30:05 UTC Adam Roach wrote:
> > this is the hardest truth i've seen in this forum. please disagree out
> > loud if you disagree
> 

privately operated edge networks make investment choices around risks and 
costs. since the internet edge was 100% private before commercialization and 
privatization began, i think it's a century too soon to exclude that model.

if you want to try those counterexamples from within some corporate, military, 
government, and other non-public-access non-ISP networks such as the one i 
operate for my family, you'll be treated as an attacker. that won't change.

i beg you, please remember that i'm not talking about public-access networks 
where the end users are receiving connectivity as a service. rather, networks 
operated by the owner of all the devices plugged into them. we are legion.

-- 
Paul

---

From: Rob Sayre <[email-masked]>
Date: Mon, 27 Jul 2020 08:26:00 -0700

> operated by the owner of all the devices plugged into them. we are legion.

I'd suggest using management software.

thanks,
Rob

---

From: Andrew Campling <[email-masked]>
Date: Mon, 27 Jul 2020 18:00:06 +0000

Can I check with you both, for your respective I-Ds, for clarification:

  *   Is personal data shared and/or processed by resolvers determined mechanistically, as opposed to being determined by a setting from the user device?  If so, what options are there for the owner of that data to give their consent to it being shared in this way?
  *   Can the device owner set a universal policy that might disable or restrict the mechanisms that you are proposing?

In other words, what control, if any, does the user have over any of this?

Andrew

From: Tommy Pauly <[email-masked]>
Sent: 26 July 2020 21:44
To: Nick Sullivan <nick=[email-masked]>
Cc: ADD Mailing list <[email-masked]>; David Schinazi <[email-masked]>; Jesse Kipp <[email-masked]>
Subject: Re: [Add] New Version Notification for draft-schinazi-httpbis-doh-preference-hints-02.txt

Hi Nick,

I know this is just a hint, but the weak relationship between this hint and the DNS may cause issues. The DoH preference hint is one-way only, and determined only by the entity that is generating HTTP headers for a given URL. This means that neither the operator of the DNS zone for the origin, nor the target DoH resolver, have any way to influence or validate this hint. It is possible that these are all the same entity (Google content in a google.com<http://google.com> zone pointing to 8.8.8.8), but that’s not guaranteed. Nothing stops any website from providing a hint to direct clients to whichever DoH server it wants, for as long as it wants. I have no problem with HTTPS content helping to confirm that the owner of the cert for a name agrees to using a specific DoH server (see https://www.ietf.org/id/draft-pauly-add-resolver-discovery-01.html#name-confirmation-of-designation), but the primary control over DNS routing should lie with the operator of the DNS zone in order to get the optimizations described in the document.

Best,
Tommy

On Jul 13, 2020, at 1:25 PM, Nick Sullivan <nick=[email-masked]<mailto:nick=[email-masked]>> wrote:

ADD Working Group,

Nick, David, Jesse

---------- Forwarded message ---------
From: <[email-masked]<mailto:[email-masked]>>
Date: Mon, Jul 13, 2020 at 12:36 PM
Subject: New Version Notification for draft-schinazi-httpbis-doh-preference-hints-02.txt
To: Jesse Kipp <[email-masked]<mailto:[email-masked]>>, Nick Sullivan <[email-masked]<mailto:[email-masked]>>, David Schinazi <[email-masked]<mailto:[email-masked]>>

Abstract:

   Discussion of this work is encouraged to happen on the ADD IETF
   mailing list [email-masked]<mailto:[email-masked]> or on the GitHub repository which contains
   the draft: https://github.com/DavidSchinazi/draft-httpbis-doh-
   preference-hints.

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<http://tools.ietf.org/>.

The IETF Secretariat

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

---

From: David Schinazi <[email-masked]>
Date: Mon, 27 Jul 2020 11:22:18 -0700

Hi Andrew,

I think user control is out of scope of both drafts. Both proposals provide
a way
for server deployments to indicate a preference to the client. One involves
an
HTTP header, the other involves a DNS record, but conceptually they're both
hints: "I offer this resolver which might work better than your default one
for
this hostname". I think this is pretty much in line with recent IETF
practices,
we don't define how a browser builds its user preferences UI. My expectation
is that browsers that implement these hints will most likely decide to also
implement a UI toggle to let users disable this feature if they prefer.
(And note
that in my statement above, "browser" can be replaced by "operating system"
or "application" depending on the use case).

David

On Mon, Jul 27, 2020 at 11:00 AM Andrew Campling
<[email-masked]> wrote:

>    - Is personal data shared and/or processed by resolvers determined
>    mechanistically, as opposed to being determined by a setting from the user
>    device?  If so, what options are there for the owner of that data to give
>    their consent to it being shared in this way?
>    - Can the device owner set a universal policy that might disable or
>    restrict the mechanisms that you are proposing?
>
>
>
> *Andrew *
> *From:* Tommy Pauly <[email-masked]>
> *Sent:* 26 July 2020 21:44
> *To:* Nick Sullivan <nick=[email-masked]>
> *Cc:* ADD Mailing list <[email-masked]>; David Schinazi <
> [email-masked]>; Jesse Kipp <[email-masked]>
> *Subject:* Re: [Add] New Version Notification for

---

From: Paul Vixie <[email-masked]>
Date: Mon, 27 Jul 2020 20:51:34 +0000

On Monday, 27 July 2020 15:26:00 UTC Rob Sayre wrote:
> > i beg you, please remember that i'm not talking about public-access
> > networks where the end users are receiving connectivity as a service.
> > rather, networks operated by the owner of all the devices plugged
> > into them. we are legion.
> 

since intruders, malware, poisoned supply chains, and BYOD will not be 
participating in "management software", that recommendation is off-topic. a 
network which is only as secure as its least-secure node is _not secure_.

-- 
Paul

---

From: Rob Sayre <[email-masked]>
Date: Mon, 27 Jul 2020 13:55:02 -0700

> network which is only as secure as its least-secure node is _not secure_.

It doesn't seem like your idea of "security" aligns with IETF consensus.

thanks,
Rob

---

From: Paul Vixie <[email-masked]>
Date: Mon, 27 Jul 2020 21:18:29 +0000

On Monday, 27 July 2020 20:55:02 UTC Rob Sayre wrote:
> > participating in "management software", that recommendation is off-topic.
> > a network which is only as secure as its least-secure node is
> > _not secure_.
> 

i'm using security the way it's defined in the dictionary. it's not "my idea".

the internet was once 100% enterprise. today it's probably 20%. on that trend, 
the IETF has lost touch with the internet's enterprise roots, and the IETF 
consensus remains determined by those who attend meetings, read or write 
drafts, or participate in mailing lists.

i am not here to tell the IETF that it's ignorant of an important market 
segment, nor request outreach beyond open meetings and open mailing lists, nor 
ask that consensus be artificially biased to include the under-represented. 
those things are true and i have spoken them often. but that's not my topic 
here and now on this thread.

my topic is to inform this working group that there are market segments who 
will treat DoH as an attack, and one of those segments (operators of private 
networks) have the resources and the will needed to defend themselves against 
that attack. my advice is to avoid those predictable consequences, as a matter 
of good engineering (anticipates real-world range of use cases).

-- 
Paul

---

From: Rob Sayre <[email-masked]>
Date: Mon, 27 Jul 2020 14:24:20 -0700

> i'm using security the way it's defined in the dictionary. it's not "my

The relevant RFCs are:

https://tools.ietf.org/html/rfc1958
https://tools.ietf.org/html/rfc7624

thanks,
Rob

---

From: Tony Rutkowski <[email-masked]>
Date: Mon, 27 Jul 2020 17:56:02 -0400

Hi there,

Those two RFCs are not useful anymore.  They reflect network 
architectures and needs of yesteryear and are restraints on the market 
for services.  IETF participants should not be required to swear 
allegiance to them, and the work should not be constrained by them.

They don't serve IETF well and it is long past due to get rid of them.

--tony

On 27-Jul-20 5:24 PM, Rob Sayre wrote:
>
>
> On Mon, Jul 27, 2020 at 2:18 PM Paul Vixie <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     > On Mon, Jul 27, 2020 at 1:51 PM Paul Vixie <[email-masked]
>     <mailto:[email-masked]>> wrote:
>     > > ...

---

From: Rob Sayre <[email-masked]>
Date: Mon, 27 Jul 2020 15:01:28 -0700

> They don't serve IETF well and it is long past due to get rid of them.

I don't agree, but feel free to get consensus on a draft that
obsoletes them. :)

thanks,
Rob