Subject: [Add] Agenda and Revised Charter for the ABCD BoF

From: Ben Schwartz <[email-masked]>
Date: Tue, 12 Nov 2019 21:32:46 -0500

On behalf of the ABCD BoF chairs, I am writing to confirm that the draft
agenda for the ABCD BoF has now been posted, along with a revised charter
proposal.

Agenda: https://datatracker.ietf.org/meeting/106/materials/agenda-106-abcd
Proposed charter:
https://datatracker.ietf.org/meeting/106/materials/slides-106-abcd-proposed-charter-text-revised

We have significantly adjusted the proposed charter text, incorporating
comments and suggestions from ADD participants.  Most notably, the revised
text attempts to ensure that disagreements on the most contentious
questions will not impede valuable standards development in less
controversial areas.

Please review the agenda and proposed charter, and join us next week for a
full discussion.

---

From: Rob Sayre <[email-masked]>
Date: Tue, 12 Nov 2019 18:55:16 -0800

> Please review the agenda and proposed charter, and join us next week for a

I think the document you've sent seems mostly reasonable. However, I must
take issue with the idea that

"- End-user privacy and pervasive surveillance"

is an issue that requires consensus building. It's settled in RFC 7258:

Pervasive Monitoring Is an Attack
https://tools.ietf.org/html/rfc7258

There hasn't been any IETF activity questioning that position.

thanks,
Rob

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 13 Nov 2019 16:08:28 +1100

Hi Ben,

> On 13 Nov 2019, at 1:32 pm, Ben Schwartz <bemasc=[email-masked]> wrote:
> 
> On behalf of the ABCD BoF chairs, I am writing to confirm that the draft agenda for the ABCD BoF has now been posted, along with a revised charter proposal.
> 
> Proposed charter: https://datatracker.ietf.org/meeting/106/materials/slides-106-abcd-proposed-charter-text-revised
> 
> We have significantly adjusted the proposed charter text, incorporating comments and suggestions from ADD participants.  Most notably, the revised text attempts to ensure that disagreements on the most contentious questions will not impede valuable standards development in less controversial areas.
> 
> Please review the agenda and proposed charter, and join us next week for a full discussion.

At the end of the proposed charter, it says:

"""
The following topics are also relevant, but represent areas that are significantly more challenging for consensus-building:

- End-user privacy and pervasive surveillance
- Detection and suppression of malware
- Use of records from untrusted sources
- Policy enforcement and control of the stub resolver configuration
- Use and impacts of large recursive resolution services

The working group will not attempt to resolve disagreements on these topics, and will require full consensus on any statements regarding these areas.
"""

However, earlier, it says:

"""
Some network operators have used DNS services for a variety of purposes beyond simple query resolution, and have relied on DNS clients to send queries to their recursive resolver or to transmit queries unencrypted. Maintaining support for those uses, if they are retained, may require new practices and protocols.
"""

This seems to imply that the Working Group will evaluate ways to support those use cases -- and promptly run into a discussion of items 1, 2, and 4 on the list above. What's the intent here?

Also, what is "full consensus", and how do you achieve it if you can't attempt to resolve disagreement on the topic that requires it?

Cheers,

--
Mark Nottingham   https://www.mnot.net/

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 13 Nov 2019 08:50:43 +0000

Hiya,

> Please review the agenda and proposed charter, and join us next week for a

Like Mark, I had a comment on this bit:

"
The following topics are also relevant, but represent areas
that are significantly more challenging for consensus-
building:

- Policy enforcement and control of the stub resolver
  configuration
"

I don't think the above is true, as written. I believe we
do have consensus on the goodness or badness of items 1-3
but differ in how best to meet the relevant goals in this
context. Items 4 & 5 also seem like different categories
from 1-3.

I suggest revising 1-5 so each bullet captures the actual
area where there's a lack of consensus, e.g. replace
"End-user privacy" with "End-user privacy impacts of
DoT/DoH deployments can vary - even over the lifetime
of one host as it moves between networks" or similar.
That'll take more words but that's ok.

I also think the sentence about "full consensus" needs
fixing. (I don't believe we have a definition of that
in any case, and I suspect this is not the right
opportunity for defining such a concept:-)

Cheers,
S.

---

From: Mat Ford <[email-masked]>
Date: Wed, 13 Nov 2019 10:56:32 +0000

Hi Ben,

[not speaking for anyone but myself]

> The working group will not attempt to resolve disagreements on these topics, and will require full consensus on any statements regarding these areas.

I think we might want to say something stronger about not being a home for discussions on these topics (because we don't expect to be able to resolve noted disagreements). That then makes the point about 'statements regarding these areas' moot (i.e. it can be removed, and then you don't need to get into a definition of 'full consensus').

Mat

> On 13 Nov 2019, at 02:32, Ben Schwartz <[email-masked]> wrote:
>

---

From: Ben Schwartz <[email-masked]>
Date: Wed, 13 Nov 2019 11:11:38 -0500

On Wed, Nov 13, 2019 at 12:08 AM Mark Nottingham <[email-masked]> wrote:

> > Agenda:
> https://datatracker.ietf.org/meeting/106/materials/agenda-106-abcd
> > Proposed charter:
> The following topics are also relevant, but represent areas that are
> significantly more challenging for consensus-building:
>
> The working group will not attempt to resolve disagreements on these
> topics, and will require full consensus on any statements regarding these
> areas.
> """
>
> Some network operators have used DNS services for a variety of purposes
> beyond simple query resolution, and have relied on DNS clients to send
> queries to their recursive resolver or to transmit queries unencrypted.
> Maintaining support for those uses, if they are retained, may require new
> practices and protocols.
> """
>
> This seems to imply that the Working Group will evaluate ways to support
> those use cases -- and promptly run into a discussion of items 1, 2, and 4
> on the list above. What's the intent here?
>

In response to the initial charter draft, some ADD participants cheered the
opportunity to address the thorniest questions, while others declared these
topics to be intractable and asked for them to be excluded.  I view this
text an attempt to find a balance between these perspectives, by permitting
the group to address a wide range of topics while avoiding divisive,
time-consuming debates.

Also, what is "full consensus",

I would define "full consensus" as the absence of any stated objection.  I
think this requirement might foster a more congenial and productive working
group environment, because (on the listed topics) participants can object
without feeling pressure to emphasize or re-state their arguments.  In my
view, the disagreements in question are not principally "technical", so it
doesn't make sense to ask the chairs to assess "technical consensus".

and how do you achieve it if you can't attempt to resolve disagreement on
> the topic that requires it?
>

I would suggest collaborating in public on less controversial work, which
might strengthen relevant relationships, and discussing any deeper
disagreements privately until you find common ground that can be presented
jointly to the group.

Cheers,

---

From: Jim Reid <[email-masked]>
Date: Wed, 13 Nov 2019 16:21:45 +0000

> On 13 Nov 2019, at 16:11, Ben Schwartz <bemasc=[email-masked]> wrote:
> 
> I would suggest collaborating in public on less controversial work, which might strengthen relevant relationships, and discussing any deeper disagreements privately until you find common ground that can be presented jointly to the group.

I wholeheartedly agree with this approach.

There's work to be done in this area and IMO the draft charter gets that balance right. I hope we can focus on the topics where progress can be made.

---

From: Melinda Shore <[email-masked]>
Date: Wed, 13 Nov 2019 13:24:16 -0500

>     Also, what is "full consensus",

I got stuck on this one, as well.

> I would define "full consensus" as the absence of any stated objection. 

Well ...  I think that, in general, as individuals we're pretty terrible
about distinguishing between objections we can live with and objections
we cannot, and organizationally we're not getting much guidance from
chairs or ADs about this.

Anyway, I'd be careful about getting into a situation in which people
are working on something that's unlikely to progress, and the current
charter text implies that a working group, if chartered, might do that.
I could be wrong but I don't think I've seen any working group charter
before that said "This is in scope and we might work on it, but maybe
not."  I think something a little crisper might help avoid getting into
a frustrating situation in which a few folks are fighting to progress
something that has little chance of success.

Melinda
-- 
Software longa, hardware brevis

PGP key fingerprint  4F68 2D93 2A17 96F8 20F2
                     34C0 DFB8 9172 9A76 DB8F

---

From: Paul Wouters <[email-masked]>
Date: Wed, 13 Nov 2019 14:52:43 -0500 (EST)

> charter text implies that a working group, if chartered, might do that.

Yes, there is a huge chance nothing will come out of a WG. After all,
the IETF work for provding the alternative solutions has been done
already. We have DoT and DoH. How, when and if people will use this
seems mostly out of scope for IETF. There are some API aspects, but I
feel this charter is more likely to just re-open the DoH vs Dot
discussion, which like the TLS 1.3 pervasive monitoring situation, will
never be resolved as its puts the end-to-end camp against the enterprise
camp.

Paul

---

From: Brian Dickson <[email-masked]>
Date: Wed, 13 Nov 2019 14:51:07 -0800

> chairs or ADs about this.
I, too, have problems with this definition or understanding of the meaning.

I was looking into where/how consensus is actually defined, if at all, in
any of the relevant BCPs.
(FYI, I see the relevant BCPs as BCP9, BCP25, BCP45, and BCP83.)

The only place I could find that makes any specific distinction between
"rough consensus" and absolute consensus is the Introduction of BCP83.
There, it makes reference to "the lone voice of dissent", where it says:

In other words, individual bad faith should not trump

   community goodwill.

IMNSHO, any WG proposal should ensure it is consistent with this sentiment,
regardless of how it is worded or how terms are defined.
I also think it would be bad form to make assessments about what is or is
not "bad faith", but rather stay consistent with how rough consensus is
measured.
(I.e. obstinance may not constitute bad faith, nor might philosophical
objections, but either of those should not be allowed to trump significant
levels of consensus.)

The other things I noted in reading all those BCPs, is the areas of
"professionalism", where the focus should be primary on technical issues.
By its nature, some of these issues drift dangerously close to policy, but
that does not mean that discussions regarding technical aspects of those
should be off limits.

We may disagree on policy, but those policy questions do need to be
informed by the underlying technical issues, and settling the technical
issues in some cases may make policy questions moot.

Mootness should always be uncovered, so as to reduce the degree of
contention.

Anyway, that's the main thing I see as being relevant to the proposal.

Brian
P.S. I think that, prior to WG adoption, discussions about whether IDs
might be suitable for adoption or relevant or ready, are perhaps not only
premature, but inappropriate. My suggestion is to refrain from that area of
discussion on an ID until the authors request adoption, at least on-list.
Private off list feedback is always appropriate, of course.

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

---

From: Brian Dickson <[email-masked]>
Date: Wed, 13 Nov 2019 15:01:14 -0800

>> - Use of records from untrusted sources
I think this really needs more concise language on what is meant by this
bullet point.
E.g.

   - Is this referring to DNS responses that are not validated?
   - Or is this referring to DNS *records* provided by some source (e.g. a
   web server) that is not the DNS resolver in use?

IMHO, the former would probably be okay to place outside normal discussion.

However, IMNSHO, the latter should specifically be listed as something akin
to "must be excluded from any WG work, except as authorized by prior
approval by DNSOP WG, WG chairs, and AD", as this would massively impact
the entirety of the Domain Name System, including security model, security,
scaling, non-repudiation, etc, etc.

Brian

---

From: Ben Schwartz <[email-masked]>
Date: Wed, 13 Nov 2019 20:03:48 -0500

On Wed, Nov 13, 2019 at 6:01 PM Brian Dickson <[email-masked]>
wrote:

>    - Or is this referring to DNS *records* provided by some source (e.g.
>    a web server) that is not the DNS resolver in use?
>
> The latter.

> However, IMNSHO, the latter should specifically be listed as something
> akin to "must be excluded from any WG work, except as authorized by prior

Thank you for the clear statement of your view.  Precisely because of the
strong feelings that have been expressed on this topic, the proposed
charter text lists it as an example of a category that is excluded from the
group's work unless full consensus miraculously emerges.  Insofar as DNSOP
WG members also participate in this proposed WG, the restriction seems
similar to the one you propose.

---

From: S Moonesamy <[email-masked]>
Date: Wed, 13 Nov 2019 21:02:50 -0800

Hi Ben,
At 08:11 AM 13-11-2019, Ben Schwartz wrote:
>I would define "full consensus" as the absence of any stated 
>objection.  I think this requirement might foster a more congenial 
>and productive working group environment, because (on the listed 
>topics) participants can object without feeling pressure to 
>emphasize or re-state their arguments.  In my view, the 
>disagreements in question are not principally "technical", so it 

The usage of "full consensus" sets a very high bar for assessing 
agreement on any of the topics listed in the proposed charter.  In my 
opinion, it is unrealistic to expect any discussion to fulfill the 
"full consensus on any statements" requirement.

There is the following statement in the last paragraph of the 
proposed charter: "All last-call announcements will be copied to the 
relevant working groups to ensure thorough and careful 
review".  Copying emails to other WG mailing lists does not ensure 
through and careful review; that is merely an announcement of the Last-Call.

Regards,
S. Moonesamy

---

From: "Ralf Weber" <[email-masked]>
Date: Thu, 14 Nov 2019 12:41:55 +0000

Moin!

 From the proposed charter:
> This working group will consider technical drafts on DNS client
> configuration, especially with a focus on the following items where
> technical consensus seems obtainable:
>
> - Communicating configuration between the network, operating system, 
> and
> applications
> - Discovery of resolvers and their capabilities and behaviors
> - Query routing in a multi-resolver environment
This is ambiguous. If it describes the current /etc/resolv.conf that’s 
fine, but I fear that it describes something where you ask “resolver 
A” for example.com and “resolver B” for example.net. I don’t 
think that there is consensus for such an approach.

> - Multiple non-equivalent query paths, such as split-horizon DNS or
> geo-sensitive answers
> - Local DNS caches (e.g. partitioning, use of stale records)
> - Resilience and fault-tolerance (e.g. single points of failure)
> - Support for debugging and analysis
> - DNS Push (accepting responses to queries that have not yet been 
> issued)
Same thing I don’t think that there is consensus on this. I personally 
think it is a bad idea, but I seem to recall from earlier discussions 
that others agreed with me. IMHO this belongs in the relevant, but more 
challenging for  consensus building category.

So long
-Ralf
—--
Ralf Weber

---

From: "Ralf Weber" <[email-masked]>
Date: Thu, 14 Nov 2019 12:46:30 +0000

Moin!

On 13 Nov 2019, at 19:52, Paul Wouters wrote:

> seems mostly out of scope for IETF.
I disagree. We have lots of groups and efforts in the IETF that discuss
deployment of Internet standards. If we don’t do this the actual
deployments will diverge and not be consistent (see NAT).

So long
-Ralf
—--
Ralf Weber

---

From: Paul Wouters <[email-masked]>
Date: Thu, 14 Nov 2019 08:32:43 -0500 (EST)

> deployments will diverge and not be consistent (see NAT).

I agree in general, but for a topic of end-to-end vs enterprise
monitoring, there is simply not much left to say. There are two
camps with different requirements that are not going to meet in
the middle. So the best we can do is ensure support for both
camps.

Paul

---

From: Ben Schwartz <[email-masked]>
Date: Thu, 14 Nov 2019 13:14:17 -0500

On Thu, Nov 14, 2019 at 7:42 AM Ralf Weber <[email-masked]> wrote:

> This is ambiguous.

I think this is very closely related to the next entry on the list, so we
should understand them together.  Perhaps they should be combined

> If it describes the current /etc/resolv.conf that’s
> fine,

That would be in-scope (and there has been some innovation here related to
retry behavior, load spreading, etc. which could be documented).

but I fear that it describes something where you ask “resolver
> A” for example.com and “resolver B” for example.net.

I think designs of this kind would also be in-scope.

> I don’t think that there is consensus for such an approach.
>

I don't think there is a single approach here; it seems to me that there is
a vast range of possible client behaviors related to multiple resolvers.
Recommending a single behavior universally might be controversial, but I
think there is plenty of room for productive technical discussion in this
area without triggering reflexive disagreement.

> > - Multiple non-equivalent query paths, such as split-horizon DNS or

As an example of the kinds of issues that come up here, consider Mozilla's
default behavior [1], in which an NXDOMAIN response from the primary
resolution path triggers a retry of the query on a second resolution path.
This is an interesting choice with particular privacy, security,
compatibility, and performance properties.  Perhaps it's worth specifying
this solution in more detail, or perhaps defining a range of solutions with
different properties.  I believe we can discuss the properties of different
stub state-machines without debating Mozilla's method for choosing the
primary resolver.

[1]
https://support.mozilla.org/en-US/kb/dns-over-https-doh-faqs#w_how-does-firefox-handle-split-horizon-dns

> Same thing I don’t think that there is consensus on this.

We don't need consensus that a topic is worthwhile in order to include it
in a working group charter.  We merely need to believe that there is some
positive interest and potential for a technical consensus to emerge without
derailing the working group's other topics.

> I personally

I don't think this topic is particularly controversial, and versions of
this idea have been considered previously without major incident, e.g.
[2].  This is purely a performance question; there is little security
relevance, because we are speaking about answers delivered from the same
resolver and query path as all the other DNS responses.

In any case, RFC 8484 DoH already defines DNS Push (Section 5.3), along
with some rules about when it cannot be used.  It does not, however,
provide any additional guidance that might support practical use, and has
some significant limitations.  Including this topic would allow us to
improve the specification of DNS Push, or indeed deprecate it if that is
the technical consensus.

[2] https://tools.ietf.org/html/draft-wkumari-dnsop-multiple-responses-05

So long

---

From: Patrick McManus <[email-masked]>
Date: Sat, 16 Nov 2019 00:05:13 -0500

This charter just seems like a suggestion for a perpetual forum to argue
and, afaict, isn't actually expected to produce anything.. it just has some
things that if they were published would belong in the proposed wg.

Please don't make us collectively relive the ADD side meeting every full
meeting.

My suggestion: If the proponents believe that a group can publish a
document on (e.g.) "Communicating configuration between the network,
operating system, and applications" please write a charter with that as the
goal of the group and the BoF can do the usual thing of deciding whether
that is a problem worth solving, is well understood, and has a chance of
success. If it works out - recharter the group for new work.

As is the charter fails those tests by putting everything in scope but
requiring nothing at the same time.

-Patrick

On Thu, Nov 14, 2019 at 1:14 PM Ben Schwartz <bemasc=
[email-masked]> wrote:

> I don't think there is a single approach here; it seems to me that there
> is a vast range of possible client behaviors related to multiple
> resolvers.  Recommending a single behavior universally might be
> controversial, but I think there is plenty of room for productive technical
> discussion in this area without triggering reflexive disagreement.
>
>
> <https://support..mozilla.org/en-US/kb/dns-over-https-doh-faqs#w_how-does-firefox-handle-split-horizon-dns>
>
>

---

From: Brian Dickson <[email-masked]>
Date: Sun, 17 Nov 2019 19:40:51 +0800

> Please review the agenda and proposed charter, and join us next week for a
Thanks to the authors etc for putting this all together, I look forward to
the discussion.

I have a question, about whether it would be reasonable to discuss the
following in the context of ABCD's BoF and whether it would be reasonable
to include it for discussion (or if it belongs somewhere else)?

This the question, very briefly: *Is it too late to discuss changing the
port for DoH from 443 to a unique port number?*

Here's the context for the question, based on what has transpired since
8484 was published:

   - Two browsers have announced experiments on DoH
   - The two browser vendors are using very different approaches to
   resolver selection
      - Firefox is using its TRR with Cloudflare as the initial (only) entry
      - Chrome is doing a "same resolver" upgrade, but only for entries in
      its (TRR-like) table of resolvers
   - Public resolver operators have generally stated they will not run any
   other services on the IP addresses used for DoH
   - No widespread dependence on DoH (without fallback to regular DNS) is
   known to have been adopted

The initial argument in 8484 for using the same port as HTTPS, was that
mixing DoH traffic with regular HTTPS traffic would provide two benefits:

   - Difficulty in identifying DoH traffic
   - Difficulty in blocking DoH traffic (e.g. without impacting non-DoH
   HTTPS traffic)

However, given that the public resolvers serving DoH are NOT mixing any
other HTTPS traffic with the DoH traffic, both of those arguments are
invalid:

   - Any on-path party wanting to block DoH to these public resolvers, can
   do so on the basis of IP address alone,
   - Thus the port number is irrelevant (and there is no reason to insist
   on 443 other than the relatively trivial issue of deployed code on two
   browsers and a handful of resolvers)

There is one relevant aspect of the choice of port number, that motivates
the question of changing to a unique port number:

   - The ability of an on-path network operator, such as an enterprise, to
   detect and/or block "rogue" DoH servers which are not on any TRR list, is
   dependent on having a unique port number to identify such traffic.

The detection and/or blocking does NOT require the ability to observe the
contents of the DoH traffic. I.e. it is compatible with encrypted DNS. This
is not a proposal to change the wire format of DoH, only its port number.

For many/most of the use cases contemplated, the mere existence of "new"
DoH endpoints is of interest to network operators (e.g. for identifying
malware), and blocking such detected connections at the network (IP and
port) level is sufficient, and also does not require examination of the
contents.

Most of the remaining contentious issues from ADD (and presumably ABCD) may
be significantly mitigated by a change of port number (thus allowing
enterprise network operators to do the above).

I'm not asking that this question be discussed here, or that a decision be
taken just yet.

I recognize the port number issue is a bit late; the question is, given
that there does not appear to be any remaining benefit to overloading 443
for DoH:

*Is it TOO late to revisit the port choice?*

I.e., Is it appropriate to add to the ABCD on-topic matter for subsequent
discussion and ID proposals?

Brian

---

From: Ted Lemon <[email-masked]>
Date: Sun, 17 Nov 2019 08:26:33 -0500

On Nov 17, 2019, at 6:40 AM, Brian Dickson <[email-masked]> wrote:
> This the question, very briefly: Is it too late to discuss changing the port for DoH from 443 to a unique port number?

It’s never too late to have a discussion, but it would be a useless discussion, unless you intend to obtain police powers; even then, you’re not really going to be able to do it in a way that gains you anything.  This would be like going up to someone who’s drinking coffee and getting into a discussion with them about how they should switch to tea.  They might be polite, or they might throw the coffee at you (but probably not because then they wouldn’t be able to drink it).  They definitely aren’t going to stop drinking coffee.

---

From: Patrick McManus <[email-masked]>
Date: Sun, 17 Nov 2019 23:02:27 +0800

DoH does not require any particular port number - the server specifies it
as part of the URI Template and there is no default template. You cannot
make another port number the default for https (which doh does required)
without minting another scheme, which seems kind of pointless when you can
simply explicitly use another port as part of the template if you like.

Handcuffing the protocol to introduce intentional network signaling would
weaken the confidentiality properties of HTTPS - i.e. it is quite explicit
that any HTTPS content (or purpose) is not visible to the network and allow
network attackers to trivially launch downgrade attacks. That isn't in the
interest of securing a protocol.

This thread is probably a good example of how ABCD would not be a
productive working group.

On Sun, Nov 17, 2019 at 7:41 PM Brian Dickson <[email-masked]>
wrote:

>
>    - The ability of an on-path network operator, such as an enterprise,
>    to detect and/or block "rogue" DoH servers which are not on any TRR list
>
>
unregistered is rogue now?

---

From: Vittorio Bertola <[email-masked]>
Date: Mon, 18 Nov 2019 01:35:47 +0100 (CET)

Il 17 novembre 2019 16:02 Patrick McManus <[email-masked]> ha scritto:

DoH does not require any particular port number - the server specifies it as part of the URI Template and there is no default template. You cannot make another port number the default for https (which doh does required) without minting another scheme, which seems kind of pointless when you can simply explicitly use another port as part of the template if you like.

That's fine, but the discussion could rather be: should we suggest that all well-behaved DoH providers use a specific port other than 443 in their template? (Of course non-well-behaved providers will always do whatever possible to camouflage their traffic, but that's an intrinsic feature of a default port anyway - it can always be changed.)

Honestly (coming from a free software maker that produces the most widely used mail delivery agent on the planet, and that strives to keep its long tail of small independent email servers able to work and connect with the big email platforms, something which has become increasingly difficult over time due to heuristic anti-abuse filters on incoming email by the big players that tend to treat any too-small-for-measurement server as "possibly rogue") I think that the TRR concept in itself is just going to get us there: by introducing the idea that some DNS providers are more trusted than others, of course everyone else's life will be made more and more difficult, by using the absence from that list as a signal of possible problems - or just by trying to block all traffic for resolvers that have not been vetted by someone.

--

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

---

From: Patrick McManus <[email-masked]>
Date: Mon, 18 Nov 2019 09:38:26 +0800

On Mon, Nov 18, 2019 at 8:35 AM Vittorio Bertola <
[email-masked]> wrote:

>
> (Of course non-well-behaved providers will always do whatever possible to
> camouflage their traffic,  [..]
>
>
Seeking confidential 2 party communication with HTTPS is not
non-well-behaved - it is exactly what HTTPS seeks to do.

---

From: Brian Dickson <[email-masked]>
Date: Mon, 18 Nov 2019 10:02:39 +0800

> simply explicitly use another port as part of the template if you like.

The default for HTTPS is just that - a default. RFC2818 is very clear, that
any transport can be used, and the default is just a default.
Revising 8484 to specify a particular default to use for DoH would be
pretty simple, and supported by any protocol stack that supports HTTPS.

Recall: HTTPS uses the HTTP URI scheme, which requires support for an
optional ":port" parameter.

So, modifying what is done under the hood on a browser is literally as
simple as changing the embedded DoH stuff to append ":DOH_PORT" to the DoH
server name/IP.

No new minting required.

I'm not concerned with the Template contents, only the base URI from which
the template is obtained.

> interest of securing a protocol.

In my original message, I pointed out that this is already the case. The
public DNS resolvers offering DoH do not offer any other services on the IP
address(es) used for DNS.
This weakening already exists and is intractable based on the operators'
practices.
The purpose can be trivially inferred by the IP addresses of those servers.
In fact, the browsers themselves publish such a list of addresses, in their
TRR (or equivalent) tables.

> productive working group.

Notwithstanding how you feel about this particular suggestion, I think it
unfair to the rest of the ABCD participants to take this stance. It is ad
hominem pluribus.

No offense intended.

Brian

---

From: Brian Dickson <[email-masked]>
Date: Mon, 18 Nov 2019 10:18:53 +0800

On Sun, Nov 17, 2019 at 9:26 PM Ted Lemon <[email-masked]> wrote:

> It’s never too late to have a discussion, but it would be a useless
> discussion, unless you intend to obtain police powers; even then, you’re
> not really going to be able to do it in a way that gains you anything.
>

I take it you are skeptical of the requirement that browsers change port in
order to DoH.

I agree it isn't necessarily an easy task, which is why updating the
standard for DoH is the right place to start.

If the larger community, in particular the DNS operator community agrees
this is worth doing, particularly at this early juncture, this provides a
path to accomplishing the change.

If the DNS operators change the port they serve DoH on, the browsers would
have no choice but to change. The port must be agreed upon for the protocol
to function.

In particular, given that Google operate one such public DNS resolver, as
well as develop one of the two browsers doing DoH experimentation, I'd say
the prospects of this depend very much on Google.

I don't discount either possibility; it might be possible, or it might not
succeed. It doesn't mean we shouldn't explore the possibility.

The main motivation is that the port number, rather than the transport
protocol  (HTTPS) or resolver selection, are the biggest areas of
contention.

Changing the protocol allows impacted network operators (enterprise, SOHO,
etc.) who have reasons to implement detection and/or blocking to take
action that does not require MITM or policing devices on their network.

It preserves, more or less, the network posture status quo, without in any
way weakening the privacy afforded generally. I.e. Changing the port number
still results in encrypted transport to the resolver, if the resolver is
reachable.

It does not automatically prevent DoH, and in fact use of DoH or DoT within
such networks is encouraged (by me at least). I'd like to see more work on
the resolver identity issues and connection upgrade (bootstrapping).

> This would be like going up to someone who’s drinking coffee and getting
> into a discussion with them about how they should switch to tea.  They
> might be polite, or they might throw the coffee at you (but probably not
> because then they wouldn’t be able to drink it).  They definitely aren’t
> going to stop drinking coffee.
>

I think product (coffee/tea) comparisons aren't good analogies, I think
standards things like railway track gauge, or the NTSC upgrade to support
HDTV, or wireless frequency stuff, are better choices.
E.g. There is some good history on why subways and railroads use different
standards for track gauge, at least in some cities, IIRC.
 A good use case example would be bridges or tunnels used for multiple
vehicle types, where being able to operate switches that apply to one set
of colinear tracks but not the other, would be particularly useful,
something only possible with different rail gauges running literally one
inside the other.

Brian

---

From: Brian Dickson <[email-masked]>
Date: Mon, 18 Nov 2019 10:25:23 +0800

> unregistered is rogue now?

No, but rogue is unregistered.

There is no "evil" bit, so the detection of rogue starts with detecting
unregistered, and digging deeper as necessary.

We're in favor of lots and lots of resolvers, rather than an effective
forcing function via TRR lists, to centralized resolvers.

A unique port number for DoH actually encourages this rather than
discourages this.

A new set of traffic that is explicitly DoH (based on port number) would be
more likely to malware-detection-friendly than overloading HTTPS.
(It involves less initial investigation, as it already self-identifies as
DoH. A cursory examination of the DoH service being contacted should be
enough to identify "regular" DoH server functionality from "irregular" DoH
functionality.)

Brian

---

From: "Ralf Weber" <[email-masked]>
Date: Mon, 18 Nov 2019 10:32:01 +0800

Moin!

> non-well-behaved - it is exactly what HTTPS seeks to do.
I think that is not question here that Vittorio and Brian wanted to 
raise. We
all agree that https or TLS in general allows confidential 2 party 
communication.
The question is more who are these endpoints and I think it is in scope 
of
ABCD, and I still hope that we will be successful in doing this, to 
define
client and server behaviour or deployment advices for DoH servers and 
clients.

So long
-Ralf
—--
Ralf Weber

---

From: "Livingood, Jason" <[email-masked]>
Date: Mon, 18 Nov 2019 02:57:07 +0000

After reflecting on the list discussion, I agree there are aspects of the proposed charter on which it will be difficult to achieve consensus (LOL). So maybe let’s just set aside the stuff where we all know that is the case and try to focus more narrowly on those areas where getting a few things done might be possible. So for example – here are some off-the-cuff thoughts which may or may not be well considered on my part. ;-) (with apologies to people that view this in plaintext mode vs. HTML - since I have added strikethrough and colored text markup – blue text is new):

- Communicating configuration between the network, operating system, and
Applications How resolvers can signal their configuration and/or practices to operating systems and applications (and users?), to support decision-making or selection behaviors by those parties.

- Automated discovery & selection Discovery of resolvers, with selection potentially made based on detected resolver and their capabilities and behaviors (based on OS, app and/or user preferences)

- Determination / detection of split-horizon DNS environments and standardized uses of ‘canary domains’ or other methods to enable detection of such environments

- Potential use of alternative application port numbers in some controlled environments (e.g. managed enterprise environments), including the pros/cons and implications of security downgrade and/or detectability in these environments

- Resilience and fault-tolerance (e.g. single points of failure modes from encrypted DNS to Do53 or from a primary encrypted DNS resolvers to secondary or tertiary resolvers – or something like that)

- Support Standards / approaches for debugging and analysis (e.g. to support development of OS and application-layer diagnostic troubleshooting tools, a la dig, whether software-driven or user-prompted)

- DNS Push (accepting responses to queries that have not yet been issued) [JL comment: not sure why this would not be a client-driven activity, such as looking at all possible FQDNs on a site that a user is likely to ask for and sending all those queries from the client when the app/site first opens, based on prior user behavior or likely pathways through an app/site]

- Ossification and evolvability

The working group will not attempt to resolve disagreements on these topics,
and will require full consensus on any statements regarding these areas.

This working group will coordinate with dnsop (OPS Area), capport (ART
Area), dprive, dhc, and homenet (INT Area). All last-call announcements will
be copied to the relevant working groups to ensure thorough and careful
review. The working group will also coordinate with the SEC Area, and will
be assigned a security advisor.

From: Add <[email-masked]> on behalf of Patrick McManus <[email-masked]>
Date: Saturday, November 16, 2019 at 1:06 PM
To: Ben Schwartz <bemasc=[email-masked]>
Cc: ADD Mailing list <[email-masked]>, Ralf Weber <[email-masked]>
Subject: Re: [Add] Agenda and Revised Charter for the ABCD BoF

This charter just seems like a suggestion for a perpetual forum to argue and, afaict, isn't actually expected to produce anything... it just has some things that if they were published would belong in the proposed wg.

Please don't make us collectively relive the ADD side meeting every full meeting.

My suggestion: If the proponents believe that a group can publish a document on (e..g.) "Communicating configuration between the network, operating system, and applications" please write a charter with that as the goal of the group and the BoF can do the usual thing of deciding whether that is a problem worth solving, is well understood, and has a chance of success. If it works out - recharter the group for new work.

As is the charter fails those tests by putting everything in scope but requiring nothing at the same time.

-Patrick

On Thu, Nov 14, 2019 at 1:14 PM Ben Schwartz <bemasc=[email-masked]<mailto:[email-masked]>> wrote:

On Thu, Nov 14, 2019 at 7:42 AM Ralf Weber <[email-masked]<mailto:[email-masked]>> wrote:
Moin!

This is ambiguous.

I think this is very closely related to the next entry on the list, so we should understand them together.  Perhaps they should be combined

That would be in-scope (and there has been some innovation here related to retry behavior, load spreading, etc. which could be documented).

but I fear that it describes something where you ask “resolver
A” for example.com<https://urldefense.com/v3/__http:/example.com__;!rx_L75ITgOQ!QpYiYmLfw5x0GNCzn55qgsVeik8Scqtt7RQzzTGhG4peCplTE5ij67Tt1xPomd9ytuQ_Ug$> and “resolver B” for example.net<https://urldefense.com/v3/__http:/example.net__;!rx_L75ITgOQ!QpYiYmLfw5x0GNCzn55qgsVeik8Scqtt7RQzzTGhG4peCplTE5ij67Tt1xPomd-IwSWjYg$>.

I don't think there is a single approach here; it seems to me that there is a vast range of possible client behaviors related to multiple resolvers.  Recommending a single behavior universally might be controversial, but I think there is plenty of room for productive technical discussion in this area without triggering reflexive disagreement.

> - Multiple non-equivalent query paths, such as split-horizon DNS or

As an example of the kinds of issues that come up here, consider Mozilla's default behavior [1], in which an NXDOMAIN response from the primary resolution path triggers a retry of the query on a second resolution path.  This is an interesting choice with particular privacy, security, compatibility, and performance properties.  Perhaps it's worth specifying this solution in more detail, or perhaps defining a range of solutions with different properties.  I believe we can discuss the properties of different stub state-machines without debating Mozilla's method for choosing the primary resolver.

[1] https://support.mozilla.org/en-US/kb/dns-over-https-doh-faqs#w_how-does-firefox-handle-split-horizon-dns<https://urldefense.com/v3/__https:/support...mozilla.org/en-US/kb/dns-over-https-doh-faqs*w_how-does-firefox-handle-split-horizon-dns__;Iw!rx_L75ITgOQ!QpYiYmLfw5x0GNCzn55qgsVeik8Scqtt7RQzzTGhG4peCplTE5ij67Tt1xPomd-lJFnTqg$>

We don't need consensus that a topic is worthwhile in order to include it in a working group charter.  We merely need to believe that there is some positive interest and potential for a technical consensus to emerge without derailing the working group's other topics.

I personally

I don't think this topic is particularly controversial, and versions of this idea have been considered previously without major incident, e.g. [2].  This is purely a performance question; there is little security relevance, because we are speaking about answers delivered from the same resolver and query path as all the other DNS responses.

In any case, RFC 8484 DoH already defines DNS Push (Section 5.3), along with some rules about when it cannot be used.  It does not, however, provide any additional guidance that might support practical use, and has some significant limitations.  Including this topic would allow us to improve the specification of DNS Push, or indeed deprecate it if that is the technical consensus.

[2] https://tools.ietf.org/html/draft-wkumari-dnsop-multiple-responses-05<https://urldefense.com/v3/__https:/tools.ietf.org/html/draft-wkumari-dnsop-multiple-responses-05__;!rx_L75ITgOQ!QpYiYmLfw5x0GNCzn55qgsVeik8Scqtt7RQzzTGhG4peCplTE5ij67Tt1xPomd8TK2_YaQ$>

So long
-Ralf
—--
Ralf Weber
--
Add mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/add<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/add__;!rx_L75ITgOQ!QpYiYmLfw5x0GNCzn55qgsVeik8Scqtt7RQzzTGhG4peCplTE5ij67Tt1xPomd-iZisPzQ$>

---

From: Eric Rescorla <[email-masked]>
Date: Sun, 17 Nov 2019 19:03:58 -0800

> interest of securing a protocol.

This more or less reflects my view as well. While I was not a core
participant in the design of DoH and decision to have it be on 443 (though
that just seems like the obvious design) I do not consider changing the
port number or adding some other mechanism to make DoH easier to block to
be an improvement.

-Ekr

> On Sun, Nov 17, 2019 at 7:41 PM Brian Dickson <
> [email-masked]> wrote:
>
>>

---

From: Brian Dickson <[email-masked]>
Date: Mon, 18 Nov 2019 11:21:57 +0800

> port number or adding some other mechanism to make DoH easier to block to

At least as far as concerns Firefox, whose TRR list involves well-known
resolvers who AFAIK don't plan on running anything else on 443, I have a
question about your view:

If changing the port number DOES NOT make DoH easier to block for Firefox's
deployment model, would changing port number then be acceptable (if perhaps
not favored)?

I believe the port number is irrelevant for blocking DoH towards well-known
public resolvers, and thus changing the port number has no impact on
blocking.
(Blocking based solely on IP addresses would be sufficient, with the caveat
that a carve-out of allowing port 53 might be done by on-path adversaries.)

Brian

---

From: Eric Rescorla <[email-masked]>
Date: Sun, 17 Nov 2019 19:41:51 -0800

On Sun, Nov 17, 2019 at 7:22 PM Brian Dickson <[email-masked]>
wrote:

> resolvers who AFAIK don't plan on running anything else on 443,
>

They don't presently do so, but I'm not aware of any statement that they
never plan to, and  there are clearly some advantages to muxing HTTP and
DNS on the same transport.

I have a question about your view:
>
> If changing the port number DOES NOT make DoH easier to block for
> Firefox's deployment model, would changing port number then be acceptable
> (if perhaps not favored)?
>

As Patrick says, there's nothing preventing people from running DoH on a
separate port, as it's part of the URL template. I do not believe we should
change the default port.

-Ekr

---

From: Ted Lemon <[email-masked]>
Date: Mon, 18 Nov 2019 00:50:17 -0500

On Nov 17, 2019, at 9:18 PM, Brian Dickson <[email-masked]> wrote:
> I think product (coffee/tea) comparisons aren't good analogies, I think standards things like railway track gauge, or the NTSC upgrade to support HDTV, or wireless frequency stuff, are better choices.
> E.g. There is some good history on why subways and railroads use different standards for track gauge, at least in some cities, IIRC.
>  A good use case example would be bridges or tunnels used for multiple vehicle types, where being able to operate switches that apply to one set of colinear tracks but not the other, would be particularly useful, something only possible with different rail gauges running literally one inside the other.

No, the coffee/tea analogy is actually more right.  If you have a rail car with the wrong gauge, it won’t run on the track.  DoH will work fine with any port number.  This is not an opinion—it’s a fact.   DoH is not useful for its intended purpose if any port other than 443 is specified. Again, not opinion, fact.

So when you say “use a different port,” you are saying “drink tea, not coffee.”   You are essentially saying “don’t use DoH.”

We’ve heard a couple of interesting actual issues raised:

- Isn’t this a violation of law in some jurisdictions?
- Doesn’t this tend to increase centralization?

I think both of these are interesting questions.   It’s not clear to me how the IETF answers the first one.   If it’s against the law to use or publish DNS names in DoH in some jurisdiction, then the user or publisher will have to behave accordingly, either violating the law or following it according to the situation.  We have no control over that, and I can’t see how we can do anything one way or another about that.  When people talk about this as a problem, in that the IETF is not respecting local law, that’s a category error.  IETF doesn’t write laws—it writes standards.   It’s completely out of scope for us to figure out how these standards may or may not violate laws in some jurisdictions.

The second question is a very good question, and I think something we should really be thinking carefully about.  I agree that this is an important concern.  It bothers me that if people think this is an important concern, they are then going to “let’s change the port number or disable DoH” as a way around that problem.  Changing the port number or disabling DoH won’t solve that problem.   Changing the port number will definitely be ignored by anybody who needs DoH for its intended purpose, so it’s a no-op.   Disabling DoH won’t happen if someone wants it, because it’s up to them to decide, not up to us.

So if this is a real problem that we want to solve, we should stop talking about changing the port number.

---

From: Joseph Lorenzo Hall <[email-masked]>
Date: Mon, 18 Nov 2019 05:51:40 +0000

(Affiliation for identification purposes only; I am not speaking on behalf of ISOC, but only for myself)

On Nov 18, 2019, at 9:38 AM, Patrick McManus <[email-masked]<mailto:[email-masked]>> wrote:

On Mon, Nov 18, 2019 at 8:35 AM Vittorio Bertola <[email-masked]<mailto:[email-masked]>> wrote:

(Of course non-well-behaved providers will always do whatever possible to camouflage their traffic,  [..]

Seeking confidential 2 party communication with HTTPS is not non-well-behaved - it is exactly what HTTPS seeks to do.

Hear, hear. I am baffled at times at why this basic property seems to be up for discussion; over-HTTPS means exactly that (of course, resolvers can specify other ports but HTTPS defaults to the one we know and love).

I agree with Patrick that this is one of a number of aspects of the ongoing ABCD/ADD discussion that seems to indicate we would be “spinning the wheels” (not getting much productive done) in a WG. I like where Livingood is going on this thread with suggested changes to the proposed charter to make the work here more crisp, but even that still seems like a vast set of possibilities and that’s a lot of rope to get ourselves wrapped around in.

best, Joe

---

From: Ted Lemon <[email-masked]>
Date: Mon, 18 Nov 2019 00:54:49 -0500

> - Potential use of alternative application port numbers in some controlled environments (e.g. managed enterprise environments), including the pros/cons and implications of security downgrade and/or…

This is presuming a solution.  Can we change it to just talk about the problem?

- The problem of detecting and preventing the use of DoH in managed environments where the network operator needs control of DNS queries.

> - Resilience and fault-tolerance (e.g. single points of failure modes from encrypted DNS to Do53 or from a primary encrypted DNS resolvers to secondary or tertiary resolvers – or something like tha…

I have no idea what this means.   Is this about dealing with the possibility that DoH will be blocked by the network?  Or that the DoH server will be unreachable for other reasons?

---

From: Rob Sayre <[email-masked]>
Date: Sun, 17 Nov 2019 21:59:45 -0800

On Sun, Nov 17, 2019 at 9:51 PM Joseph Lorenzo Hall <[email-masked]> wrote:

>
> I agree with Patrick that this is one of a number of aspects of the
> ongoing ABCD/ADD discussion that seems to indicate we would be “spinning
> the wheels” (not getting much productive done) in a WG. I like where
> Livingood is going on this thread with suggested changes to the proposed
> charter to make the work here more crisp
>

I agree that some of Livingood's additions are a little better. But his
edits seem to remove out-of-bounds topics, which seems misguided.

I also think that a lot of the proposals basically amount to "you have to
use my resolver!!". Those are misguided, and ultimately undermine the IETF
itself.

thanks,
Rob

---

From: Jim Reid <[email-masked]>
Date: Mon, 18 Nov 2019 06:08:26 +0000

> On 18 Nov 2019, at 05:54, Ted Lemon <[email-masked]> wrote:
> 
>> 

I thought this meant end client behaviour/policy. ie If/when DoH fails (for some definition of fail), try DoT then Do53. Or give up. Or try Do53, then DoT. Or some other combination of these fallbacks. How could/should resolvers (for some definition of resolver) be configured and/or provisioned to reflect local policy or end user preference about these possibilities?

---

From: Ted Lemon <[email-masked]>
Date: Mon, 18 Nov 2019 01:12:43 -0500

> I thought this meant end client behaviour/policy. ie If/when DoH fails (for some definition of fail), try DoT then Do53. Or give up. Or try Do53, then DoT. Or some other combination of these fallba…

It’s not clear to me that we need to do this, but I think it would be okay to have a charter item about researching it.  The reason I say we may not need to do it is that it’s not clear to me that there’s one answer we could dictate.   I suspect that it is more of a security policy decision.  So what might be useful is an exploration of what policies might make sense.   However, my intuition is that the actual work on this topic will be done by vendors, not in the IETF, because the only way to really get clarity on the correct behavior is to have users winning or losing as a result of this.  So unless the vendors want to discuss this in the IETF, I think this is just going to create confusion.   If a WG in the IETF spends a lot of time writing documents about this without input from the vendors, the best case scenario is that the documents will coincidentally reflect what the vendors learn as they deploy this.

---

From: Brian Dickson <[email-masked]>
Date: Mon, 18 Nov 2019 14:17:04 +0800

> something only possible with different rail gauges running literally one
I'm going to ask follow-up questions here, because I don't think I
understand what you're meaning, and want to understand.
(The hallmark of useful discussion is the listening and comprehension,
rather than the talking part.)

> No, the coffee/tea analogy is actually more right.
>

> If you have a rail car with the wrong gauge, it won’t run on the track.
>

So, what I'm talking about in the analogy, is two tracks running in
parallel, occupying what amounts to a single "right of way", or passageway.
Only one of the two tracks can be used at a time.
For demonstration purposes, suppose one track is 44.3 inches wide, and the
other track is 65.3 inches wide (call them https, and newdoh).

I'm proposing that both the client and server switch to port NEW_VALUE (in
the example that would correspond to 653, for identification purposes only).

The analogy is only useful when both the client and server use the new
value, i.e. the rail car also has the new gauge.

DoH rail cars would have 65.3 gauge. HTTPS rail cars would have 44.3 gauge.

The two ends of the passageway would have switches for the 65.3 gauge only,
to divert it (analogous to being able to identify and/or block on the basis
of port -- or to not block it, if the network policy were permissive.)

> DoH will work fine with any port number.
>
This is not an opinion—it’s a fact.

I believe you are conflating the DoH Template URI, and the content of the
template.
I am proposing a new Template port number, irrespective of what is in the
template.
(I.e. that post-template communications is not port-dependent, as that is
all specified in the template.)
I think there is no disagreement on whether the DoH traffic after being
configured by the template is port-neutral.

The issue is the first port, which is necessarily required for the DoH
configuration step (which may still require a bootstrap via DNS to find the
IP address of the server name at which the Template is served.)

> DoH is not useful for its intended purpose if any port other than 443 is
> specified. Again, not opinion, fact.
>

I am unsure what fact you are implying, as the "intended purpose" is pretty
vague.

If you mean "privacy-enhanced DNS using TLS encryption", we disagree, as
the only issue is whether the TLS connection can be established. If it is
established, privacy is assured by TLS.

If you mean the stuff about

Additionally, the use of the HTTPS default port 443 and the ability

   to mix DoH traffic with other HTTPS traffic on the same connection
   can deter unprivileged on-path devices from interfering with DNS
   operations and make DNS traffic analysis more difficult.

... then that is a "can", not a "will", and is entirely dependent on
whether the resolver operator has any HTTPS content other than DNS.

If it does not, then the port number is moot, since the preconditions
are not met.

This whole discussion that I started, is premised entirely on facts,
regarding DoH public resolvers not doing any other HTTPS on the IP
addresses serving DoH.

This, IMHO, is what makes the port number question germane, and ripe
for discussion. I see no solid reason to insist on the Template being
served on port 443.

While I'd prefer the default port used by the resulting templates (and
thus by the DoH TLS connections) be different, I haven't given it
enough thought to figure out if the port number INSIDE the template is
as important.

Maybe this is where we are talking past each other, and if so, that is
probably my fault, and I apologize.

So, to restate: I'm suggesting changing the standardized port FOR THE
TEMPLATE RETRIEVAL, without speaking to the in-template URI port
number.

>
> So when you say “use a different port,” you are saying “drink tea, not
> coffee.”   You are essentially saying “don’t use DoH.”
>

No, I really am saying, different rail gauge, and pick the hot beverage
that suits you.

Brian

---

From: "John Levine" <[email-masked]>
Date: 18 Nov 2019 15:26:19 +0800

>port for DoH from 443 to a unique port number?*

It's pretty clear to me from the discussion is that the answer to this
question depends on what you think DoH is for.  Good luck getting agreement
on either.

---

From: "Livingood, Jason" <[email-masked]>
Date: Mon, 18 Nov 2019 07:50:30 +0000

Honestly I was unsure what it meant as well – I was really just guessing at what might have been intended by “Resilience and fault-tolerance” in the latest draft charter. ;-) So I was just throwing out ideas to progress discussion on the charter.

From: Add <[email-masked]> on behalf of Ted Lemon <[email-masked]>
Date: Monday, November 18, 2019 at 2:13 PM
To: Jim Reid <[email-masked]>
Cc: ADD Mailing list <[email-masked]>
Subject: Re: [Add] Agenda and Revised Charter for the ABCD BoF

On Nov 18, 2019, at 1:08 AM, Jim Reid <[email-masked]<mailto:[email-masked]>> wrote:
I thought this meant end client behaviour/policy. ie If/when DoH fails (for some definition of fail), try DoT then Do53. Or give up. Or try Do53, then DoT. Or some other combination of these fallbacks. How could/should resolvers (for some definition of resolver) be configured and/or provisioned to reflect local policy or end user preference about these possibilities?

---

From: "Livingood, Jason" <[email-masked]>
Date: Mon, 18 Nov 2019 07:56:38 +0000

From: Ted Lemon <[email-masked]>

> - The problem of detecting and preventing the use of DoH in managed environments where the network operator needs control of DNS queries.

[JL] That could work as well. I wonder though if there are use cases where an enterprise may not want to prevent DoH writ large, just to off-net DoH servers (s/detecting and/detecting or ?). As I thought about it, perhaps there is value in documenting why enterprises might want to do this, as well as the security & privacy pros and cons of doing so, etc. Again, not sure I have a position on this deliverable - I'm just trying to see if it's possible to flesh out some of the charter items and frame them so that perhaps consensus on it may be possible.

---

From: "Livingood, Jason" <[email-masked]>
Date: Mon, 18 Nov 2019 08:04:39 +0000

From: Add <[email-masked]> on behalf of Rob Sayre <[email-masked]>
On Sun, Nov 17, 2019 at 9:51 PM Joseph Lorenzo Hall <[email-masked]<mailto:[email-masked]>> wrote:

I agree with Patrick that this is one of a number of aspects of the ongoing ABCD/ADD discussion that seems to indicate we would be “spinning the wheels” (not getting much productive done) in a WG. I like where Livingood is going on this thread with suggested changes to the proposed charter to make the work here more crisp

> I agree that some of Livingood's additions are a little better. But his edits seem to remove out-of-bounds topics, which seems misguided.

[JL] It seemed the ‘out of bounds’ topics would make consensus impossible – which would then prevent WG formation. So proposing removal was an approach to see if we might identify those few areas where there is agreement. I am not sure how that is misguided, but it wouldn’t be the first time I’ve been accused of being misguided, confused, crazy, deluded or whatever else. LOL.

---

From: Andrew Campling <[email-masked]>
Date: Mon, 18 Nov 2019 08:20:48 +0000

On Mon, Nov 18, 2019 at 16:05 Livingood, Jason <[email-masked]> wrote:

> From: Add <[email-masked]<mailto:[email-masked]>> on behalf of Rob Sayre <[email-masked]<mailto:[email-masked]>>

> It seemed the ‘out of bounds’ topics would make consensus impossible – which would then prevent WG formation.
> So proposing removal was an approach to see if we might identify those few areas where there is agreement. I am
> not sure how that is misguided, but it wouldn’t be the first time I’ve been accused of being misguided, confused,
> crazy, deluded or whatever else. LOL.

That does seem a somewhat idiosyncratic use of the word misguided.  Let’s hope that others take a similar approach to help reach a reasonable consensus in the BoF session tomorrow.

Andrew

---

From: Brian Dickson <[email-masked]>
Date: Mon, 18 Nov 2019 16:25:14 +0800

TL;DR:
I TL;DR'd the 8484 and misunderstood the whole template semantics.

In short, there was a misunderstanding on my part on what the template was
and where it came from, and that it was actually outside the scope of the
RFC.

And, then, what I really should have said/meant was, the port number would
be a replacement for (or additional ":port" parameter) to the template URI
where it currently needs to be "https://".

Apologies, still maybe a bit jet lagged.

Brian

On Mon, Nov 18, 2019 at 2:17 PM Brian Dickson <[email-masked]>
wrote:

>> E.g. There is some good history on why subways and railroads use
>> different standards for track gauge, at least in some cities, IIRC.
> The two ends of the passageway would have switches for the 65.3 gauge
> only, to divert it (analogous to being able to identify and/or block on the
> basis of port -- or to not block it, if the network policy were
> permissive.)
>
>
> I am unsure what fact you are implying, as the "intended purpose" is
> pretty vague.
>
> ... then that is a "can", not a "will", and is entirely dependent on whether the resolver operator has any HTTPS content other than DNS.
>
>
> If it does not, then the port number is moot, since the preconditions are not met.
>
>
> This whole discussion that I started, is premised entirely on facts, regarding DoH public resolvers not doing any other HTTPS on the IP addresses serving DoH.
>
>
> This, IMHO, is what makes the port number question germane, and ripe for discussion. I see no solid reason to insist on the Template being served on port 443.
>
>
> While I'd prefer the default port used by the resulting templates (and thus by the DoH TLS connections) be different, I haven't given it enough thought to figure out if the port number INSIDE the template is as important.
>
>
> Maybe this is where we are talking past each other, and if so, that is probably my fault, and I apologize.
>
>
> So, to restate: I'm suggesting changing the standardized port FOR THE TEMPLATE RETRIEVAL, without speaking to the in-template URI port number.
>
>
>
>>

---

From: Paul Adair <[email-masked]>
Date: Mon, 18 Nov 2019 09:05:10 +0000

Blocking access to all unapproved recursive resolvers (be they on or off network) has been a best practice recommendation of Infoblox to our enterprise customers for a very long time.  We have updated our recommendations as a result of DoH. We now recommend enterprises block the URLs, FQDNs, and IP addresses of all unapproved DoH services at any relevant enforcement points they may have (RPZ, SWG, NGFW, Host FW, etc).

Paul Adair

On 11/18/19, 3:56 PM, "Add on behalf of Livingood, Jason" <[email-masked] on behalf of [email-masked]> wrote:

---

From: Andrew Campling <[email-masked]>
Date: Mon, 18 Nov 2019 09:26:40 +0000

On Nov 18, 2019, at 13:50, Ted Lemon <[email-masked]> wrote:

> Changing the port number will definitely be ignored by anybody who needs DoH for its intended purpose,
> so it’s a no-op.

I believe that one of the issues that is hindering an effective discussion about DoH is the lack of documented use cases that enable an objective assessment of various proposals.  It would be particularly helpful for the WG charter to include the capture, document and then validate the relevance of use cases so that we have an agreed set for future reference.

> Disabling DoH won’t happen if someone wants it, because it’s up to them to decide, not up to us.

I suspect that one of the areas of angst is who that “someone” is – ie whether it’s an actual end user (individual or enterprise) or whether it’s a tech company driven by a “commercial imperative”.  As above, documented use cases would help here.

Andrew

---

From: Ted Lemon <[email-masked]>
Date: Mon, 18 Nov 2019 05:14:59 -0500

> I believe that one of the issues that is hindering an effective discussion about DoH is the lack of documented use cases that enable an objective assessment of various proposals.  It would be parti…

The protocol is already documented in an RFC, and is being deployed by vendors.   So there are already use cases.   You’re welcome to document them if you think it’s useful.  I don’t think we need an IETF working group for that.

> I suspect that one of the areas of angst is who that “someone” is – ie whether it’s an actual end user (individual or enterprise) or whether it’s a tech company driven by a “commercial imperative”.…

I think it’s inappropriate to describe this as “angst.”   It’s pretty clear how to block DoH.  It’s pretty clear in what cases this makes sense.  What I’m getting at here is that in most cases, the person making the decision is the host operator, not the network operator.  Documenting how a network operator would do this seems like it would be useful; my point was that the network operator can’t do this by convincing the operators of the host and the resolver to use a different port, because from their perspective they have no choice.   So if you start out by saying “first, get the operators of the endpoints to use a different port,” then whatever you do after that will be of no use at all.  Any interception or blocking you’re going to do has to work when the port number is 443, or you are wasting your time.

---

From: Brian Dickson <[email-masked]>
Date: Mon, 18 Nov 2019 19:24:03 +0800

On Mon, Nov 18, 2019 at 6:15 PM Ted Lemon <[email-masked]> wrote:

> I believe that one of the issues that is hindering an effective discussion
> about DoH is the lack of documented use cases that enable an objective
> assessment of various proposals.  It would be particularly helpful for the
> WG charter to include the capture, document and then validate the relevance
> of use cases so that we have an agreed set for future reference.
>
>
> The protocol is already documented in an RFC, and is being deployed by
> vendors.   So there are already use cases.   You’re welcome to document
> them if you think it’s useful.  I don’t think we need an IETF working group
> for that.
>
> I suspect that one of the areas of angst is who that “someone” is – ie
> whether it’s an actual end user (individual or enterprise) or whether it’s
> a tech company driven by a “commercial imperative”.  As above, documented
> use cases would help here.
>
>
>  Documenting how a network operator would do this seems like it would be
> useful; my point was that the network operator can’t do this by convincing
> the operators of the host and the resolver to use a different port, because
> from their perspective they have no choice.
>

Just to clarify this assertion, "they have no choice" -- is that solely
because of what is specified by RFC8484?
(It's not a rhetorical question, btw.)

> So if you start out by saying “first, get the operators of the endpoints
> to use a different port,” then whatever you do after that will be of no use
> at all.  Any interception or blocking you’re going to do has to work when
> the port number is 443, or you are wasting your time.
>

This presumes that the process of "get the operators of the endpoints to
use a different port" is not accomplished by doing an RFC8484-bis to change
the port.

If doing a -bis were done, does that change things?
(That presupposes a lot of things, of course, but it's an IETF document,
and can be updated by the IETF. That happens all the time, with "updates"
or "obsoletes" RFCs.)
(And yes, I realize that deployments would have to have updates done on
both the resolver operator side, and on the client side.)
(It may be necessary to also specify a new namespace specifier analogous to
"https:", call it "doh:". I believe the contents of 2818 could be trivially
transformed by modifying the document name, and changing sections 2.3 and
2.4 to specify "doh:" and the new port number, and doing basic
housekeeping. Then 8484-bis would refer to this in place of 2818, and use
the new doh: URI component in place of https: .)

So, starting the question over again, this time without excluding doing a
-bis as the mechanism on changing the port number.

If the port number was different, the mechanisms available for a network
operator to block DoH would include doing so strictly on the basis of port
number.
And, if the network operator did not block any DoH servers, or only blocked
DoH servers not on the TRR list, DoH to those servers would work exactly as
they would have done had the port number remained 443.

The caveat here is I think this -bis would need to either require the new
port be used exclusively by clients (no client-side override of port number
via template configuration), or to exclude 443 as an override port number.
(I realize that kind of seems draconian, because it is. It's the logical
result of facilitating a scalable way for network operators to block DoH.)

This may seem contentious, because of the original desire to have DoH and
HTTPS traffic muxed together on the same IP addresses.
However, the current reality is that isn't happening to the best of my
knowledge, and I am unaware of any large public resolver operator
committing to doing so.
(Large == enough HTTPS traffic to dwarf expected DoH traffic, and
production resolver, meaning with geographically redundant anycast
addressing and > O(10K qps) DNS traffic.)

I.e. if the port 443 justification has become moot, I think it is
reasonable to look at this pragmatically.
All the public TRR-list (and similar) DoH operators' DoH traffic can be
identified by IP address alone, and blocked the same way.
The remaining issue is the ability of network operators to do any of
several things:

   - Identify all DoH traffic regardless of destination
   - Block all DoH traffic
   - Reactively block individual DoH destinations that have been identified
   as problematic (regardless of how/why)
   - Accommodate mandated legal filtering requirements within appropriate
   jurisdictions (e.g. in the UK) by limiting resolver choice to resolvers
   which comply with those mandates
   - Limit DoH destinations to a white list of addresses (e.g. TRR lists)

And to reiterate: the purpose of this is to reach a balance, and to
specifically encourage and promote the use of TLS for privacy on DNS
traffic, speaking only for myself at least.

Brian

---

From: Brian Dickson <[email-masked]>
Date: Mon, 18 Nov 2019 19:33:42 +0800

On Mon, Nov 18, 2019 at 7:24 PM Brian Dickson <[email-masked]>
wrote:

>
> (It may be necessary to also specify a new namespace specifier analogous
> to "https:", call it "doh:". I believe the contents of 2818 could be
> trivially transformed by modifying the document name, and changing sections
> 2.3 and 2.4 to specify "doh:" and the new port number, and doing basic

I hate doing a self-reply-to-all so soon after my previous email.

I should suggest a better update method: do a new RFC that "updates" 8484,
to add sections 2.5 and 2.6 which mirror 2.3 and 2.4, but use the new name
and port numbers, adding "for DNS" to the section heading.

Brian

---

From: Paul Wouters <[email-masked]>
Date: Mon, 18 Nov 2019 19:50:47 +0800

> On Nov 18, 2019, at 17:26, Andrew Campling <[email-masked]> wrote:
>  
> I believe that one of the issues that is hindering an effective discussion about DoH is the lack of documented use cases that enable an objective assessment of various proposals.

One use case is “never see anything in my DNS stream” and the other use case is “we want to be able to see everything in the DNS stream”.

Documenting the use cases in detail isn’t going to help an “effective discussion” because the two camps can not compromise on their requirements. This is the same issue as the TLS 1.3 discussion on enterprise monitoring.

>   It would be particularly helpful for the WG charter to include the capture, document and then validate the relevance of use cases so that we have an agreed set for future reference.

I honestly don’t see value in this and I don’t see how this WG could produce results other  than advancing one of the two camps at the expense of the other of the two camps.

> I suspect that one of the areas of angst is who that “someone” is – ie whether it’s an actual end user (individual or enterprise) or whether it’s a tech company driven by a “commercial imperative”.…

I think using the word angst here is not a fair description.

Describing the attacker in more detail doesn’t change the fact that one camp has defined all of them as attacker and the other camp wants to be seen as the benevolent party instead. 

Seeing the discussion on this list about the charter alone seems to make it pretty clear that DoH remains a feature or a bug, depending on your view. Producing more documents isn’t going to change that.

Paul

---

From: Dave Lawrence <[email-masked]>
Date: Mon, 18 Nov 2019 09:19:56 -0500

Livingood, Jason writes:
> It seemed the out of bounds topics would make consensus impossible
> which would then prevent WG formation.

(No hats.)

I've got a few thoughts around this general idea of (nigh) impossible
consensus and the various angles on it that have been presented in the
thread so far, but in advance of the meeting I'll try to be succinct
with one main thought that I haven't really seen represented.

Without a suitable home in the IETF for these difficult topics to be
discussed, it does not mean that they are not discussed and yet they
will still colour a lot of the work that the IETF does.  It would
still be useful work for a group to address why they are fundamentally
intractable topics for which no consensus is possible, and release
documentation to that effect.

That is, of course, not the focus of the proposed group.  We're
looking first and foremost for the largely technical work on
relatively policy-neutral topics where it seems likely we can still
achieve some victories.

Yes, I can readily see how including the difficult topics in the
charter looks like an attractive nuisance for getting bogged down on
them, suffocating out the more straightforward work.  On the other
hand it also seems that leaving them out means there's no other good
outlet, and doesn't intrinsically mean that they won't come up.  It
only means that the chairs have a tool of declaring "off topic!" to
manage the list.  Working group chairs already loosely have the
ability to redirect unproductive discussion though, even without that
specific objection of charter-relevance.  Effective chairs/ADs will
keep things on track for work product that we actually achieve.

Yes this whole area represents a significant disruption to the DNS
business-as-usual.  We'll inevitably have some bumps along the way.
I, speaking as an individual, would prefer to see that they be openly
discussed and documented rather than simply declared to be off-limits.

---

From: Ted Lemon <[email-masked]>
Date: Mon, 18 Nov 2019 09:38:44 -0500

David, we can and do discuss these topics in the IETF already. We’re doing it now, and have done it elsewhere in the past. 

What putting it in the charter does is not merely to give us permission to discuss it, which we already have, but rather indicates that there is consensus to work on those things, which there clearly is not. Hence, they do not belong in the charter. 

> On Nov 18, 2019, at 09:20, Dave Lawrence <[email-masked]> wrote:
> 
> Livingood, Jason writes:

---

From: Dave Lawrence <[email-masked]>
Date: Mon, 18 Nov 2019 10:04:05 -0500

Ted Lemon writes:
> What putting it in the charter does is not merely to give us
> permission to discuss it, which we already have, but rather
> indicates that there is consensus to work on those things, which
> there clearly is not. Hence, they do not belong in the charter.  

Apparently despite my efforts I was not clear.  I see it as something
that can be discussed toward the end of still producing documents that
describe why exactly we are not able to otherwise achieve consensus on
some issue.  That, to me, is meaningfully different than just going
round and round in circles.  That provides a useful statement of why
the IETF is where it is on those topics.

---

From: Rob Sayre <[email-masked]>
Date: Mon, 18 Nov 2019 11:43:33 -0800

On Mon, Nov 18, 2019 at 12:04 AM Livingood, Jason <
[email-masked]> wrote:

> *From: *Add <[email-masked]> on behalf of Rob Sayre <
> [email-masked]>
> [JL] It seemed the ‘out of bounds’ topics would make consensus impossible
> – which would then prevent WG formation. So proposing removal was an
> approach to see if we might identify those few areas where there is
> agreement. I am not sure how that is misguided, but it wouldn’t be the
> first time I’ve been accused of being misguided, confused, crazy, deluded
> or whatever else. LOL.
>

:) I didn't accuse the person of being misguided, just the edit.

I like the way the charter is written on these topics, because it makes it
clear that consensus on these topics is extremely unlikely.

thanks,
Rob

---

From: "Glenn Deen" <[email-masked]>
Date: Tue, 19 Nov 2019 06:46:10 +0800

> the IETF is where it is on those topics.

If I’m understanding that the suggestion is to have people write 
drafts on which consensus won’t ever be reached?  If that was done it  
doesn’t quite work in the IETF process as things which are just drafts 
and do not get consensus and do not get adopted carry no weight/meaning 
and expire.  This would be a lot of work by the WG with no work product 
to show for it.

It seems that a large portion of the topics that won’t get consensus 
are in fact policy and not technical topics and hence aren’t good 
topics anyway to work on at the IETF as we create protocols not policy.  
  That’s not to say that the policy world doesn’t provide 
requirements that IETF protocols must address, it’s just that the 
policy isn’t drafted, crafted, or created in the IETF.

If you were to remove the policy topics from the charter it would 
greatly simplify and focus the work product of the WG to streams that 
actually would produce output results.

-glenn

---

From: Rob Sayre <[email-masked]>
Date: Mon, 18 Nov 2019 15:11:48 -0800

On Mon, Nov 18, 2019 at 2:46 PM Glenn Deen <[email-masked]> wrote:

> drafts on which consensus won’t ever be reached?
>

I don't think that's the intent. I believe the aim is to prevent protocol
discussions from being derailed by policy interjections.

That way, WG participants will understand that concerns around items from
the second list in the charter will not delay progress on items from the
first list.

thanks,
Rob

---

From: Dave Lawrence <[email-masked]>
Date: Mon, 18 Nov 2019 19:56:06 -0500

Glenn Deen writes:
> drafts on which consensus won’t ever be reached?  [...] This would
> be a lot of work by the WG with no work product  to show for it.

   "If you choose not to decide / You still have made a choice"
                                  -- Neil Peart

There would be work product.  Published documents that explain why
the issues are sufficiently difficult that the IETF is taking a pass.

Maybe it's because what I am saying is admittedly uncommon in the IETF
that I've not been successful in getting the idea across.  It's
something that I've been advocating for a while though, that we
should have a more effective history of not only proposals that
succeed but also those that, for whatever reason, did not.  

We publish the Request for Comments series, which is what made it
through the gauntlet already, with discussion largely done rather than
beginning.  I'm not suggesting that be changed, just that we do better
about debriefing why drafts failed.  Sometimes it's fairly innocuous,
sometimes it is volatile, but either way it is difficult for someone
who wasn't part of it to know.

These needn't be long, heavy documents the relitigate every aspect
that brought us to the judgment that we just won't be able to reach
consensus.  Sometimes the explanations are fairly simple, that
tautologically the immovable object is in irreconcilable conflict with
the unstoppable force -- or more aptly, that two immovable objects sit
separated by an insurmountable mount.  Sometimes the explanation is
essentially a reference to RFC 3935 (A Mission Statement for the
IETF). RFC 7258 (Pervasive Monitoring Is An Attack), or the like.  In
any event it should be easier to achieve consensus on why consensus
isn't possible, and document it for everyone.

And again, my thoughts here are predicated on my belief that the IETF
not working on something doesn't mean it isn't worked on, it's just
worked on elsewhere to various effects, one of which is sometimes that
it's still a relentless issue within the IETF anyway.  (NAT, anyone?)
The IETF has an ongoing challenge in maintaining its relevance, and I
think that providing more transparency not only through discussion but
also via clear summaries of tough issues is one important aspect of
doing that.

I hope this makes my view clearer.

--tale

---

From: "Glenn Deen" <[email-masked]>
Date: Tue, 19 Nov 2019 09:11:33 +0800

> I hope this makes my view clearer.

So basically document what’s not being worked on and why it’s not 
being worked on?

---

From: Dave Lawrence <[email-masked]>
Date: Mon, 18 Nov 2019 21:02:13 -0500

> So basically document what’s not being worked on and why it’s not 

Yes, I think the whys for the record are important.

---

From: Patrick McManus <[email-masked]>
Date: Tue, 19 Nov 2019 10:12:59 +0800

such a document is not explicitly in the charter as a deliverable. indeed
there are no documents in the charter as deliverables - though the scope
allows, without requiring, many things. This is not good footing for a high
tension group.

in your view - how is this compatible with the charter? Would it be subject
to the mysterious 'full consensus' requirement? Do you believe we would
have full consensus on such a thing (I do not).

Alternatively, are you suggesting the WG produce a document to be published
without full IETF consensus on its contents? Such things have been done,
but are imo not a good idea. Let's be clear.

-Patrick

---

From: Dave Lawrence <[email-masked]>
Date: Mon, 18 Nov 2019 21:23:23 -0500

Patrick McManus writes:
> such a document is not explicitly in the charter as a
> deliverable. indeed there are no documents in the charter as
> deliverables - though the scope allows, without requiring, many
> things. This is not good footing for a high tension group.
> 
> in your view - how is this compatible with the charter?

I agree with your first paragraph, and my own hope is that as we work
to an acceptable charter then it would be clearer on this.

> Would it be subject to the mysterious 'full consensus' requirement?

I personally do not agree with the full consensus term, for the
objections that others have already raised on the list.  I think we
should use consensus as the IETF has traditionally understood it.

---

From: Rob Sayre <[email-masked]>
Date: Mon, 18 Nov 2019 18:52:34 -0800

> should use consensus as the IETF has traditionally understood it.

That term is kind of strange. Does it mean "unanimity"?

thanks,
Rob

---

From: Andrew Campling <[email-masked]>
Date: Tue, 19 Nov 2019 02:55:04 +0000

On Mon, Nov 19, 2019 at 23:04 Rob Sayre <[email-masked]> wrote:

> I don't think that's the intent. I believe the aim is to prevent protocol discussions

> from being derailed by policy interjections.
>
> That way, WG participants will understand that concerns around items from the
> second list in the charter will not delay progress on items from the first list.

It would quite a lot of work to detail everything that a given WG won’t cover! I think it more efficient for the charter to detail what is in scope for the WG to avoid anyone wasting time and energy on out of scope matters – although of course that is a choice available to anyone should they wish to document such items.

Andrew

---

From: Melinda Shore <[email-masked]>
Date: Tue, 19 Nov 2019 11:03:05 +0800

On 11/18/19 9:55 PM, Andrew Campling wrote:
> It would quite a lot of work to detail everything that a given WG won’t
> cover! 

It's not uncommon to include charter text describing things that
are out-of-scope, when it's ambiguous, unclear, or (as in this
case) tempting (see, for example,
https://datatracker.ietf.org/wg/ccamp/charter/).  I think it's necessary
to be clear that, should
a working group in this space be chartered, that working group would
not work on those policy-related questions.  I would go as far as to
say that I would oppose chartering a working group if the charter
did not clearly identify those things as being out-of-scope.

Melinda

---

From: Adam Roach <[email-masked]>
Date: Tue, 19 Nov 2019 11:04:48 +0800

[as an individual]

On 11/19/19 10:55, Andrew Campling wrote:
>
> On Mon, Nov 19, 2019 at 23:04 Rob Sayre <[email-masked]>wrote:
>
> It would quite a lot of work to detail everything that a given WG 
> won’t cover!
>

I don't read the proposal as suggesting that we list, for exclusion, 
every topic in the universe save those that are in scope.

There is a very small set of topics that have historically been proposed 
to be covered by DOH/ADD/ABCD conversations, and about which it is 
increasingly clear consensus is unlikely to emerge from an IETF working 
group. For avoidance of doubt, charters explicitly rule a small, 
discrete set items out of scope fairly regularly. This is a reasonable 
request with good precedent.

/a

---

From: "Livingood, Jason" <[email-masked]>
Date: Tue, 19 Nov 2019 03:30:14 +0000

I could see some logic in that, in documenting what various issues & points of view on an issue may be.

On 11/19/19, 8:56 AM, "Add on behalf of Dave Lawrence" <[email-masked] on behalf of [email-masked]> wrote:

    --tale

    --
    Add mailing list
    [email-masked]
    https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/add__;!rx_L75ITgOQ!THrCx0akgf4znn34C15s3BXnf4Uyl2Aq-4xbLF76lg4mLdREm5-b_cMjYs_wwWH4_eI3tg$

---

From: Brian Dickson <[email-masked]>
Date: Tue, 19 Nov 2019 12:20:01 +0800

This is intended as a background article to provide information for
participants who may not have first-hand experience operating DNS services
at scale,

Apologies to anyone who already knows this stuff; the target audience is
everyone else.

TL;DR: It is probably not reasonable to expect any operators of DNS
services-at-scale to offer other (non-DNS) services on the exact same IP
address and port number, ever.

Caveats and personal background:
I've worked at a number of companies whose product offerings include some
flavor of at-scale DNS services, and have participated in industry
organizations and become familiar with a number of other operators'
offerings.
There is generally no "secret sauce" involved; everyone doing this
generally relies on some combinations of COTS hardware, open source or home
grown software, and substantial integration with networking infrastructure.

These observations and analyses are pretty uniform, regardless of whether
the "service" being offered is recursive DNS (public or otherwise),
delegation-only (root or TLD), or authoritative (generically "second level
domain" aka SLD).

In order to provide high availability and performance, doing DNS at scale
generally involves the use of "anycast". This means announcing the same IP
prefix(es) in multiple locations, typically with BGP towards transit
providers and peer ISPs and enterprise networks.

The first rule of anycast is, only announce externally that which is
responding to queries internally. If the server(s) providing the service
fail, continuing to announce the prefix will result in service degradation
or failure, to at least the relevant "watershed" of clients that prefer
that specific anycast instance.

This first rule has a number of corollaries, which may or may not apply for
a given type of service or particular architecture. Generally,  the
preference is to minimize the number of services running within any given
prefix, even going so far as to minimize the number of host addresses used
on the prefix. Many operators do this by limiting each prefix to having
only a single address in use. The reason for minimizing addresses and
services is that the total failure of a single service on a single address
may be sufficiently problematic as to require the prefix to be withdrawn
from that location. This can impact global performance and availability
statistics, which in some operators' cases, is a big deal.

The primary ingress path for a BGP anycast node is generally a router,
although this may either a hardware device or sorftware-based router.
Routers do their work strictly using the destination IP address, and
nothing else, when forwarding packets. This rules out any kind of
port-based or source-address based routing. Routers may do stateless ACLs
(access control lists) to white-list or black-list ports, protocols, and
addresses, on source and/or destination basis.

The next element in a BGP anycast node may optionally be some kind of
hardware load balancer. Alternatively, the router at the previous step may
perform a load-balancing style hashing function. Either way, that function
is generally going to be based on a hash of the 5-tuple (source IP,
destination IP, source port, destination port, protocol). The intent is to
ensure "sticky" connections, which is particularly important for TCP-based
transport flows, including TLS.

In the case of TLS, there may be a TLS termination point above the actual
servers, typically for hardware acceleration. For the most part, this can
be ignored for purposes of the address/port issue, as the termination point
will typically need to be configured for a specific service exclusively for
a given IP address and port combination.

Finally, at the host level, there will typically be a horizontally scaled
set of servers, all serving identical content for any given IP and port
combination, including what service is handled on which port.

Multiplexing services is only feasible if those services have some
additional differentiator, such as host name as signaled by SNI for TLS,
and then only if the performance characteristics and requirements of those
differentiated services are roughly equivalent.

Web pages and DNS service generally do not share delay tolerance and
performance requirement characteristics. DNS volumes are typically high
transaction rates with high throughput, and require not just low latency,
but low upper bounds on latency. Web servers may be designed towards lowish
latency towards individual pages or components, but do not generally have
the ability to place upper bounds on transmitted data or outbound queueing.

In short, there is no place in the BGP anycast architecture above the
server itself where it is even possible to demux DoH and regular HTTPS
traffic, and the server itself is extremely unlikely to meet performance
requirements for both kinds of traffic simultaneously.

The general practice for web hosting is to have individual servers
internally anycast for availability and with a 1:1 mapping between a set of
domains and a single IP address, scaled as necessary. And very similarly,
DNS services will also be anycast on their own dedicated IP addresses (and
generally speaking entire prefixes), serving only DNS traffic. The
infrastructure above them may be identical,  but the IP addresses of web
services and DNS services do not overlap (if both kinds of service are
present).

This is driven by performance, scalability, the foundational technologies
(BGP, IP address aggregation, routing/switching, hashing 5-tuples), and
applies to at-scale DNS services across the board.

The gist of this is: even if infrastructure operated by a given entity
provides a common front-end to both DNS and web services, the IP addresses
used for those services should always be expected to be totally distinct,
and is not anticipated to change in the foreseeable future.

Brian

---

From: Jari Arkko <[email-masked]>
Date: Tue, 19 Nov 2019 13:23:16 +0800

As I said earlier on another thread, my crystal ball sees two areas of development:

1. Rapid and widespread deployment of DNS encryption via DOH. This is a good thing.

2. Changes in deployment models for DNS. But the crystal ball is cloudy, we could either end up with a different distributed model than we have today (e.g., along the lines of Adaptive DNS) or with a centralised deployment model where large parts of Internet DNS queries go to few places. The latter outcome would be very unfortunate, in my opinion it is one of the biggest privacy dangers for the current Internet.

I believe anything we can do to affect the direction of #2 for the less centralised way is essential work for the IETF, and should be taken up by the proposed working group. This needs to include both technical work (e.g., discovery, use of multiple resolvers, distributed architectures a la Oblivious or Adaptive DNS) as well as discussion and analysis of deployment models and their implications. I don’t believe this is work that should be feared by people who want to improve the privacy of the DNS system. In fact, it seems essential for our understanding of the issues, and in my view also in line with the requirement that we understand pervasive surveillance implications of our work.

Jari

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 18 Nov 2019 21:29:44 -0800

On Mon, Nov 18, 2019 at 9:23 PM Jari Arkko <[email-masked]> wrote:

> 2. Changes in deployment models for DNS. But the crystal ball is cloudy,
> we could either end up with a different distributed model than we have
> today (e.g., along the lines of Adaptive DNS) or with a centralised
> deployment model where large parts of Internet DNS queries go to few
> places. The latter outcome would be very unfortunate, in my opinion it is
> one of the biggest privacy dangers for the current Internet.
>

I feel like I'm repeating myself, but we are already in that world to a
great extent. Roughly 10% of DNS queries go to 8,8.8.8 right now and in
many markets (e.g., the US, but not just in the US) Internet service
provision is dominated by a few large providers.

-Ekr

---

From: Ted Lemon <[email-masked]>
Date: Tue, 19 Nov 2019 02:23:17 -0500

> It would quite a lot of work to detail everything that a given WG won’t cover! I think it more efficient for the charter to detail what is in scope for the WG to avoid anyone wasting time and energ…

It might be worth noting here that if an item is chartered and adopted, in some sense it presumptively has consensus.  At that point, “no consensus” means that there are objections that have been raised that have not been addressed.

So it actually _is_ important that we get any charter right.   As Adam mentioned, we don’t have to exclude everything, but we should exclude things that might, on an off day, get adopted.  It’s important to be clear about what is not in charter when it’s something that we already know some participants would like to be in charter.

To Dave’s point, that it is worth documenting why we didn’t do something, I agree with that point in principle, but that’s _not_ a reason to put the thing in charter.  If you want to document why there isn’t consensus to do X, putting X in charter is the wrong thing to do.  What you should put in charter is “document why there is no consensus to do X.”   If you don’t feel that you know for sure that there is no consensus to do X, or if you don’t want to put it in the charter that way, then explicitly declare it out of scope.

---

From: Vittorio Bertola <[email-masked]>
Date: Tue, 19 Nov 2019 10:36:39 +0100 (CET)

Il 19 novembre 2019 06:29 Eric Rescorla <[email-masked]> ha scritto:

I feel like I'm repeating myself, but we are already in that world to a great extent. Roughly 10% of DNS queries go to 8,8.8.8 right now and in many markets (e.g., the US, but not just in the US) Internet service provision is dominated by a few large providers.

For those that have not seen them yet, I recommend APNIC's great statistics at
https://stats.labs.apnic.net/rvrs . You can use them to get an estimate of how many people use their local resolver ("sameas"), another resolver in their own country ("samecc"), or the various global public services - and you can break the data down to country level.

Now, how much "sameas" is concentrated likely depends on how much the Internet access market is concentrated in the specific country, but still the ISPs generally differ country by country, so seen on a global scale it's way more diverse than the global operators, that are the same in every country.

By the way, this is also useful to measure the potential "jurisdiction shift" effect of some deployment models: e.g. in Europe, today ~90% of the queries (sameas+samecc) are served in-country.

--