Subject: [Add] Proposed charter and BoF request for IETF 106

From: Barry Leiba <[email-masked]>
Date: Wed, 9 Oct 2019 09:38:37 +0200

Hi, all,

The IESG has worked up a proposal for a possible working group, which
we're tentatively calling "ABCD", for "Application Behavior
Considering DNS".  We can discuss the charter proposal here, and
expect to approve a working-group-forming BoF for Singapore.

I realize that the charter proposal isn't going to please everyone
(and perhaps will please no one), but it's something that, at a first
level of review, the IESG accepts and will likely want to move forward
with.

See the proposal here:
      https://trac.tools.ietf.org/bof/trac/wiki/WikiStart

I am also going to remove the moderation of this list for now.  Let's
see how that goes.  Please continue being calm, thoughtful, and
respectful (and thanks for having done that during the moderation
period).

Barry

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 9 Oct 2019 08:51:36 +0100

Hiya,

>       https://trac.tools.ietf.org/bof/trac/wiki/WikiStart

I understand that figuring out what to do here is tricky,
but it's unclear to me how that text moves us along at all.
I'm also unconvinced that adding a new WG is the right
approach.

I see two main problems:

1) What is out of scope? The current text seems to leave
everything related to DNS privacy and it's impacts as being
in scope. So far, having such a broad scope doesn't seem
to me to have gone well.

2) "This working group will coordinate with the DNSOP (OPS
Area), DPRIVE (INT Area), and DOH (ART area) working groups,..."
seems to me to mean that the confusion with proposals and
discussions we've seen will continue. Moving from 3 WGs and
a non-WG list, to 4 WGs, doesn't seem likely to help that
aspect. For a specific example DPRIVE is already working
on a BCP that would likely overlap with one of the initial
focus areas listed here. That makes no sense to me.

Cheers,
S.

---

From: Jim Reid <[email-masked]>
Date: Wed, 9 Oct 2019 09:41:29 +0100

> On 9 Oct 2019, at 08:51, Stephen Farrell <[email-masked]> wrote:
> 
> I see two main problems:
> 
> in scope. 

What aspects of DNS privacy should be out of scope for the proposed WG?

At first glance, the proposed charter looks fine.

I accept a broadly scoped WG could be awkward. Though what’s being proposed here seems reasonably well scoped. If the WG has strong leadership and everyone uses common sense, I think it would work. Famous last words...

BTW, it’s “its impact”. Yes, I need to resign from the apostrophe police and get out more. :-)

> focus areas listed here. That makes no sense to me.

One possibility for dealing with this overlap could be for the new WG to look at the deployment and operational considerations surrounding whatever DNS-privacy-friendly technologies emerge from DPRIVE. I suppose that could mean the BCP that’s under development moves to the new WG.

One meta-question: would ABCD be in the art area? I think ops might be a better home for it.

---

From: Rob Sayre <[email-masked]>
Date: Wed, 9 Oct 2019 15:54:47 +0700

> level of review, the IESG accepts and will likely want to move forward

Hi,

Who wrote the charter? Shouldn’t the BoF proponents be 1-3 individuals,
rather than a mailing list?

The proposed charter looks extremely misguided to me. But a proposal that
no one will put their name on doesn’t even deserve an argument.

thanks,
Rob

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 9 Oct 2019 10:04:16 +0100

Hiya,

On 09/10/2019 09:41, Jim Reid wrote:
>> 1) What is out of scope? The current text seems to leave everything
>> related to DNS privacy and it's impacts as being in scope.
> 

Based on the current text, I don't know. If we are going
to have N WGs in this space, it seems important that we
have clarity as to the scope of those.

> I accept a broadly scoped WG could be awkward. Though what’s being
> proposed here seems reasonably well scoped. If the WG has strong
> leadership and everyone uses common sense, I think it would work.

I wonder if common sense and WG chairs are enough to
deal with the different perspectives/interests here.

> Famous last words...

Indeed.

> police and get out more. :-)

Oops. I depend on you to keep on keeping on improving me:-)

> 
>> 2) "This working group will coordinate with the DNSOP (OPS Area),
>> DPRIVE (INT Area), and DOH (ART area) working groups,..." seems to
>> me to mean that the confusion with proposals and discussions we've
>> seen will continue. Moving from 3 WGs and a non-WG list, to 4 WGs,
>> doesn't seem likely to help that aspect. For a specific example
>> DPRIVE is already working on a BCP that would likely overlap with
>> one of the initial focus areas listed here. That makes no sense to
>> me.
> 
> One possibility for dealing with this overlap could be for the new WG
> to look at the deployment and operational considerations surrounding
> whatever DNS-privacy-friendly technologies emerge from DPRIVE. 

Meaning it wouldn't develop any new protocol? Not sure
that'd work.

> I
> suppose that could mean the BCP that’s under development moves to the
> new WG.
> 

That's one for the IESG. I suspect the right answer will be
fairly obvious or a "doesn't matter" if/when there's a final
charter. If that is not the case, then I'd really wonder if
the charter is the right one.

Cheers,
S.

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 9 Oct 2019 04:58:27 -0700

Barry,

I took a first look at your proposed ABCD charter. Thanks for
proposing something.

At a high level, I think there are some good areas for discussion
here, but they're going to get swamped by the inclusion of a bunch of
contentious topics we're not likely to get resolution on.

I think this would be much stronger if it focused entirely
on technical matters on which there is at least some agreement,
specifically:

- Signalling that the network has DoH support, who provides it,
  and (potentially) what their policies are.

- Signaling that the network has some kind of filtering policy
  that might make the application think twice about using
  DoH.

- Something like the apple proposal that does "steering" of
  traffic to the right resolver.

Note that these mechanisms should generally not tell apps what
policies they should follow when they see these signals.

These seem to be on your list below. I think we should stay away from
anything that is about specifying best current practices because as
far as I can tell all but the most trivial ones (here is how to safely
run a TLS server or something) are contested. For instance, even
retention period has very strong views on both sides.

> Together, these developments may represent
> a set of shifts depending on how the new protocols are deployed: from
> cleartext to encrypted transports; from use of unique port numbers for
> DNS resolution to ports that support significant other traffic (e.g.,
> HTTPS); from network operator control of DNS configuration to control by
> clients, third-party resolvers, or others; and from the use of a large,
> dispersed set of network operator resolvers to a smaller set of more
> centralized resolvers operated by other parties.

The word "may" is doing a lot of work here. In particular, while I
realize that this centralization argument has been repeatedly raised,
it's not really a point of consensus. Consider that in the United
States, the ISP market is dominated by a very small number of players,
with two companies, Charter and Comcast, having the vast majority of
the market
(
https://www.statista.com/statistics/217348/us-broadband-internet-susbcribers-by-cable-provider/
)
Because residential customers generally use the ISP resolver, this
market is already highly centralized. It's true that there are a lot
of much smaller enterprise resolvers, but every major
application-level DNS rollout I have seen proposed attempts to
preserve that situation.

> This potential set of shifts raises many questions given the long history
> and current status of DNS operational practices. Network operators have
> historically used DNS services for a variety of purposes beyond simple
> query resolution: to mitigate network and security threats, to enforce
> enterprise policy, to provide parental controls and other filters, and to
> comply with relevant laws and regulations, among others.

This list of practices would be much more accurate if it included the
resolver-level DNS practices that we are trying to mitigate using DoH,
including NXDOMAIN synthesis and collection of user browsing history
data.

> Achieving these
> objectives while providing confidentiality and tamper-resistance will
> generally require that network operators shift to one of the available
> encrypted transports for their resolvers and that clients include
> configuration options to select them.

This entirely misses the point, which isn't just to do a lot of encryption
but to provide security for the user. Just having network operators
transition to secure transports while continuing their current practices
does not address the issue.

> Specific initial areas of focus include:
>
> - Resolver discovery
> - Expression of resolver policy
> - Query routing in the presence of resolver choice
> - Best Current Practices for the deployment and operation of encrypted
DNS transport

This seems like it leaves all of the contested issues firmly
in scope. I can't imagine how we're going to get consensus on
best current practices, when we can't even agree on the terms
for resolver selection.

-Ekr

On Wed, Oct 9, 2019 at 12:39 AM Barry Leiba <[email-masked]> wrote:

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

---

From: Barry Leiba <[email-masked]>
Date: Wed, 9 Oct 2019 15:31:06 +0200

> Who wrote the charter? Shouldn’t the BoF proponents be 1-3 individuals, rather than a mailing list?

That's a fair question.  The answers are:

- The IESG write the charter proposal as something to float to the community.

- We took longer than we would have liked to get it done, and we
wanted to be sure we had it ready for discussion as soon as possible,
and to be sure we had a reasonable placeholder for BoF approval
(today).  That was sloppy, and I'm sorry for that, but we also did not
have time to get it socialized and to have people signed up as
proponents and possible chairs yet.

So if it helps, consider "the IESG" as the charter proposal writers
and "5 or 6 ADs" as the BoF proponents.

Barry

On Wed, Oct 9, 2019 at 10:55 AM Rob Sayre <[email-masked]> wrote:
> Who wrote the charter? Shouldn’t the BoF proponents be 1-3 individuals, rather than a mailing list?
>
> The proposed charter looks extremely misguided to me. But a proposal that no one will put their name on doesn’t even deserve an argument.
>
> thanks,
> Rob
>
>

---

From: <[email-masked]>
Date: Wed, 9 Oct 2019 13:36:05 +0000

Barry, I second the thanks for the charter, which in general looks to me that it could be a good way forward.

I'll pick up on a couple of Ekr's points:

> I think we should stay away from

In my view BCPs are clearly needed, as a means of resolving the contested areas. If I thought rough concensus was impossible I would agree with Eric, but I'm more optimistic.

> Just having network operators transition to secure transports while
> continuing their current practices does not address the issue.

Please point me to an operator that is arguing for the continuing of NXDOMAIN monetisation. BT is not, nor is Comcast. I don't see why we can't have ABCD work on a declaration that these practises are not permissible except in defined circumstances (e.g. user's express wish, perhaps others). The signalling of policies that you refer to could be part of that statement.

> best current practices, when we can't even agree on the terms

Yes it's hard, and some compromise will be required, but it's worth attempting this in ABCD.

Chris

---

From: Rob Sayre <[email-masked]>
Date: Wed, 9 Oct 2019 20:40:56 +0700

> That's a fair question.  The answers are:

Thank you for the response.

> and "5 or 6 ADs" as the BoF proponents.

It does not help. Could those "5 or 6 ADs" put their names on the proposal?

thanks,
Rob

---

From: Joe Abley <[email-masked]>
Date: Wed, 9 Oct 2019 09:48:44 -0400

Hi Rob,

> It does not help. Could those "5 or 6 ADs" put their names on the proposal?

Can you explain why this is important?

I don't mean to imply it's not; I'm just trying to understand your question.

Joe

---

From: Jari Arkko <[email-masked]>
Date: Wed, 9 Oct 2019 15:50:41 +0200

(I should acknowledge that the privacy and deployment model related text in Barry’s text was proposal from me. But the whole charter text should be considered as a proposal and subject for discussion and modification.)

Back to Ekr’s point: I do think the technical discovery etc parts are very important and should be worked on. But I also think that we have to say something about privacy, pervasive monitoring and centralisation issues. From my perspective if we work on this topic at all, we’d be not doing our duty if we didn’t consider those aspects.

Jari

---

From: Rob Sayre <[email-masked]>
Date: Wed, 9 Oct 2019 20:51:43 +0700

> I don't mean to imply it's not; I'm just trying to understand your

You ask a totally fair question.

I think the charter is misguided and wrote that "a proposal that no one
will put their name on doesn’t even deserve an argument."

So, I just asked (again) whether someone would put their name on it.

thanks,
Rob

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 9 Oct 2019 06:51:30 -0700

On Wed, Oct 9, 2019 at 6:36 AM <[email-masked]> wrote:

> Please point me to an operator that is arguing for the continuing of
> NXDOMAIN monetisation.

Arguing or not, it continues to happen, at least on T-mobile.

-Ekr

---

From: Jim Reid <[email-masked]>
Date: Wed, 9 Oct 2019 14:52:20 +0100

> On 9 Oct 2019, at 14:36, <[email-masked]> <[email-masked]> wrote:
> 

Indeed. And when consensus isn’t achievable, I think it would be helpful to document the reasons why that’s the case. Even if those hypothetical Informational RFCs were little more than a statement of the bleedin’ obvious. For instance “The IETF has no BCP on query data retention because that topic is an intractable tar pit of conflicting/contradictory national regulations, legislation and local policy. Here’s why: ... The WG decided not to go on a quest for an unachievable compromise. Have a nice day.”.

IMO it will sometimes be helpful to document the things the WG doesn’t agree on and why as it is to document the topics where there is a (rough) consensus.

---

From: "Eric Vyncke (evyncke)" <[email-masked]>
Date: Wed, 9 Oct 2019 13:56:00 +0000

Rob

There is no secret obviously: I was one of those 5-6 area directors (with dprive in mind)   ;-)

Hope this helps

-éric

From: Add <[email-masked]> on behalf of Rob Sayre <[email-masked]>
Date: Wednesday, 9 October 2019 at 15:41
To: Barry Leiba <[email-masked]>
Cc: ADD Mailing list <[email-masked]>
Subject: Re: [Add] Proposed charter and BoF request for IETF 106

thanks,
Rob

---

From: Rob Sayre <[email-masked]>
Date: Wed, 9 Oct 2019 20:57:18 +0700

On Wed, Oct 9, 2019 at 8:56 PM Eric Vyncke (evyncke) <[email-masked]>
wrote:

> Rob
>
>
>
> There is no secret obviously:
>

Why not just put your names on the form?

thanks,
Rob

---

From: Barry Leiba <[email-masked]>
Date: Wed, 9 Oct 2019 16:12:55 +0200

> Why not just put your names on the form?

Working on it; we're in the middle of a meeting right now, but I will
fix it after.

Barry

---

From: Ted Lemon <[email-masked]>
Date: Wed, 9 Oct 2019 10:16:59 -0400

If the proposal was half baked due to hurry, maybe the right approach is to wait until March. If you really think it’s urgent, you could do it as a virtual BoF in January.  That’s what the IESG would say to me if I proposed something that was too rushed.  

Are you going easier on yourselves than you would on an outsider?  What is the rush?  Is there some goal that you are pushing to achieve that justifies this rush?

At present, the charter does not even discuss some of the most important use cases for dns services configured by the network operator, particularly the ones that involve surveillance. And we’ve had endless discussions on the exact topic of the proposed BoF here on the ADD mailing list with no evidence of consensus on the topics in the proposed charter. 

With that in mind, why does the IESG consider this a good use of meeting time? We already had this BoF in Montreal. We know there is no consensus on these topics. Can you make brief, crisp elevator pitch on why this is worth the IETF’s time?

> On Oct 9, 2019, at 09:31, Barry Leiba <[email-masked]> wrote:
> 
> 
>>

---

From: Richard Barnes <[email-masked]>
Date: Wed, 9 Oct 2019 10:21:20 -0400

I think EKR is on the right track here.

There is a bright line here between technology and deployment policy.  The
former we have some hope of progressing on, and there are meaty questions
around how applications can discover local network capabilities and
preferences in a way that is not open to abuse like the mechanisms we have
today.  On questions of the latter form, the entire history of this list,
and the meeting that preceded it demonstrate, that there is very little
hope of consensus.

The charter right now has some of both.  If this charter is to go forward,
it should be refactored to focus on engineering questions, and avoid policy
questions.  In particular, the BCP item needs to be struck.

--RLB

---

From: Ted Lemon <[email-masked]>
Date: Wed, 9 Oct 2019 10:21:22 -0400

On Oct 9, 2019, at 9:50 AM, Jari Arkko <[email-masked]> wrote:
> But I also think that we have to say something about privacy, pervasive monitoring and centralisation issues. From my perspective if we work on this topic at all, we’d be not doing our duty if we didn’t consider those aspects.

Who is the “we” here, Jari?   If it’s the IAB, then you don’t need a BoF.  Go write down what you think and share it with us as an IAB statement or IAB RFC.  I think this would be a useful thing to do.   But I don’t think there’s a “we” in the IETF that has a consensus position on this, so even if “we” should say something about this, it’s clear to me that there is no something we can agree on that we could say.

---

From: Rob Sayre <[email-masked]>
Date: Wed, 9 Oct 2019 21:24:16 +0700

On Wed, Oct 9, 2019 at 9:21 PM Richard Barnes <[email-masked]> wrote:

>
>  If this charter is to go forward, it should be refactored to focus on
> engineering questions, and avoid policy questions.  In particular, the BCP
> item needs to be struck.
>

Fully agree.

thanks,
Rob

---

From: Jari Arkko <[email-masked]>
Date: Wed, 9 Oct 2019 16:41:13 +0200

Richard,

I realise that it is easier to ignore the deployment models. And I don’t imagine that we’d have unanimous opinion about deployment models. Certainly the NSAs of the world and few others that have very specific deployments depend on benefits from centralised models :-) But, should that drive IETF opinion on an important change in Internet infrastructure. 

I wouldn’t entirely rule out broader IETF rough consensus on what’s good. We could find out, perhaps.

And I think we should care about pervasive monitoring, in this and other topics.

Jari

---

From: Alissa Cooper <[email-masked]>
Date: Wed, 9 Oct 2019 16:52:33 +0200

Hi Rob,

When the IESG was discussing this, I wrote up the text below. The structure and some of the text made it into the version Barry shared.

—

Application Behavior Considering DNS (ABCD)

DNS over TLS (DoT) [RFC 7858], DNS over DTLS [RFC8094], and DNS over HTTPS (DoH) [RFC 8484] provide confidentiality and tamper-resistance to thwart on-path attacks against DNS queries flowing between clients and recursive resolvers. Along with the deployment of these new transports, various application providers have been exploring having the application configure its own DNS services rather than using DNS services configured by the network operator. (The working group considers a network operator to include Internet service providers, enterprises, and any businesses that provide network access.) Together, these developments may represent a set of shifts depending on how the new protocols are deployed: from cleartext to encrypted transports, from use of unique port numbers for DNS resolution to ports that support significant other traffic (e.g., HTTPS), and from network operator control of DNS configuration to control by clients, third-party resolvers, or others.

This potential set of shifts raises many questions given the long history and current status of DNS operational practices. Network operators have historically used DNS services for a variety of purposes beyond simple query resolution: to mitigate network and security threats, to enforce enterprise policy, to provide parental controls and other filters, and to comply with relevant laws and regulations, among others. To the extent that the presence of encrypted DNS transports or changes in DNS configuration control or both create barriers to achieving the objectives that underlie these practices, this working group is the venue within the IETF to work on engineering and operational solutions. 

This working group is focused on specifying protocols, guidance, and best practices to support the smooth operation of encrypted DNS transports across diverse networks with potentially diverse and changing arrangements concerning where the control of DNS service configuration is located. Specific initial areas of focus include but are not limited to:

- Resolver discovery and selection
- Expression of resolver policy
- Support for split-horizon DNS environments
- Mechanisms to facilitate testing of new configurations

This working group will coordinate with the DNSOP (OPS Area) and DPRIVE (INT Area) working groups, and all last-call announcements (including Working Group Last Calls issued by the chairs) will be copied to all three working groups to ensure thorough and careful review.  The working group will also coordinate with the Security Area, and will be assigned a security advisor.

—

Best,
Alissa

> On Oct 9, 2019, at 3:51 PM, Rob Sayre <[email-masked]> wrote:
> 
> 
> 
> On Wed, Oct 9, 2019 at 8:48 PM Joe Abley <[email-masked] <mailto:[email-masked]>> wrote:
> Hi Rob,
> 
> On 9 Oct 2019, at 09:40, Rob Sayre <[email-masked] <mailto:[email-masked]>> wrote:
> 
> I think the charter is misguided and wrote that "a proposal that no one will put their name on doesn’t even deserve an argument." 
>

---

From: Rob Sayre <[email-masked]>
Date: Wed, 9 Oct 2019 22:03:58 +0700

Hi Alissa,

Thank you for sharing that text. A light edit to your contribution might
say:

"Network operators have historically mis-used DNS for a variety of
purposes..."

The "mis-" prefix was obviously added by me. But should the IETF take those
use cases seriously? I think all the shady traffic is on the "dark web"
now, anyway.

thanks,
Rob

On Wed, Oct 9, 2019 at 9:52 PM Alissa Cooper <[email-masked]> wrote:

> Hi Rob,
>
> When the IESG was discussing this, I wrote up the text below. The
> structure and some of the text made it into the version Barry shared.
>
> —
>
> DNS over TLS (DoT) [RFC 7858], DNS over DTLS [RFC8094], and DNS over HTTPS
> (DoH) [RFC 8484] provide confidentiality and tamper-resistance to thwart
> on-path attacks against DNS queries flowing between clients and recursive
> resolvers. Along with the deployment of these new transports, various
> application providers have been exploring having the application configure
> its own DNS services rather than using DNS services configured by the
> network operator. (The working group considers a network operator to
> include Internet service providers, enterprises, and any businesses that
> provide network access.) Together, these developments may represent a set
> of shifts depending on how the new protocols are deployed: from cleartext
> to encrypted transports, from use of unique port numbers for DNS resolution
> to ports that support significant other traffic (e.g., HTTPS), and from
> network operator control of DNS configuration to control by clients,
> third-party resolvers, or others.
>
> comply with relevant laws and regulations, among others. To the extent that
> the presence of encrypted DNS transports or changes in DNS configuration
> control or both create barriers to achieving the objectives that underlie
> these practices, this working group is the venue within the IETF to work on
> engineering and operational solutions.
>
> This working group is focused on specifying protocols, guidance, and best
> practices to support the smooth operation of encrypted DNS transports
> across diverse networks with potentially diverse and changing arrangements
> concerning where the control of DNS service configuration is located.
> Specific initial areas of focus include but are not limited to:
>
> This working group will coordinate with the DNSOP (OPS Area) and DPRIVE
> (INT Area) working groups, and all last-call announcements (including
> Working Group Last Calls issued by the chairs) will be copied to all three
> working groups to ensure thorough and careful review.  The working group
> will also coordinate with the Security Area, and will be assigned a
> security advisor.
>
> —
>
> Best,
> Alissa
>
>

---

From: Richard Barnes <[email-masked]>
Date: Wed, 9 Oct 2019 11:08:32 -0400

Hi Jari,

Of course I agree that we should care about pervasive monitoring.  But it's
far from clear which of the deployment options is more resilient against
that threat.  The Snowden revelations indicated NSA interference at both
ISPs and cloud providers.

As for ruling out broader IETF rough consensus -- This hopefulness has been
expressed several times in this thread.  As far as I can tell, all the data
are on the other side.

--Richard

On Wed, Oct 9, 2019 at 10:41 AM Jari Arkko <[email-masked]> wrote:

> Richard,
>
> I realise that it is easier to ignore the deployment models. And I don’t
> imagine that we’d have unanimous opinion about deployment models. Certainly
> the NSAs of the world and few others that have very specific deployments
> depend on benefits from centralised models :-) But, should that drive IETF
> opinion on an important change in Internet infrastructure.
>

---

From: "Ralf Weber" <[email-masked]>
Date: Wed, 09 Oct 2019 17:57:18 +0200

Moin!

> Arguing or not, it continues to happen, at least on T-mobile.
I assume you mean T-Mobile US as it is not happening for me at T-Mobile
in Germany.

But that aside Browsers are still monetising sending search results to
a search provider they choose when I enter something in the Omnibox that
most browsers today have. How is that different from ISP monetisation?

Now I don’t like both and wish we would not have these Omniboxes, but
instead an URL and search box with a possibility to choose a search
provider before my search and associated personal identifiable cookie
goes there.

So long
-Ralf

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 9 Oct 2019 09:10:40 -0700

> I assume you mean T-Mobile US as it is not happening for me at T-Mobile

Yes. I do not know what T-mobile does in Germany.

> provider before my search and associated personal identifiable cookie

I'm not quite sure what you're looking for here, but Firefox does allow you
to
select your search provider both globally and on a per-search basis. The
former
is done via Preferences > Search. The latter is done by having a list of
search providers at the bottom of the suggestions offered by the AwesomeBar,
and you can click to send the searches there. Note that you'll need to turn
off Search Suggestions because that's implemented by sending your partial
queries to the selected search provider. This is also done in Preferences >
Search.

-Ekr

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 9 Oct 2019 17:38:12 +0100

Hiya,

On 09/10/2019 14:50, Jari Arkko wrote:
> But I also think that we have to say something about privacy,
> pervasive monitoring and centralisation issues. From my perspective
> if we work on this topic at all, we’d be not doing our duty if we
> didn’t consider those aspects.
+1

While I'd be pleasantly surprised if we could reach
rough consensus on how to "fix" the privacy impacts
of the centralisation that may accompany use of DoH
in browsers, I do think we ought consider this as a
challenge to tackle as best we can. For example, if
we have protocol design choices to make, related to
say discovery, then considering how those enable or
encourage or discourage centralisation should be in
scope questions to ask in the putative WG.

Cheers,
S.

---

From: Vittorio Bertola <[email-masked]>
Date: Wed, 9 Oct 2019 18:47:54 +0200 (CEST)

Il 9 ottobre 2019 16:21 Richard Barnes <[email-masked]> ha scritto:

There is a bright line here between technology and deployment policy.  The former we have some hope of progressing on, and there are meaty questions around how applications can discover local network capabilities and preferences in a way that is not open to abuse like the mechanisms we have today.  On questions of the latter form, the entire history of this list, and the meeting that preceded it demonstrate, that there is very little hope of consensus.

The charter right now has some of both.  If this charter is to go forward, it should be refactored to focus on engineering questions, and avoid policy questions.  In particular, the BCP item needs to be struck.

I see the reasons behind this line of thought, but honestly, seen from my viewpoint, it looks like the IETF is playing hide and seek on the non-technical issues. It starts a deep change in a basic technology for the entire Internet, with at least one AD stating in public things like "we're going to save dissidents and journalists with this new technology", then when the real world problems of that approach come up, the IETF backs away and says "sorry, we only deal with the engineering questions". So yes, you can strike any policy and deployment model discussion from the charter, but then you should also strike RFC 7258 - what is it, if not a policy statement?

(Before someone jumps at my throat, I'll stress that I'm not actually arguing against RFC 7258, I'm just noting that it's too late to claim that the IETF does not do policy, at least in this area.)

This said, I do not have a firm opinion yet on this; I see that having the deployment model in the charter might derail technical developments that could instead get to consensus. So it might still be a wise decision for the IETF to say "we have realized that there are complex policy and juridical issues stemming from this and we are not well equipped to deal with them, so we declare them out of scope".

The unavoidable consequence, however, would be that the policy discussion moves somewhere else, possibly somewhere in the I* galaxy, for the global, non-binding and opinion-making debates, and into national Parliaments for any hard law if required. So the IETF must then be prepared to accept that other parts of the ecosystem might have other views on how the DNS should work and which use cases it should support, and cooperate with their conclusions.

And to be honest, even if the IETF decided to tackle the policy issues and managed to come up with a best practice, it could easily be that other policymaking entities got to different conclusions and asked the engineers to align.

--

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

---

From: Vittorio Bertola <[email-masked]>
Date: Wed, 9 Oct 2019 18:56:31 +0200 (CEST)

Sorry, now it is my turn to dot the i's: certainly *some* network operators in your country adopt *some* current practices that Mozilla do not like, and neither do I. But you cannot generalize this like that, and then use it as a reason not to enable the other network operators to shift to encrypted transport while continuing their practices exactly like they are, for the full satisfaction of their existing users.

And by the way, making judgements on whether the commercial practices of a given company are acceptable really looks like a policy issue.

--

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 9 Oct 2019 10:05:01 -0700

On Wed, Oct 9, 2019 at 9:56 AM Vittorio Bertola <
[email-masked]> wrote:

> Sorry, now it is my turn to dot the i's: certainly *some* network
> operators in your country adopt *some* current practices that Mozilla do
> not like, and neither do I. But you cannot generalize this like that, and
> then use it as a reason not to enable the other network operators to shift
> to encrypted transport while continuing their practices exactly like they
> are, for the full satisfaction of their existing users.
>
> And by the way, making judgements on whether the commercial practices of a
> given company are acceptable really looks like a policy issue.
>

You're misunderstanding me. I'm not saying that we should not enable
network operators to shift to encrypted transport. As I said in the section
of my message that you cut, I'm more than happy to have the IETF
standardize a mechanism for the network to tell endpoints that it supports
encrypted transport. I'm merely observing that this does not address the
issue that Mozilla is trying to address with our DoH/TRR deployment.

-Ekr

---

From: Richard Barnes <[email-masked]>
Date: Wed, 9 Oct 2019 13:14:22 -0400

On Wed, Oct 9, 2019 at 12:47 PM Vittorio Bertola <
[email-masked]> wrote:

> I see the reasons behind this line of thought, but honestly, seen from my
> viewpoint, it looks like the IETF is playing hide and seek on the
> non-technical issues. It starts a deep change in a basic technology for the
> entire Internet, with at least one AD stating in public things like "we're
> going to save dissidents and journalists with this new technology", then
> when the real world problems of that approach come up, the IETF backs away
> and says "sorry, we only deal with the engineering questions". So yes, you
> can strike any policy and deployment model discussion from the charter, but
> then you should also strike RFC 7258 - what is it, if not a policy
> statement?
>

It is indeed a policy statement -- and one around which there was strong
consensus at the time it was published.  (I expect there still is.)  It's
not that I think the IETF can't make policy statements of this character,
it's that there's no indication that there's any policy statement in this
domain around which there is consensus to be had.

--Richard

>
> (Before someone jumps at my throat, I'll stress that I'm not actually
> arguing against RFC 7258, I'm just noting that it's too late to claim that
> the IETF does not do policy, at least in this area.)
>
> This said, I do not have a firm opinion yet on this; I see that having the
> deployment model in the charter might derail technical developments that
> could instead get to consensus. So it might still be a wise decision for
> the IETF to say "we have realized that there are complex policy and
> juridical issues stemming from this and we are not well equipped to deal
> with them, so we declare them out of scope".
>
> The unavoidable consequence, however, would be that the policy discussion
> moves somewhere else, possibly somewhere in the I* galaxy, for the global,
> non-binding and opinion-making debates, and into national Parliaments for
> any hard law if required. So the IETF must then be prepared to accept that
> other parts of the ecosystem might have other views on how the DNS should
> work and which use cases it should support, and cooperate with their
> conclusions.
>
> And to be honest, even if the IETF decided to tackle the policy issues and
> managed to come up with a best practice, it could easily be that other
> policymaking entities got to different conclusions and asked the engineers
> to align.
>
> --
>

---

From: Paul Wouters <[email-masked]>
Date: Wed, 9 Oct 2019 13:15:21 -0400 (EDT)

On Wed, 9 Oct 2019, Eric Rescorla wrote:

> You're misunderstanding me. I'm not saying that we should not enable network operators to shift to encrypted transport.
> As I said in the section of my message that you cut, I'm more than happy to have the IETF standardize a mechanism for
> the network to tell endpoints that it supports encrypted transport. I'm merely observing that this does not address the

And it seems doing this at the DHCP / Captive Portal level is enough. I
don't see the need for a WG to be spun up for this.

Paul

---

From: Paul Wouters <[email-masked]>
Date: Wed, 9 Oct 2019 13:33:41 -0400 (EDT)

> and "5 or 6 ADs" as the BoF proponents.

This is really weird by the way. The IESG proposing a BoF/WG which the
IESG reviews to accept or not. It would be even weirder if the WG chairs
selected will be IESG members or ADs.

Paul

---

From: tirumal reddy <[email-masked]>
Date: Wed, 9 Oct 2019 19:04:15 +0100

On Wed, 9 Oct 2019 at 18:15, Paul Wouters <[email-masked]> wrote:

> network operators to shift to encrypted transport.
> > As I said in the section of my message that you cut, I'm more than happy
> to have the IETF standardize a mechanism for
> > the network to tell endpoints that it supports encrypted transport. I'm
> merely observing that this does not address the

DHCP is not a secure way to discover the local DoT/DoH server.

-Tiru

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 9 Oct 2019 11:32:02 -0700

On Wed, Oct 9, 2019 at 11:04 AM tirumal reddy <[email-masked]> wrote:

>> > As I said in the section of my message that you cut, I'm more than
>> happy to have the IETF standardize a mechanism for

It would probably useful to start by defining what "secure" means in this
context. For instance, I am in an airport and I see the name of the WiFi AP
printed on the wall an join a network with that SSID. How would you define
securely learning the DoH server?

-Ekr

---

From: Richard Barnes <[email-masked]>
Date: Wed, 9 Oct 2019 14:46:29 -0400

On Wed, Oct 9, 2019 at 2:32 PM Eric Rescorla <[email-masked]> wrote:

>>> > the network to tell endpoints that it supports encrypted transport.
>>> I'm merely observing that this does not address the

I would probably be happy with the property that some random other host on
the LAN couldn't feed you bad information.

Not that this has much to do with DoH.  The impact of rogue DHCP servers is
just as catastrophic for Do53.

--Richard

---

From: Vittorio Bertola <[email-masked]>
Date: Wed, 9 Oct 2019 20:55:46 +0200 (CEST)

> Il 9 ottobre 2019 09:38 Barry Leiba <[email-masked]> ha scritto:
> 
> See the proposal here:

I have a clarification question on the last part of the charter, where it gives this objective for a BCP:

"- guidelines for deployment models that minimize issues with pervasive monitoring, commercial use of DNS data, and other privacy concerns"

Assuming that we want to keep the BCP part in the charter, what is the purpose of listing explicitly those three categories of issues and not others? There are several other types of issues that are created by certain choices of deployment model, e.g. on network security, on jurisdiction, on content/access control, on competition, on centralization... Would these not be minimized by the proposed guidelines?

--

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 9 Oct 2019 11:59:54 -0700

> the LAN couldn't feed you bad information.

Yeah, I'm not actually sure how to do that without making some assumptions
about the LAN structure and (in the case of wireless, what kind of crypto
was in place).

> Not that this has much to do with DoH.  The impact of rogue DHCP servers
> is just as catastrophic for Do53.
>

Well, perhaps less, because the Do53 security properties are already so
terrible :)

-Ekr

---

From: Jim Reid <[email-masked]>
Date: Wed, 9 Oct 2019 20:16:08 +0100

> On 9 Oct 2019, at 19:04, tirumal reddy <[email-masked]> wrote:
> 

That may well be true. However that debate belongs on another thread and maybe even another list.

I thought we were meant to be discussing the proposed charter for a new WG and a possible BoF in Singapore. Could we please focus on that?

Debating the detail of DHCP/discovery methods seems to be off-topic for the matter at hand. Though these could well be the basis of new work if and when the ABCD is formed.

---

From: Paul Wouters <[email-masked]>
Date: Wed, 9 Oct 2019 16:24:20 -0400 (EDT)

> I thought we were meant to be discussing the proposed charter for a new WG and a possible BoF in Singapore. Could we please focus on that?

It is relevant, because if we believe the only thing that is needed is
a DHCP option, then we do not need to spin up a working group. In fact,
I would expect whoever wants to spin up a new group to have done some
preliminary work in this area so that it is clear there is a real large
enough problem to be solved using a WG. I don't get the feeling this
happened. What I see is people looking for a business model for "secure
DNS" services. I don't think that business model needs protocol level
support from the IETF (because as I stated earlier, consumer trust
doesn't work by signed XML statements).

Compare this with starting up a WG to eavesdrop on TLS 1.3 traffic.
Look at how PATIENT hasn't seen any discussion since July 2018. We
didn't start a WG for that either. Why should we do one on eavedropping
encrypted DNS?

As for the "DHCP is not secure" argument. There is absolutely no
expectation of validatable security when someone joins a random
network. When I join a known preconfigured enterprise network, I already
have trust anchors. When I decide to trust a personal DoH server that is
not local, I already have the trust anchors I need as well. An insecure
DHCP option is useful for the enterprise/parental use case, where just
being on the network is a veriably secure action already.

Paul

---

From: "Eric Vyncke (evyncke)" <[email-masked]>
Date: Wed, 9 Oct 2019 20:56:39 +0000

And BTW do not forget that in IPv6 the prominence of DHCP is close to 0 ;-)

-éric

On 09/10/2019, 22:24, "Add on behalf of Paul Wouters" <[email-masked] on behalf of [email-masked]> wrote:

    

    
    Paul

---

From: Jim Reid <[email-masked]>
Date: Wed, 9 Oct 2019 22:35:10 +0100

> On 9 Oct 2019, at 21:24, Paul Wouters <[email-masked]> wrote:
> 
> Why should we do one on eavedropping encrypted DNS?

What part of the proposed charter implies that’s what this new WG would do?

---

From: Jim Reid <[email-masked]>
Date: Wed, 9 Oct 2019 22:46:58 +0100

> a DHCP option, then we do not need to spin up a working group.

Well the draft charter says:

Only the first item on that list looks is if it could somehow touch on DHCP. And even then it might only have an impact on DHCP if the current discovery draft in the doh WG fails to deliver. So no, a DHCP option is not the only thing that’s needed IMO.

I would also hope we can agree to take an objective, evidence-based approach rather than one which is based on subjective matters of belief.

---

From: Ted Lemon <[email-masked]>
Date: Wed, 9 Oct 2019 18:41:22 -0400

Isn’t there already a DHCPv6 option for split horizon DNS?  ISTR being dragooned as a co-author on that one. 

> On Oct 9, 2019, at 17:47, Jim Reid <[email-masked]> wrote:
> 
> 
>

---

From: Suzanne Woolf <[email-masked]>
Date: Wed, 9 Oct 2019 20:31:11 -0400

> On Oct 9, 2019, at 10:21 AM, Richard Barnes <[email-masked]> wrote:
> 

I’d be more comfortable if the proposed charter said this, and further if it distinguished between standards-track development of new protocol, extension or fine-tuning of existing protocol, and advice on configuration and deployment.

In DNSOP, and discussion of DNS-based items in other WGs, there’s a distinction between DNS protocol (e.g. defining resolver behavior or, in this case, perhaps resolver discovery), fully backward-compatible and optional extensions and fine-tuning like new EDNS options and RRtypes, and implementation, configuration, or operational advice. 

If we’re talking about protocol to be implemented in software, or operational capability to be configured, for basic deployment— such as standardized resolver discovery, or an EDNS option for interrogating a DOH server for its policy on specific aspects of query handling— it’s possible to come up with  a concise problem description and protocol to solve it. This kind of problem seems like a good candidate for consensus.

Operations-oriented documents can be tricky, but DNSOP has done a number of RFCs where the purpose is to document certain behavior that’s been invented and deployed entirely outside of the standards process. Those documents can be controversial, because if the behavior is seen as harmful by a significant subset of the community, there can be deep divisions in the WG about whether documenting it promotes the harmful behavior, whether the WG should propose improvements to the attributes seen as harmful, and what operators will do with the result— that is, whether the “improved” protocol will be implemented or deployed. But there’s been consensus from time to time that documenting the choices actually available in the field— including how to opt-out or avoid behavior seen as harmful— is an improvement even if the perceived harm can’t be eliminated.

I do share the reservations about a BCP, because a BCP proposes not only documenting the choices, but making claims about “rightness”. Describing tradeoffs between these protocols, the available configuration choices, and how they impact specific aspects of user security seems as if it should be doable, but consensus would be exceptionally difficult around what’s “best”.

> The charter right now has some of both.  If this charter is to go forward, it should be refactored to focus on engineering questions, and avoid policy questions.  In particular, the BCP item needs…

I think it’s important to be realistic here about what can be accomplished by a group and a process primarily geared towards producing quality technical standards. There are a lot of smart people here and a lot of interesting perspectives on what good policy looks like, but the IETF process may not be the best way to reach consensus on a shared view. We can agree on, for example, a description of how, quantitatively, DNS traffic changes when the resolver is moved from the carrier gateway to 8.8.8.8— but whether the user “should” trust one party more than another is less likely to be agreed on any time soon.

Suzanne

> 
> On Wed, Oct 9, 2019 at 9:50 AM Eric Rescorla <[email-masked] <mailto:[email-masked]>> wrote:
> 
> Barry,
> 
> (https://www.statista.com/statistics/217348/us-broadband-internet-susbcribers-by-cable-provider/ <https://www.statista.com/statistics/217348/us-broadband-internet-susbcribers-by-cable-provider/>)
> > - Best Current Practices for the deployment and operation of encrypted DNS transport
> 
> On Wed, Oct 9, 2019 at 12:39 AM Barry Leiba <[email-masked] <mailto:[email-masked]>> wrote:
> Hi, all,
> 
>       https://trac.tools.ietf.org/bof/trac/wiki/WikiStart <https://trac.tools.ietf.org/bof/trac/wiki/WikiStart>
> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/add <https://www.ietf.org/mailman/listinfo/add>
> -- 
> Add mailing list
> [email-masked]

---

From: "Ralf Weber" <[email-masked]>
Date: Thu, 10 Oct 2019 06:59:53 +0200

Moin!

> queries to the selected search provider. This is also done in 
And that exactly is the problem. You have to know that and set that. All 
ISPs
NXDomain redirection I’ve encountered so far had an opt out 
functionality,
which is exactly what you described here for Firefox.

However a fresh install of Firefox is sending searches to Google 
directly. So
if I mistype something in the browser bar it is sending this to Google 
for
search. It does this without asking me if I would like to send data to 
Google
or giving me a selection first.

So long
-Ralf
—--
Ralf Weber

---

From: S Moonesamy <[email-masked]>
Date: Wed, 09 Oct 2019 20:46:25 -0700

Hi Barry,
>expect to approve a working-group-forming BoF for Singapore.

The topic looks like it is about (re)defining how DNS works.  The 
draft charter is quite broad.  I could not figure out what would be 
in scope and what would be out of scope.  That could be clarified as 
part of WG chartering.

My reading of the DPRIVE WG charter is that the WG was chartered to 
address concerns surrounding RFC 7258.  That is also a specific area 
of focus of this BOF proposal.  I suggest clarifying that (please see 
my previous comment about scope).

The area of focus mentions DNS transport including recommendations on 
detail protocol usage.  Does that mean the the group will make 
recommendations about when to use DNS over TLS and when to use DNS over TLS?

Regards,
S. Moonesamy

---

From: "Martin Thomson" <[email-masked]>
Date: Thu, 10 Oct 2019 17:20:28 +1100

Hi Barry,

I think that I agree with others about trying to find a narrower and more concrete scope.

The IAB have been discussing workshops on the general subject area and it initially struck me that this is a pretty credible workshop description.  There are a few pieces that seem to explicitly invite the sorts of discussions of policy we've seen on this thread in the past 23 hours.

Alissa's version is a lot closer to the mark, though it shares some of the woolly framing and scope issues.  If we were to BoF that, I suspect we wouldn't even be able to resolve the P3P piece adequately.

Just as a disclaimer, I have been on vacation and there are 36 unread threads in my IAB folder, so I'm probably behind the times a little.

Cheers,
Martin

---

From: Rob Sayre <[email-masked]>
Date: Thu, 10 Oct 2019 13:33:23 +0700

Hi,

I see that the description has been updated. It looks like the proponents
are 4 ADs (rather than "5-6"), and one long-time IETF member who has been
on the IESG in the past.

Is that correct?

thanks,
Rob

---

From: Alissa Cooper <[email-masked]>
Date: Thu, 10 Oct 2019 09:17:41 +0200

Hi Jim,

> On Oct 9, 2019, at 11:46 PM, Jim Reid <[email-masked]> wrote:
> 
> 
> 

This was actually in some draft text I originally generated that led to the version Barry eventually shared with the list, but this text itself doesn’t exist in the version that appears at <https://trac.tools.ietf.org/bof/trac/wiki>. 

Alissa

---

From: Michael Richardson <[email-masked]>
Date: Thu, 10 Oct 2019 13:42:51 +0200

Barry Leiba <[email-masked]> wrote:
    > we're tentatively calling "ABCD", for "Application Behavior Considering
    > DNS".  We can discuss the charter proposal here, and expect to approve
    > a working-group-forming BoF for Singapore.

    > I realize that the charter proposal isn't going to please everyone (and
    > perhaps will please no one), but it's something that, at a first level
    > of review, the IESG accepts and will likely want to move forward with.

Let me reply here before having read the thread.

My impression is that ABCD will act as an architecture group for the problem
with DNSOP (OPS Area), DPRIVE (INT Area), and DOH (ART area) providing
specific technologies.

It seems that many of the discovery/configuration protocols which are
appearing in DPRIVE from Tiru/Dan/me, and Tommy and Thomas would fit into
ABCD rather than DPRIVE.

Please confirm that this is your intention?

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

---

From: Michael Richardson <[email-masked]>
Date: Thu, 10 Oct 2019 13:44:26 +0200

> One meta-question: would ABCD be in the art area? I think ops might be

+1.

Please also consider that we need strong connections to Enterprise operators,
or we fail.

---

From: Michael Richardson <[email-masked]>
Date: Thu, 10 Oct 2019 13:47:05 +0200

Ted Lemon <[email-masked]> wrote:
    > If the proposal was half baked due to hurry, maybe the right approach
    > is to wait until March. If you really think it’s urgent, you could do
    > it as a virtual BoF in January.  That’s what the IESG would say to me
    > if I proposed something that was too rushed.

I think that we need to have the WG-forming BOF at 106, so that in March (which
will be better attended) we can actually hit the ground running with a WG.

Most of the WG charter arguments are going to happen on the list.

---

From: Barry Leiba <[email-masked]>
Date: Thu, 10 Oct 2019 13:47:04 +0200

The intention is to put work items into an appropriate working group,
also considering the other work the relevant working groups are doing.
That means that we'd have to look at where this (ABCD) charter ends
up, whether we do or don't decide to recharter DPRIVE to tweak
anything (we don't currently plan to, but it might turn out to be
helpful), and how much workload there is here and there.

So, yes, it's possible that things that might look like they fit into
DPRIVE now would be better done in ABCD.  We'll have to make that
decision after we see the final charter.

Barry

---

From: Barry Leiba <[email-masked]>
Date: Thu, 10 Oct 2019 14:08:29 +0200

Further following up on the more general thing (a BoF and charter proposal):

I'll stress that what's out there in the BoF wiki is a proposed
starting point -- it represents the IESG's trying to be helpful in
getting concrete charter discussion started.  It's not a finished
charter that's being lobbed at the community, and we *want* you to
discuss it and refine it, to throw parts of it away and add other
things that you need.  Please *do* start that discussion -- we'll
discuss it at the BoF, but we should wait until the BoF to work on it.
Have at it.

For that matter, even having a BoF in Singapore isn't set in stone: if
you, the community, think we've erred in assuming that a BoF now is
the best approach, and we get rough consensus on that, we can easily
cancel the BoF between now and then.

This really *is* out to the community for discussion and consensus.
Let's figure out, together, what the best way is to make progress on
useful documentation here.

Barry

---

From: Jim Reid <[email-masked]>
Date: Thu, 10 Oct 2019 15:26:25 +0100

> On 10 Oct 2019, at 08:17, Alissa Cooper <[email-masked]> wrote:
> 
> This was actually in some draft text I originally generated that led to the version Barry eventually shared with the list, but this text itself doesn’t exist in the version that appears at <https://trac.tools.ietf.org/bof/trac/wiki>

Whoops! My mistake Alissa - thanks.

---

From: Jim Reid <[email-masked]>
Date: Thu, 10 Oct 2019 15:29:21 +0100

> On 9 Oct 2019, at 23:41, Ted Lemon <[email-masked]> wrote:
> 
> Isn’t there already a DHCPv6 option for split horizon DNS?

I wasn’t aware of that Ted - thanks.

Even so, that option doesn’t detract from the point I was trying to make: all the stuff in the proposed charter can’t realistically be accommodated in a DHCP option (or more than one option).

---

From: Rob Sayre <[email-masked]>
Date: Thu, 10 Oct 2019 21:48:01 +0700

> cancel the BoF between now and then.

These two drafts seem well-intentioned:

https://tools.ietf.org/html/draft-pauly-dprive-adaptive-dns-privacy-00
https://tools.ietf.org/html/draft-pauly-dprive-oblivious-doh-00

Why not just handle them in the DPRIVE WG?

I don't think a 200-person BoF in Singapore will get a better result.

thanks,
Rob

---

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

> Why not just handle them in the DPRIVE WG?

There are several other drafts:

https://tools.ietf.org/html/draft-ietf-dnsop-resolver-information-00
https://tools.ietf.org/html/draft-reddy-dprive-bootstrap-dns-server-05
https://tools.ietf.org/html/draft-peterson-dot-dhcp-01
https://tools.ietf.org/html/draft-reddy-dprive-dprive-privacy-policy-00

-Tiru

---

From: Rob Sayre <[email-masked]>
Date: Thu, 10 Oct 2019 22:18:05 +0700

> There are several other drafts:

Hi Tiru,

Thank you for mentioning those documents. One of them already seems to be a
DNSOP WG production.

Are you implying a BoF in Singapore would be productive for the other three
documents? Two of them seem to be targeted at DPRIVE.

thanks,
Rob

---

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

On Thu, 10 Oct 2019 at 16:18, Rob Sayre <[email-masked]> wrote:

> Thank you for mentioning those documents. One of them already seems to be
> a DNSOP WG production.
>

Yes, but draft-ietf-dnsop-resolver-information-00 only discusses publishing
the resolver information but does not discuss the resolver policy.

>
> Are you implying a BoF in Singapore would be productive for the other
> three documents?
>

Yes for a BoF to discuss the above documents including the ones from Apple.

> Two of them seem to be targeted at DPRIVE.
>

All the above drafts target both DoT and DoH excluding
draft-peterson-dot-dhcp-00. I missed including
https://tools.ietf.org/html/draft-peterson-doh-dhcp-00.

Cheers,
-Tiru

---

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

On Wed, 9 Oct 2019 at 19:32, Eric Rescorla <[email-masked]> wrote:

> context.

"secure" means only the operator of the network should be able to advertise
the  DoT/DoH server. If DHCP is used, attacker can spoof the DHCP response.

> For instance, I am in an airport and I see the name of the WiFi AP printed
> on the wall an join a network with that SSID. How would you define securely
> learning the DoH server?
>

The user cannot know the SSID is hosted by the airport IT admin or by an
attacker in the first place. I don't think the charter of the WG is
targeted only for public WiFi, local resolver discovery is critical in
Home, Mobile and Enterprise networks to meet some of the issues raised in
https://tools.ietf.org/html/draft-reid-doh-operator-00.

-Tiru

---

From: Ted Lemon <[email-masked]>
Date: Thu, 10 Oct 2019 11:52:30 -0400

> Yes for a BoF to discuss the above documents including the ones from Apple. 

Why is this better than discussing them in dprive?  Talking about documents that already have homes seems like a poor justification for having a BoF: sufficiently poor that if that is the stated goal of the BoF, there is a tendency to wonder what the unstated goal might be.   I don’t mean to suggest shenanigans—what I mean is that there is some ur-idea behind this BoF that perhaps hasn’t even been clearly expressed among the proponents, and that would be useful to surface.

When I look at the proposed charter, I don’t really see it talking about stuff that we can reach consensus on.   I think there are some interesting questions being asked here, but I don’t think there’s any kind of consensus on the answers.

As Martin said, I think it could be useful to have an IAB workshop on this to explore those topics, and maybe see if there are schools of thought on the various issues mentioned here.   I suspect there are.   If these could be captured in a non-consensus document that simply explains what the various beliefs are clearly and with sufficient background that they can be reasoned about, that could be a substantial improvement over the discussion we’ve been having here.

But I don’t see that happening in a 200-person BoF.   And the idea that we would charter a working group without having done that, with a charter to act on the stated work items, just seems like another chaff-generating activity.   I certainly agree that there are issues to discuss here; I just don’t believe that a working group chartered to reach consensus on these topics is a good approach at the present moment.

---

From: "Livingood, Jason" <[email-masked]>
Date: Wed, 16 Oct 2019 18:29:12 +0000

A few inline replies.

> From: Add <[email-masked]> on behalf of Eric Rescorla <[email-masked]>

[JL] Fair point that there may be some issues agreeing on BCPs. On the other hand, as an operator, some convergence on and recommended best practices may be quite helpful. So I would prefer to keep this in, and not shy away from debate on this because I suspect we may eventually find rough consensus in some areas and those could be put in a BCP (while the others where agreement is lacking would not).

[JL] No reason why NXDOMAIN and other stuff should not be in scope, whether as part of expression of resolver policy or otherwise.  A lot of this is opaque today. As well, practices are more in flux now that perhaps in the last 10 years, so I think work here would be interesting.

---

From: "Livingood, Jason" <[email-masked]>
Date: Wed, 16 Oct 2019 18:34:42 +0000

> Arguing or not, it continues to happen, at least on T-mobile.

[JL] Perhaps an interesting question will be whether such operators will still be doing NXDOMAIN redirection in 1 year or 5 years. I think the CCPA (California Consumer Privacy Act) and subsequent/potential US state and national rules could influence such practices. As well, the whole discussion and deployment of DoH is an external environmental influence as well. So my impression is that the situation with respect to these practices is likely to be less certain than in recent years, and the general trend seems to be away from such practices.

---

From: "Livingood, Jason" <[email-masked]>
Date: Wed, 16 Oct 2019 18:42:30 +0000

> From: Add <[email-masked]> on behalf of Richard Barnes <[email-masked]>
> If this charter is to go forward, it should be refactored to focus on engineering questions, and avoid policy questions.

[JL] Perhaps one issue is what we each mean when the word 'policy' arises. Clearly we're unlikely to get consensus on what is the 'correct' policy across a variety of countries and societies. On the other hand we may well be able to agree on a way to define/differentiate, document/signal, and test such policies. For example, NXDOMAIN redirection (which I do not support) - the WG may not agree on whether this is good or bad. But the WG may well agree on how to define it, how an operator may signal that such a policy config is in place, how this might be tested/validated, etc. Based on those policies, operating systems, apps or users can then determine how to act on that information, etc. (Or maybe I am just being optimistic.)

---

From: Ted Lemon <[email-masked]>
Date: Wed, 16 Oct 2019 14:47:49 -0400

On Oct 16, 2019, at 2:42 PM, Livingood, Jason <[email-masked]> wrote:
> 
> But the WG may well agree on how to define it, how an operator may signal that such a policy config is in place, how this might be tested/validated, etc. Based on those policies, operating systems, apps or users can then determine how to act on that information, etc. (Or maybe I am just being optimistic.)

This sounds analogous to “do not track.”  Is there something about this that would lead to a different outcome?  If I know I am not acting as the user would prefer, would I not just say nothing?