DNS Over HTTPS
charter-ietf-doh-01

[Ballot comment]

In my first ballot, I mentioned "What I've been failing to understand from the charter is the rational for DNS over HTTPS? Can you expand on this." Because I'm not an Web browser and DNS expert, or most likely because the concerns were not clear in my head, I could not clearly express my thoughts.

So I watched the IETF mailing list with attention.
Mark Nottingham's email summarized the situation

    It's not a matter of constraining the work; the work isn't proposing to operate even remotely in the way that you describe. I think we're just having a misunderstanding, because people have multiple use cases in mind for this protocol, and properties thereof have been mixed up.

    AIUI those use cases are, roughly:

    1. Configure your browser/OS to use a DOH service for DNS resolution (as above) -- this will affect browser/OS state, because it's being used for DNS; however, it's not being done from JS.

    2. Call a DOH service from Javascript (for some reason) -- note this is just like any other HTTP request; it doesn't affect browser/OS state outside of the same origin model. Yes, you can still build a browser-in-a-browser and mess with things inside that context, but that's already true today.

    3. Future handwavy things like making DNS updates over HTTP -- very ill-defined and not important for this discussion

Expressing #1 and #2 in the charter would have helped me. #2 is kind of present now.
What about the addition the notion of "browser and/or OS" in the next sentence?

The primary focus of this working group is to develop a mechanism that
provides confidentiality and connectivity between DNS Clients and Iterative
Resolvers.

[Ballot comment]
I think this new text about JS is going in the right direction, but perhaps it straddles the line too much.

Say that -- contra the text here -- we discovered some respect in which it was more convenient to design the protocol in a way that made JS break. Would the charter require us not to do that? I think the answer is "no", but I just want to verify that.

[Ballot comment]
I'm balloting "yes", but I have a point of confusion on the following text:

"The primary focus of this working group is to develop a mechanism that
provides confidentiality and connectivity between DNS Clients and Iterative
Resolvers.  While access to DNS-over-HTTPS servers from JavaScript running in
a typical web browser is not the primary use case for this work, precluding
the ability to do so would require additional preventative design. The working
group will not engage in such preventative design."

I remember someone (Terry, maybe?) stating earlier that the justification for keeping this separate from DPRIVE was that confidentiality was _not_ the primary use case, and connection from JS in browsers _was_.  I see where people decided otherwise in the (95 entries so far) discussion thread--but does that change the relationship with DPRIVE? Especially since the first sentence comes directly from the DPRIVE charter?

[Ballot comment]
(I would be a Yes, but I don't want to be the first one)

Thanks to everyone for the spirited review to date. I think the changes are headed the right direction. I trust that will continue.

I have one nit. In this text,

"The specification of how to discover DOH servers via mechanisms currently used
to discover other DNS servers (e.g., DHCP and Router Advertisements) may be
considered by the working group if the chairs determine that a sufficiently
large mass of working group participants exist who are willing to edit and
comment on documents regarding such mechanisms."

is "large" the best word to describe what you're expecting the chairs to be assessing?

:-)

[Ballot comment]
(I would be a Yes, but I don't want to be the first one)

Thanks to everyone for the spirited review to date. I think the changes are headed the right direction. I trust that will continue.

I have one nit. In this text,

"
The specification of how to discover DOH servers via mechanisms currently used
to discover other DNS servers (e.g., DHCP and Router Advertisements) may be
considered by the working group if the chairs determine that a sufficiently
large mass of working group participants exist who are willing to edit and
comment on documents regarding such mechanisms."

is "large" the best word to describe what you're expecting the chairs to be assessing?

:-)

[Ballot comment]
I do not object to the work -- but I personally think that one of the main benefits is the potential for censorship resistant DNS. I realize that listing all the justifications for doing something isn't really the job of the charter, but I was a bit surprised to not see it mentioned more prominently.

I also think that strong consultation with DNSOP will be very important - DNS has much hidden subtlety and it is easy to trip over the edges if you are not careful.

[Ballot comment]
What I've been failing to understand from the charter is the rational for DNS over HTTPS? Can you expand on this.
My first reaction was: is it because HTTP(S) became the new transport? But obviously not.
So instead of fixing a DNS issue with UDP/TCP/DTLS, we're going to offer yet another choice (with, I guess, a different source of truth?)
Do we need to mention the connection with DNSSEC?
Why not DPRIV?

[Ballot comment]
Just a couple of nits:

(1) s/data may used/data may be used

(2) Given that the milestones reflect the intended date for completion, I don't think it is necessary to also include the date in the charter text.

[Ballot block]
I would very much like to see explicit text in the charter that reinforces the need for cross area review to INT area for DNS semantics and also to OPS (not speaking for the OPS ADs) for operational impacts of DNS over HTTPS on the aspects where normal/expected host (stub resolver->recursive resolver) behaviours are altered through browser HTTPS over DNS resolution.

[Ballot block]
I would very much like to see explicit text in the charter that reinforces the need for cross area review to INT area for DNS semantics and also to OPS (not speaking for the OPS ADs) for operational impacts of DNS over HTTPS on the aspects where normal/expeted host (stub resolver->recursive resolver) behaviours are altered through browser HTTPS over DNS resolution.

Changed charter milestone "Submit specification for performing DNS queries over HTTPS to the IESG for publication as PS", set due date to April 2018 from December 2017

[Ballot comment]
I agree with Eric's BLOCK, that this charter should be really clear about HTTPS expectations.  If I was chairing this working group, I'd want to know whether specifying HTTP was in scope, up front.

I'm pretty sure I know what the answer is going to be, but I'll let people who understand more about DNS usage have that conversation before I express an opinion.

[Ballot block]
This charter seems oddly agnostic on whether or not we are defining
use over HTTP or over HTTPS. In 2017, I think its imperative that this
only be chartered for secure transports (which is, after all, implicit
in the value proposition).  I agree with Martin Thomson that "HTTPS"
is the right way to convey this point.

[Ballot comment]

I think I agree with MT's point that it would be best if this binding
were agnostic about HTTP/2 over TLS versus HTTPS over QUIC (or
whatever we call it) and to the extent possible, agnostic about HTTP/2
versus HTTP/1.1 (i.e., the binding should be indifferent for the
functionality that don't depend on explicit HTTP/2 features like
push). However, I think we could send the charter out for review
w/o deciding that.

[Ballot comment]
Note: this charter has received review from the ART community on the DISPATCH mailing list. Comments ranged from neutral to supportive. See https://mailarchive.ietf.org/arch/search/?email_list=dispatch&gbt=1&index=XJRkCb3Yeu6_Asa5a3sFfrsvgac for details.