Subject: [hrpc] Proposal for a side-meeting on services centralization at IETF 104 Prague

From: Stephane Bortzmeyer <[email-masked]>
Date: Mon, 11 Mar 2019 18:02:18 +0100

[Resent with the correct list of working groups.]

[Sorry for the long list of working groups but the discussion already
started in different places.]

There are been some discussion about DoH (DNS-over-HTTPS, RFC 8484)
deployment and the risk of centralization of Internet services. (See
for instance drafts [this is not an endorsement]
draft-bertola-bcp-doh-clients, draft-reid-doh-operator and
draft-livingood-doh-implementation-risks-issues.)

It was suggested <wikipedia>Reference necessary</wikipedia> to have a
side meeting in Prague at IETF 104. I propose monday, 1400-1600 in
Tyrolka. The proposal is at
<https://trac.ietf.org/trac/ietf/meeting/wiki/104sidemeetings>. You
are welcome to agree/disagree/meet in a bar instead.

---

From: Vittorio Bertola <[email-masked]>
Date: Mon, 11 Mar 2019 18:57:03 +0100 (CET)

> Il 11 marzo 2019 alle 18.02 Stephane Bortzmeyer <[email-masked]> ha scritto:
> 

Why not in the Wednesday timeslot that was specifically set aside for side meetings? Also, I'm wondering whether a 40-people room is enough (may be, may be not).

Moreover, centralization is not the only Do*-related problem category that has been raised (my draft alone lists eight others). So the focus of the meeting should be on whether, where and how to deal with all of them, though some of them may later be deemed off mission for the IETF. But first of all we need to agree on a venue and process.

Ciao,
-- 

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

---

From: Allison Mankin <[email-masked]>
Date: Mon, 11 Mar 2019 13:59:25 -0400

Perfect idea, very good use of the Wednesday slot.

On Mon, 11 Mar 2019 at 13:57, Vittorio Bertola <vittorio.bertola=
[email-masked]> wrote:

> Why not in the Wednesday timeslot that was specifically set aside for side
> meetings? Also, I'm wondering whether a 40-people room is enough (may be,
> may be not).
>
> Moreover, centralization is not the only Do*-related problem category that
> has been raised (my draft alone lists eight others). So the focus of the
> meeting should be on whether, where and how to deal with all of them,
> though some of them may later be deemed off mission for the IETF. But first
> of all we need to agree on a venue and process.
>
> Ciao,
> --
>
> _______________________________________________
> hrpc mailing list
> [email-masked]
> https://www.irtf.org/mailman/listinfo/hrpc
>

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Tue, 12 Mar 2019 09:57:59 +0100

On Mon, Mar 11, 2019 at 01:59:25PM -0400,
 Allison Mankin <[email-masked]> wrote 

> Perfect idea, very good use of the Wednesday slot.

New date and place registered at
<https://trac.ietf.org/trac/ietf/meeting/wiki/104sidemeetings>,
wednesday, Karlin 1/2, 1500 to 1700. (Note there is registry lock side
meeting just before, for domain name industry people.)

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Tue, 12 Mar 2019 10:01:42 +0100

On Mon, Mar 11, 2019 at 06:57:03PM +0100,
 Vittorio Bertola <[email-masked]> wrote 
 a message of 18 lines which said:

> Moreover, centralization is not the only Do*-related problem
> category that has been raised (my draft alone lists eight others).

IMHO, this is precisely the biggest problem with these three drafts:
they accumulate a lot of unrelated rants, and it is important to split
between issues that are really DoH-specific from more general issues.

Warren Kumari did a good job of sorting that out in
<https://mailarchive.ietf.org/arch/msg/dnsop/GaO9UDiVCeAzCKxbPt5V1D9N450>. I
quote him:

1: the protocol,
2: the deployment concerns,
3: "resolverless DNS",
4: the loss of visibility from encrypting the DNS

IMHO, this makes several side meetings. People are welcome to organize
more.

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 12 Mar 2019 20:14:49 +1100

Hi,

I'm already starting to pile up conflicts on Wednesday. I'm also very conscious that we had a side meeting about similar issues in Singapore (IIRC), and didn't make much progress at all in that time. Are we going to be able to productively use two hours for this? Could we come up with a more focused agenda and just use an hour?

Cheers,

> On 12 Mar 2019, at 7:57 pm, Stephane Bortzmeyer <[email-masked]> wrote:
> 
> Doh mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/doh

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

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Tue, 12 Mar 2019 10:17:45 +0100

On Tue, Mar 12, 2019 at 08:14:49PM +1100,
 Mark Nottingham <[email-masked]> wrote 
 a message of 32 lines which said:

> I'm also very conscious that we had a side meeting about similar
> issues in Singapore (IIRC), and didn't make much progress at all in
> that time.

This time, we have drafts (poor ones, IMHO, but it's better than a
discussion without written proposals).

> Are we going to be able to productively use two hours for this?
> Could we come up with a more focused agenda and just use an hour?

You are the first to suggest to focus, until now, all remarks (both on
and off-list) have been people asking to *enlarge* the agenda :-)

---

From: Vittorio Bertola <[email-masked]>
Date: Tue, 12 Mar 2019 10:46:35 +0100 (CET)

> Il 12 marzo 2019 alle 10.01 Stephane Bortzmeyer <[email-masked]> ha scritto:
> 
> 
> they accumulate a lot of unrelated rants, 

They are not unrelated, they are all effects of the same thing and you cannot deal with them separately, as some practices that would address one of the problems could worsen some of the others. Also, the fact that some of these are not problems for you does not imply that they are not problems for others, and if you want to get consensus, you have to address everyone's concerns and not just yours.

Also, the reason why this is a difficult problem is exactly that it affects many things at once. It is fine to break down the analysis into single issues, but when it comes to what to do next, if you start several parallel work threads without any clear coordination plan, you will just end up with several conflicting proposals.

So, rather than focusing on any specific entry of the list of issues, I think that the most urgent thing to discuss would be where to have the discussion (so that we can stop crossposting entire threads to four groups) and how to organize it (objectives, working items etc.).

Ciao,
--

---

From: Paul Vixie <[email-masked]>
Date: Tue, 12 Mar 2019 18:52:43 +0000

> between issues that are really DoH-specific from more general issues.

when you refer to something as a rant, you diminish and disrespect it.

any concern about the inability of a network operator to maintain possession 
of their RDNS control plane is on-topic for DoH, simply because RFC 8484's 
stated goal is to prevent on-path interference with DNS operations.

please do not relegate discussions about the loss of operator control over the 
RDNS control plane to some mailing list where DoH is not front-and-center. 
their intentions were clear. therefore they should participate in the results.

> 4: the loss of visibility from encrypting the DNS

that is a useless distinction.

> IMHO, this makes several side meetings. People are welcome to organize

in usenet, we used to say "please take this to some mailing list" by which we 
meant "...that i won't be joining, so that i no longer have to listen to you."

so far, most responses to RDNS control plane ownership issues have received a 
similar response. "please find someone who cares, and talk to them about it."

that's going to make the coming fight harder. we should be looking to make it 
easier.

vixie

---

From: Ted Lemon <[email-masked]>
Date: Wed, 13 Mar 2019 20:48:53 -0400

On Mar 12, 2019, at 2:52 PM, Paul Vixie <[email-masked]> wrote:
> RDNS control plane

Although it’s certainly true that DNS is used as a control plane by many operators, there is no standard “RDNS control plane.”   If you think there should be, that’s something that the IETF could conceivably work on, but it’s not something that the DoH working group is obligated to treat as a standard use of DNS.   And I don’t think it’s a topic on which there is consensus in the IETF.

The problem with the discussion we’ve been having about DoH and how it affects your “RDNS control plane” is that we’re talking past each other, not that the discussion should be had elsewhere.   It’s fine for there to be a discussion, but if there is going to be a discussion, participants need to engage constructively, and not just fling slogans at each other.

---

From: Paul Vixie <[email-masked]>
Date: Thu, 14 Mar 2019 05:32:48 +0000

On Thursday, 14 March 2019 00:48:53 UTC Ted Lemon wrote:
> > please do not relegate discussions about the loss of operator control over
> > the RDNS control plane
> 
> Although it’s certainly true that DNS is used as a control plane by many
> operators, there is no standard “RDNS control plane.”   ...

i don't think lack of standardization is the same as not existing. devices 
which honour the dhcp-assigned rdns service, work as expected, and as 
intended. devices who ignore that setting and seek their own rdns by their own 
internal configuration, will often not work at all.

because many of us amend our locally visible dns namespace with things like 
.corp or .home or .local, it's even more vital that devices respect the rdns 
assignment i make. the dns content i want to be visible on my network, have to 
be visible on my network.

because many of us won't allow pirate or malware or otherwise undesired DNS 
lookups to succeed, either because we don't like the name, or we don't like 
the result of the query, or we don't like some name server that would be 
involved in resolving it. the dns content i don't want to be visible on my 
network, have to not be visible on my network.

from the days before dhcp when we typed these numbers in by hand, until now, 
it has always been the expectation that rdns was part-and-parcel of local 
network service. no different in that regard from dhcp or arp, neither of 
which is standardized under the heading, "control plane", yet, are.

so i think i'm not going to follow you down this terminological rabbit hole. 
the reason that internet creations of yours will work better on my network if 
you treat the rdns as part of my control plane is, because it's my network and 
that's how i operate it. you're not welcome to bypass it, nor answer dhcp 
requests when you're not my dhcp server, nor answer arp requests when you 
aren't the device i assigned that address to.

you can call that tautological if you wish. but it's the life my networks 
lead. external DoH providers are explicitly not welcome to provide service to 
malware or intruders who get into my network -- because rdns is part of my 
control plane, and like arp and dhcp, i control it and i monitor it, for 
$reasons.

> The problem with the discussion we’ve been having about DoH and how it
> affects your “RDNS control plane” is that we’re talking past each other,
> not that the discussion should be had elsewhere.   It’s fine for there to
> be a discussion, but if there is going to be a discussion, participants
> need to engage constructively, and not just fling slogans at each other.

i think i've flung considerably more than slogans, and, it's been exhausting.

vixie

---

From: "Ralf Weber" <[email-masked]>
Date: Thu, 14 Mar 2019 10:41:41 -0400

Moin!

On 13 Mar 2019, at 20:48, Ted Lemon wrote:

> Although it’s certainly true that DNS is used as a control plane by 
> many operators, there is no standard “RDNS control plane.”   If 
> you think there should be, that’s something that the IETF could 
> conceivably work on, but it’s not something that the DoH working 
> group is obligated to treat as a standard use of DNS.   And I don’t 
> think it’s a topic on which there is consensus in the IETF.
Well as you said it is something that will not get consensus at the 
IETF, so why work on that? However as you said these RDNS control planes 
exist in real life and even if there is no IETF standard for it, the 
IETF should consider actual deployments when doing work and not just 
IETF standards IMHO and that is what the drafts out there trying to do, 
bring the view of people operating these services into the IETF.

> The problem with the discussion we’ve been having about DoH and how 
> it affects your “RDNS control plane” is that we’re talking past 
> each other, not that the discussion should be had elsewhere.   It’s 
> fine for there to be a discussion, but if there is going to be a 
> discussion, participants need to engage constructively, and not just 
> fling slogans at each other.
So you are ok with having this discussion in DoH, which is good, as the 
DoH protocol caused some application providers to experiment with 
switching resolution per default away from OS and the local network 
provider. A lot of the exhausting thread however was about moving the 
discussion away from DoH. I’ll personally have the discussion 
anywhere, but given that the drafts have been given time in doh and 
people might have planned there schedule around that it should be the 
place. I also think Paul and others have engaged constructive in the 
discussion about the topic.

So long
-Ralf
—--
Ralf Weber

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 14 Mar 2019 14:53:26 +0000

Hiya,

On 14/03/2019 14:41, Ralf Weber wrote:
> the DoH protocol caused some application providers to experiment with
> switching resolution per default away from OS and the local network provider

I wasn't aware that some application provider was doing this
as their default (assuming that's what "per default" means).
Can you provide details?

I am aware of what FF/CF have done but I don't believe that
was on by default.

Thanks,
S.

PS: Apologies if there's a reference in one of the I-Ds, but
I don't recall there being one for that assertion.

---

From: "Ralf Weber" <[email-masked]>
Date: Thu, 14 Mar 2019 11:17:23 -0400

Moin!

On 14 Mar 2019, at 10:53, Stephen Farrell wrote:
>> provider
The experiment Mozilla did switched these 25000 users to use DoH and
gave that option as the default option:
	https://blog.nightly.mozilla.org/2018/08/28/firefox-nightly-secure-dns-experimental-results/

> I am aware of what FF/CF have done but I don't believe that
It was only for nightly users and only for users that have opted in for
experiments, but it still IMHO gave a bad impression, as it was viewed
by many as a plan send all future DNS traffic to Cloudflare.

I still think giving a singular known option as it is the case currently 
if
you click the Dns over HTTPs button in Firefox is a bad idea, but at 
least
it is off per default.

So long
-Ralf
—--
Ralf Weber

---

From: Ted Lemon <[email-masked]>
Date: Thu, 14 Mar 2019 12:33:54 -0400

On Mar 14, 2019, at 10:41 AM, Ralf Weber <[email-masked]> wrote:
> Well as you said it is something that will not get consensus at the IETF, so why work on that? However as you said these RDNS control planes exist in real life and even if there is no IETF standard for it, the IETF should consider actual deployments when doing work and not just IETF standards IMHO and that is what the drafts out there trying to do, bring the view of people operating these services into the IETF.

Sorry, I expressed myself fairly poorly.

What I mean is that it’s important to agree on what we are talking about before we try to talk about it, because otherwise a lot of useless back-and-forth happens where one person is arguing from one set of assumptions, and another person is arguing from a different set of assumptions, and neither is able to feel heard.

It can feel very political to go meta on a discussion like this, but I think it’s important for people to actually agree on what the various views are of the problem and solution spaces.   That is, not agree that this problem is the correct view of the problem, or that that solution is the correct solution to a problem, but to enumerate all the views of the problem that various participants have, and enumerate all the solutions to these various problems that people are interested in.

With that overview, a winnowing process is possible; without it, we just have endless non-terminal discussion.

---

From: "Vinicius Fortuna [vee-NEE-see.oos]" <[email-masked]>
Date: Thu, 14 Mar 2019 13:50:44 -0400

Paul, I'm trying to understand your scenario.

If you ran your own DoH server in your network (doing RDNS or whatnot), and
the DoH server is distributed to clients via DHCP + a protocol upgrade
mechanism, would that address the concerns you are listing?

Vinicius Fortuna

---

From: Paul Vixie <[email-masked]>
Date: Thu, 14 Mar 2019 19:50:46 +0000

i've removed "[email-masked]" from the CC headers, at the WG chair's 
request. note, the main topic of this message is DNS privacy's implications.

On Thursday, 14 March 2019 17:50:44 UTC Vinicius Fortuna [vee-NEE-see.oos] 
> mechanism, would that address the concerns you are listing?

no. the new risk intended by DoH comes from its expected ubiquity. two of its 
design assumptions are wrong.

one wrong assumption is that all users and apps operating inside my network 
deserve rdns service from third parties that is invisible to me (as network 
operator) and which is therefore subject to neither my surveillance nor my 
control. it turns out that some users are intruders and some apps are malware, 
and i do not want them to have the capability of invisible third party rdns. 

the second wrong assumption is that all on-path interferers have ill intent 
and do not deserve to surveil or control their network's rdns. as a parent, my 
interest in monitoring and control of the control plane used by my family, 
including rdns, is not a matter to be litigated against IETF consensus. the 
same thing happens at a larger scale in my corporate network.

so, no DoH service i can add would have any impact on the intended risks of 
DoH. i may offer it anyway, for clients who can't use DoT. but for my actual 
purposes both a user of networks and an operator of networks, DoT is both 
sufficient and better.

my costs to mitigate the risks intended by DoH will in some cases be cheap, 
like enumerating the so-called "public DNS" providers who offer it, and 
blocking them at my IP firewall.

DoH risk mitigation costs will be much higher for me when DoH is offered by an 
IP that i have other business with, for example if i need access to a google 
API or service, and the same IP also offers DoH. there, i'll have to run a tls 
proxy, and break any client who tries to use outbound TCP/443 directly.

many people here have mistakenly asserted that i had that risk anyway, and 
that this mitigation cost should already be on my ledger. this is mistaken for 
two reasons, both of which owe to security economics.

first, because some of my networks have an outbound TCP/443 whitelist which 
may have included IP addresses i previously thought i could trust not to offer 
invisible third party rdns to intruders or malware (or children) on my 
network.

second, because some of my networks only close the barn door after badness has 
passed through -- that is, the IP blacklist is amended after a detection 
event, since whitelisting wasn't feasible. defense that only works in the 
future is still quite a bit better than defense that will not work in the 
future. DoH, by intending to be invisible inside flows i already accept, will 
raise my defense costs, forever.

so, the costs of proxying TCP/443 to well known IP addresses was not already 
on my ledger, but must be now, and will have far-reaching effects.

not all agents (users and apps) inside my network are friendly and trusted, 
nor can they be expected to use DoH only when MDM tells them it is ok.

not all network operators who monitor or control their rdns are unfriendly or 
untrustworthy.

DoH is intended to be, and is, a security economics disaster for edge network 
operators.

vixie

---

From: Vittorio Bertola <[email-masked]>
Date: Thu, 14 Mar 2019 21:10:00 +0100 (CET)

> Il 14 marzo 2019 alle 15.53 Stephen Farrell <[email-masked]> ha scritto:
> 
> Hiya,

What caused all this fuss is that they did not turn it on by default, but they publicly said they "would like" to do it in the future, here (at the end, "what is the status"):

https://hacks.mozilla.org/2018/05/a-cartoon-intro-to-dns-over-https/

and also here, more or less at half the text, they say "Firefox does not *yet* use DoH by default" (asterisks are mine):

https://blog.nightly.mozilla.org/2018/06/01/improving-dns-privacy-in-firefox/

Mozilla also had several calls with concerned parties in which they were asked to clarify, and they confirmed that while they are considering all the feedback, this is still in their plans for the future.

So we are not all having hallucinations here :-) and even if Mozilla decided to announce that their plans are changed and that idea is now off the table, which has not happened yet, now everyone is aware that this could be done by any application at any time in the future; so, speaking from a policy perspective, it would be nice to agree (if possible) that that is a bad idea, at least if certain conditions are not met, and record that consensus somewhere. It would not prevent anyone from doing something else if they want, but that's true of any standard; but it would at least provide some guidance for well behaved application makers.

Regards,