Subject: Re: [Doh] WG Review: DNS Over HTTPS (doh)

From: Ted Hardie <[email-masked]>
Date: Fri, 15 Sep 2017 09:44:58 -0700

Howdy,

There are a couple of points that I'd like to raise here.

On Fri, Sep 15, 2017 at 8:44 AM, The IESG <[email-masked]> wrote:

> A new IETF WG has been proposed in the Applications and Real-Time Area. The
> IESG has not made any determination yet. The following draft charter was
> submitted, and is provided for informational purposes only. Please send
> your
> comments to the IESG mailing list ([email-masked]) by 2017-09-25.
>
> DNS Over HTTPS (doh)
> -----------------------------------------------------------------------
> Current status: Proposed WG
>
> Chairs:
>   TBD
>
> Assigned Area Director:
>   Adam Roach <[email-masked]>
>
> Applications and Real-Time Area Directors:
>   Adam Roach <[email-masked]>
>   Ben Campbell <[email-masked]>
>   Alexey Melnikov <[email-masked]>
>
> Mailing list:
>   Address: [email-masked]
>   To subscribe: https://www.ietf.org/mailman/listinfo/doh
>   Archive: https://mailarchive.ietf.org/arch/browse/doh/
>
> Group page: https://datatracker.ietf.org/group/doh/
>
> Charter: https://datatracker.ietf.org/doc/charter-ietf-doh/
>
> This working group will standardize encodings for DNS queries and responses
> that are suitable for use in HTTPS. This will enable the domain name system
> to function over certain paths where existing DNS methods (UDP, TLS, and
> DTLS)
> experience problems.  The working group will re-use HTTPS methods, error
> codes, and other semantics to the greatest extent possible.  The use of
> HTTPS
> provides integrity and confidentiality, and it also allows the transport to
> interoperate with common HTTPS infrastructure and policy.
>
>
I appreciate the charter's use of "HTTPS" as a signal that these are
intended to be TLS-protected HTTP sessions.  I note, however, that there is
considerable ambiguity still present.  HTTPS can mean HTTP 1.1 over TLS,
HTTP/2 over TLS, and it may mean HTTP over QUIC at some point soon (in some
deployments it already means that).  The document named as input specifies
HTTP/2  over TLS.  While the working group may, of course, change that to
support HTTP 1.1 and/or QUIC, it might be useful for the charter to
indicate which of these is potentially in scope.  If the community is sure
now that HTTP over QUIC is in scope, for example, having that noted in the
charter by adding the QUIC working group to list of working groups to
consult would be useful.

I will confess a bias here: while I think it is useful to match the
capability set of HTTP over QUIC to that of HTTP over other transports as
much as possible, I think making that a key part of this work is not a good
initial direction.  For one thing, there are some aspects of the QUIC
transport that are still in discussion, and I think it will slow this work
a bit to track those.  More importantly, though, I think this would be the
wrong way to do DNS over QUIC (draft-huitema-quic-dnsoquic-00 shows a
different approach).  Having QUIC be an early focus here may solidify an
approach that is simple, but not nearly as complete as we could deliver
with a DNS over QUIC.

(This is in part because of the choice to use the udp wireformat as the
baseline HTTP response here, rather than specifying DNS responses over a
transport construct like a QUIC stream.  The working group could, of
course, change that, but it would seriously shift the direction of its
input document to do so).

The working group will coordinate with the DNSOP and INTAREA working groups
> for input on DNS-over-HTTPS's impact on DNS operations and DNS semantics,
> respectvely. In particular, DNSOP will be consulted for guidance on the
> operational impacts that result from traditional host behaviors (i.e.,
> stub-resolver to recursive-resolver interaction) being replaced with the
> specified mechanism.
>
> Specification of how the DNS data may be used for new use cases, and
> the discovery of the DOH servers, are out of scope for the working group.
>
>
While it is useful to know that discovery is out of scope here, I think
having a quick community discussion now of where it might be in scope is
useful.  There are some potentially interesting questions buried in that,
especially in how we expect interworking with existing systems to go.
Note that even if the service discovery method provides an HTTPS URI for
the name server, the questions above related to HTTP version or transport
may bite you.  For server discovery based on address and port, the
situation is much the same unless the port is clearly marked as TCP or
UDP.  And if the server discovery includes no port at all, then a happy
eyeballs type method may be needed.

This may all fall into a combo of DHCP and DNSOP work, but giving somewhat
clean lines for it now seems like it will make the later work go faster.

> The working group will use draft-hoffman-dispatch-dns-over-https as input.
>
> Milestones:
>
>   Apr 2018 - Submit specification for performing DNS queries over HTTPS to
>   the IESG for publication as PS
>
>
I admire the optimism in this.

regards,

Ted Hardie

---

From: The IESG <[email-masked]>
Date: Fri, 15 Sep 2017 08:44:53 -0700

A new IETF WG has been proposed in the Applications and Real-Time Area. The
IESG has not made any determination yet. The following draft charter was
submitted, and is provided for informational purposes only. Please send your
comments to the IESG mailing list ([email-masked]) by 2017-09-25.

DNS Over HTTPS (doh)

Chairs:
  TBD

Assigned Area Director:

Mailing list:
  Address: [email-masked]

This working group will standardize encodings for DNS queries and responses
that are suitable for use in HTTPS. This will enable the domain name system
to function over certain paths where existing DNS methods (UDP, TLS, and DTLS)
experience problems.  The working group will re-use HTTPS methods, error
codes, and other semantics to the greatest extent possible.  The use of HTTPS
provides integrity and confidentiality, and it also allows the transport to
interoperate with common HTTPS infrastructure and policy.

Milestones:

---

From: Eliot Lear <[email-masked]>
Date: Fri, 15 Sep 2017 19:24:34 +0200

Hi,

I have no objection to a WG forming, but I have some concerns about the
charter.

On 9/15/17 5:44 PM, The IESG wrote:
> experience problems.

There is a fundamental question that is left open in the charter: is the
HTTPS server intended to be a substitute for a resolver, or is intended
to provide name service for domains related to the authority section of
the URL used to connect to the current service?  There is some hint
along the lines of the latter in the draft, and I see nothing wrong with
that use, and could see quite a bit of benefit, because the browser
would be following the express intent of the origin.

On the other hand, if this is intended to be used as a full scale
replacement of a resolver, the placement of that resolver and more
precisely locality would become a big operational issue for all sorts of
reasons, such as anti-malware protection, split dns behavior, split
personalities across applications that might impact non-participating
web services, and more.  And yet..
> respectvely. In particular, DNSOP will be consulted for guidance on the
[nit - s/respectvely/respectively/]
> the discovery of the DOH servers, are out of scope for the working group.

The last sentence seems to put the cart before the horse.  How about
letting the working group decide in consultation with dnsop and intarea
whether or not to handle discovery?  The fact is, you are not leaving
discovery out of scope.  You are making a decision that discovery will
take place either in a proprietary way, on an ad hoc basis, or via
manual configuration, but you are ruling out a standard discovery mechanism.

Eliot

---

From: "Paul Hoffman" <[email-masked]>
Date: Fri, 15 Sep 2017 11:24:01 -0700

On 15 Sep 2017, at 9:44, Ted Hardie wrote:

=>> This working group will standardize encodings for DNS queries and 
responses
> indicate which of these is potentially in scope.

Yes, please. The charter should say "HTTP/2 over TLS". There is no 
reason for current browsers adding this feature to add it using an 
obsolete protocol. If someone wants to create a diff from the eventual 
protocol for HTTP 1.1, they can do that without forcing the document to 
add a comparison of the two transports to what is supposed to be a 
short, concise document.

> If the community is sure

The deadline for this WG is well ahead of when HTTP-over-QUIC will be 
finalized. Instead, when HTTP-over-QUIC is finalized, an update to this 
document should be pretty easy to produce.

> input document to do so).

Fully agree.

> clean lines for it now seems like it will make the later work go 

If you want to propose a new WG for that, please do so; there are a lot 
of people interested in that topic. It definitely goes across multiple 
areas of interest, such as "discovery" and "addressing" and even 
"trust". Personally, I don't think it applies to a transport document.

> I admire the optimism in this.

It was not optimistic with the charter that was originally sent to the 
IESG; see <https://datatracker.ietf.org/doc/charter-ietf-doh/00-00/>. As 
more issues are added to the charter, it makes sense to have to extend 
the milestone deliverable.

--Paul Hoffman

---

From: Adam Roach <[email-masked]>
Date: Fri, 15 Sep 2017 14:00:23 -0500

On 9/15/17 1:24 PM, Paul Hoffman wrote:
> obsolete protocol.

I think you're assuming a tighter coupling between layers than actually 
exists.

In particular -- since you're talking about browsers -- it would easy to 
implement the current draft entirely in content JavaScript. In doing so, 
it would be impossible for the implementation to prevent its use over 
HTTP/1.1 (or QUIC): aside from some proprietary browser-specific APIs, 
there's no way for such an implementation to even tell what version of 
HTTP is in use, much less prevent certain queries from going out over 
unwanted ones.

This all bears more on the specified solution than the charter, but I 
suspect that (after a reasonable back-and-forth in the ensuing working 
group), one reasonable outcome will be that the mechanism works over 
HTTPS in general, simply because it will be too much of an 
implementation burden to prevent it from doing so.

I'd rather not preclude the ability to have that discussion in the 
working group by foreclosing it in the charter language.

/a

---

From: Ted Hardie <[email-masked]>
Date: Fri, 15 Sep 2017 12:25:19 -0700

On Fri, Sep 15, 2017 at 12:00 PM, Adam Roach <[email-masked]> wrote:

>> Yes, please. The charter should say "HTTP/2 over TLS". There is no reason
>> for current browsers adding this feature to add it using an obsolete
>> protocol.
>>
>
>
> implement the current draft entirely in content JavaScript. In doing so, it
> would be impossible for the implementation to prevent its use over HTTP/1.1
> (or QUIC): aside from some proprietary browser-specific APIs,

So, "the implementation" in your statement above--is that the JavaScript or
the browser?

> HTTP is in use, much less prevent certain queries from going out over
So, I think you have a usage in mind that is not the usage model that the
draft talks about and is not really clear in the charter--the use of this
within a JavaScript application to collect DNS responses without going
through the browser/OS cache and DNS method.  If that is a proposed use
case, then I think there is a serious question of how the same origin
policy applies here.

Assume for a second that the resource in question mimics the current DNS
URI structure (RFC 4501), but substitutes HTTPS as a scheme.   If Facebook
JavaScript has a call for https://dns.fb.com/www.google.com?type=AAAA, will
that be within same origin policy or not?  If it is within same origin,
where does the resulting data go?  Just to the JavaScript or into browser
or system caches?

In addition to same origin questions, there are some privacy issues around
this being used to signal external parties.  Imagine a query like this:

https://dns.google.com/unique-id.partner-site.com?type=TXT

I don't know of any cross-site cookie watcher that would catch that, but it
might be needed.

This set of questions is pretty different from the ones you get with
"function over different paths", because the locus of control moves from
the mostly-trusted browser to the mostly not trusted downloaded application.

> group), one reasonable outcome will be that the mechanism works over HTTPS
> in general, simply because it will be too much of an implementation burden
> to prevent it from doing so.
>
> I'd rather not preclude the ability to have that discussion in the working
> group by foreclosing it in the charter language.
>
>
I agree that the working group has to tackle it if it is in scope.  The
question we're discussing now is whether that use case is in scope.  If any
potential solution must deal with that eventuality because they all *could*
be done in Javascript, like it or not, then the question is moot, but
that's not personally clear to me yet.

regards,

Ted

---

From: Adam Roach <[email-masked]>
Date: Fri, 15 Sep 2017 15:19:43 -0500

On 9/15/17 14:25, Ted Hardie wrote:
> On Fri, Sep 15, 2017 at 12:00 PM, Adam Roach <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>         Yes, please. The charter should say "HTTP/2 over TLS". There
>         is no reason for current browsers adding this feature to add
>         it using an obsolete protocol.
>
>
>
>     I think you're assuming a tighter coupling between layers than
>     actually exists.
>
>     In particular -- since you're talking about browsers -- it would
>     easy to implement the current draft entirely in content
>     JavaScript. In doing so, it would be impossible for the
>     implementation to prevent its use over HTTP/1.1 (or QUIC): aside
>     from some proprietary browser-specific APIs,
>
>
> So, "the implementation" in your statement above--is that the 
> JavaScript or the browser?

In the scenario I'm describing, it's the JavaScript.

>     there's no way for such an implementation to even tell what
>     version of HTTP is in use, much less prevent certain queries from
>     going out over unwanted ones.
>
>
> So, I think you have a usage in mind that is not the usage model that 
> the draft talks about and is not really clear in the charter--the use 
> of this within a JavaScript application to collect DNS responses 
> without going through the browser/OS cache and DNS method.  If that is 
> a proposed use case, then I think there is a serious question of how 
> the same origin policy applies here.

Given that (in this scenario), the browser wouldn't know this query from 
any _other_ HTTPS request, it applies the same way as it does to all 
other HTTPS requests.

> Assume for a second that the resource in question mimics the current 
> DNS URI structure (RFC 4501), but substitutes HTTPS as a scheme.   If 
> Facebook JavaScript has a call for 
> https://dns.fb.com/www.google.com?type=AAAA, will that be within same 
> origin policy or not?

You didn't say what the origin of the calling page was. If it's the same 
origin, then it's the same origin (modulo CORS behavior).

> If it is within same origin, where does the resulting data go?  Just 
> to the JavaScript or into browser or system caches?

The scenario I'm posting above assumes no special browser behavior.

> In addition to same origin questions, there are some privacy issues 
> around this being used to signal external parties.  Imagine a query 
> like this:
>
> I don't know of any cross-site cookie watcher that would catch that, 
> but it might be needed.

This is a fine point. I do wonder how the resolvers at 8.8.8.8 and 
8.8.4.4 handle it. I suppose the API deployed at 
https://developers.google.com/speed/public-dns/docs/dns-over-https is 
probably closer to the use case we're contemplating, though.

To be clear, I'm not saying that these situations you describe aren't 
_bad_; I'm pointing out that they already exist with or without the 
mechanism under discussion. I would think the standard here is "don't 
make it worse," rather than "first, drain the swamp."

I'll also point out that this use case (the JavaScript-based one) is 
nice in that it allows applications to communicate with a known trusted 
site (e.g., their own origin) to prevent this kind of unintentional 
exfiltration of information. Of course, this is already possible today 
using proprietary mechanisms, but it would be nice if such apps could 
use standard libraries.

> I agree that the working group has to tackle it if it is in scope.  
> The question we're discussing now is whether that use case is in 
> scope.  If any potential solution must deal with that eventuality 
> because they all *could* be done in Javascript, like it or not, then 
> the question is moot, but that's not personally clear to me yet.

I chose that example because it's easy to reason about without knowing 
the internal implementation architecture of browsers. If we instead turn 
to the *other* use case that you describe in which the browser (absent 
any special JavaScript handling) chooses to use DNS-over-HTTPS, then a 
congruent problem arises. While it's not an area I've worked in closely, 
what I've seen of Firefox's network layer implementation leads me to 
believe that precluding a mechanism like this from working across all 
supported variations of HTTP would require additional code; and that the 
role of that code, in its entirety, would be to prevent from working 
that which otherwise would. Unless there are, say, security implications 
to doing so, I'd think we need better rationale for preventing it than 
"we don't want to think about it."

/a

---

From: Ted Hardie <[email-masked]>
Date: Fri, 15 Sep 2017 13:53:40 -0700

In-line.

On Fri, Sep 15, 2017 at 1:19 PM, Adam Roach <[email-masked]> wrote:

>>> reason for current browsers adding this feature to add it using an obsolete
>>> protocol.
>>>
>>
>>
> So, "the implementation" in your statement above--is that the JavaScript
> or the browser?
>
>
> any _other_ HTTPS request, it applies the same way as it does to all other
> HTTPS requests.
>
>
You're making an assumption that I don't think is established, that the
requests using HTTPS for DNS are not distinguishable from other resources.
If they were keyed by something like dnsh://authority/query-target?RR (to
pick on poor old RFC 4501 again), they would be in JavaScript *even if they
were not on the wire*.

> JavaScript has a call for https://dns.fb.com/www.google.com?type=AAAA,
> will that be within same origin policy or not?
>
>
> You didn't say what the origin of the calling page was.
>

Sorry, when I said "Facebook JavaScript" I meant to imply that facebook was
the origin and that fb.com would same origin.

> If it's the same origin, then it's the same origin (modulo CORS behavior).
>
>
I'm frankly a bit worried that the GET version of Paul's draft would not
trigger the CORS pre-flight checks.  If it is consumed by JavaScript and
never otherwise cached, that's not so big a deal, but if it is populating a
browser or system cache, it's a problem.

> If it is within same origin, where does the resulting data go?  Just to
> the JavaScript or into browser or system caches?
>
>
I'm not sure "no special browser behavior" answers my question.  Is the
default the browser behavior when it gets a DNS response or the browser
behavior for content JavaScript requests in-line?

> I don't know of any cross-site cookie watcher that would catch that, but
> it might be needed.
>
>
>

> This is a fine point. I do wonder how the resolvers at 8.8.8.8 and 8.8.4.4
> handle it. I suppose the API deployed at https://developers.google.com/
> speed/public-dns/docs/dns-over-https is probably closer to the use case
> we're contemplating, though.
>
>
(I wasn't involved developing that, so the view from the outside); that
looks very much like it would take the JSON records returned and populate
the standard cache(s) with them.

> mechanism under discussion. I would think the standard here is "don't make
> it worse," rather than "first, drain the swamp."
>
> I'll also point out that this use case (the JavaScript-based one) is nice
> in that it allows applications to communicate with a known trusted site
> (e.g., their own origin) to prevent this kind of unintentional exfiltration
> of information. Of course, this is already possible today using proprietary
> mechanisms, but it would be nice if such apps could use standard libraries.
>
>
The trust relationship you mention is important (the JavaScript trusting
its source), but we also have to consider the user's trust in the
JavaScript.  A malicious piece of JavaScript is not so hard to introduce
into the world, and if it can influence the DNS mapping, it may be well
worth the time of phishers and others to do so.

> I chose that example because it's easy to reason about without knowing the
> internal implementation architecture of browsers. If we instead turn to the
> *other* use case that you describe in which the browser (absent any special
> JavaScript handling) chooses to use DNS-over-HTTPS, then a congruent
> problem arises. While it's not an area I've worked in closely, what I've
> seen of Firefox's network layer implementation leads me to believe that
> precluding a mechanism like this from working across all supported
> variations of HTTP would require additional code; and that the role of that
> code, in its entirety, would be to prevent from working that which
> otherwise would. Unless there are, say, security implications to doing so,
> I'd think we need better rationale for preventing it than "we don't want to
> think about it."
>

I assume that you have code that would let you say "not unless protected by
TLS", though, so that portion of the charter presumption matches reality?

Thanks for your insight into this,

Ted

---

From: Adam Roach <[email-masked]>
Date: Fri, 15 Sep 2017 15:56:43 -0500

On 9/15/17 15:53, Ted Hardie wrote:
> I assume that you have code that would let you say "not unless 
> protected by TLS", though, so that portion of the charter presumption 
> matches reality?

Yes; there's a *lot* of "don't do this over unsecured transports" code.

/a

---

From: "Paul Hoffman" <[email-masked]>
Date: Fri, 15 Sep 2017 15:04:36 -0700

On 15 Sep 2017, at 14:44, Stephen Farrell wrote:

> On 15/09/17 20:25, Ted Hardie wrote:
>>
> FWIW, I share Ted's concerns about origins. Regardless
> of what approaches are taken, the effects of this need
> to be well understood I think. I don't object to the WG
> being chartered though but would suggest that there be
> a mention in the charter that the WG needs to document
> the consequences, including the dangers, of caching and
> re-use of DNS answers for likely implementations.

The charter already points to the document that the work will be based 
on, which has that topic in it, because *you* pointed it out in the 
earlier discussion of the document. As co-author on the document, I 
assure you we will not remove it, if for no other reason than I wouldn't 
want to face your wrath again in IETF Last Call. :-)

> I'd be even happier if the resulting spec had a bunch
> of MUST NOT statements about that, if such statements
> were likely to be effective.

All MUST NOTs are only partially effective, but we use them anyway to 
help good implementers. If you have some proposed MUST NOTs on the 
current document, by all means send them in.

--Paul Hoffman

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Fri, 15 Sep 2017 17:14:16 -0500

To a slightly smaller crowd ...

On Fri, Sep 15, 2017 at 5:04 PM, Paul Hoffman <[email-masked]> wrote:

> The charter already points to the document that the work will be based on,
> which has that topic in it, because *you* pointed it out in the earlier
> discussion of the document. As co-author on the document, I assure you we
> will not remove it, if for no other reason than I wouldn't want to face
> your wrath again in IETF Last Call. :-)

I recently pointed out, while complaining about pervasive monitoring in an
AD Evaluation for a TSV document, that not only is
https://tools.ietf.org/html/rfc7258 a BCP, but if
https://www.ietf.org/mailman/roster/secdir really is the list of reviewers
like https://trac.ietf.org/trac/sec/wiki/SecurityDirectorate says it is,
authors have a non-zero chance of getting an RFC 7258 author as their
sec-dir reviewer ...

The same probability of getting Stephen would apply here.

You are very wise :-)

Spencer

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 15 Sep 2017 22:44:30 +0100

S.

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 15 Sep 2017 23:33:10 +0100

On 15/09/17 23:04, Paul Hoffman wrote:
>>> This set of questions is pretty different from the ones you get
>>> with "function over different paths", because the locus of
>>> control moves from the mostly-trusted browser to the mostly not
>>> trusted downloaded application.
>> 
>> FWIW, I share Ted's concerns about origins. Regardless of what
>> approaches are taken, the effects of this need to be well
>> understood I think. I don't object to the WG being chartered though
>> but would suggest that there be a mention in the charter that the
>> WG needs to document the consequences, including the dangers, of
>> caching and re-use of DNS answers for likely implementations.
> 
> The charter already points to the document that the work will be
> based on, which has that topic in it, because *you* pointed it out in
> the earlier discussion of the document. As co-author on the document,
> I assure you we will not remove it, if for no other reason than I
> wouldn't want to face your wrath again in IETF Last Call. :-)

"Wrath" has to count a pretty speedy escalation in terms,
and especially when I'm so shy and retiring about saying
what I think:-)

I'm also confident that that security considerations will
cover this topic in some sense. I'm not confident that I
understand the relevant consequences at this point in
time, so ISTM useful to mention it in the charter as that
might help later.

> 
>> I'd be even happier if the resulting spec had a bunch of MUST NOT
>> statements about that, if such statements were likely to be
>> effective.
> 
> All MUST NOTs are only partially effective, but we use them anyway
> to help good implementers. 

Agreed. And sometimes we use them to describe damaging
things bad implementers might otherwise be likely to do
without realising the downsides.

> If you have some proposed MUST NOTs on
> the current document, by all means send them in.

Probably better in a different thread, but I think there
is scope for a MUST NOT (re-)use answers outside the same
origin, but I've no doubt there are subtleties there that
the WG would need to figure out and that'd make this
sentence a bad idea to include on it's own.

S.

---

From: Mark Nottingham <[email-masked]>
Date: Sat, 16 Sep 2017 11:51:48 +1000

On 16 Sep 2017, at 4:24 am, Paul Hoffman <[email-masked]> wrote:
> Yes, please. The charter should say "HTTP/2 over TLS". There is no reason for current browsers adding this feature to add it using an obsolete protocol. If someone wants to create a diff from the eventual protocol for HTTP 1.1, they can do that without forcing the document to add a comparison of the two transports to what is supposed to be a short, concise document.

Whoa; hold it right there. Last I checked, we had only obsoleted HTTP/0.9; 1.1 is still very actively used, still on the standards track, and despite some peoples' wishes, needs and gets attention.

> The deadline for this WG is well ahead of when HTTP-over-QUIC will be finalized. Instead, when HTTP-over-QUIC is finalized, an update to this document should be pretty easy to produce.

I don't understand why anyone thinks anything would be required at all; if QUIC does its job properly, any application defined for HTTP/1.1 or HTTP/2 should work on HTTP-over-QUIC (whatever we end up calling it) without any changes. 

>> input document to do so).

I interpret the charter to say that this protocol is *using* HTTP, in the sense of <https://mnot.github.io/I-D/bcp56bis/#used>. In that view, this WG *cannot* change that.

> If you want to propose a new WG for that, please do so; there are a lot of people interested in that topic. It definitely goes across multiple areas of interest, such as "discovery" and "addressing" and even "trust". Personally, I don't think it applies to a transport document.

I agree that it's a preferable separable rathole.

> It was not optimistic with the charter that was originally sent to the IESG; see <https://datatracker.ietf.org/doc/charter-ietf-doh/00-00/>. As more issues are added to the charter, it makes sense to have to extend the milestone deliverable.

I'd prefer to keep the current milestone by avoiding additions.

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

---

From: Mark Nottingham <[email-masked]>
Date: Sat, 16 Sep 2017 11:52:57 +1000

> On 16 Sep 2017, at 6:53 am, Ted Hardie <[email-masked]> wrote:
> 
> You're making an assumption that I don't think is established, that the requests using HTTPS for DNS are not distinguishable from other resources.  If they were keyed by something like dnsh://authority/query-target?RR (to pick on poor old RFC 4501 again), they would be in JavaScript *even if they were not on the wire*.

As before, I read the charter as saying that this protocol will use HTTP in the sense of <https://mnot.github.io/I-D/bcp56bis/#used> -- i.e., defining a new URI scheme is out of scope. If that's not clear, it should be made explicit.

---

From: Patrick McManus <[email-masked]>
Date: Fri, 15 Sep 2017 19:23:28 -0700

Hi All. I'll respond to most of the key points in one message. Forgive the
consolidation.

* This is meant to be over "https" full stop. Whether that means we require
a particular minimum level of version (which the input draft defines as >=
h2 not == h2 btw) to satisfy the uses at hand is a controversy suitable for
the wg to resolve.

On one hand we should consider that semantic http has no versioning, so
using the semantics from something like javascript becomes impossible to
enforce the versioning requirement (though the server could do so). otoh
you could argue that the mechanisms of <=h1 are not technically up to the
task (hol blocking, lack of priority, etc..) of providing a reasonable
implementation for a recursive resolver like use case.. or even argue that
the IETF would have been better off historically across the board using new
functionality as a forcing function for migrating to newer specifications
rather than putting such a premium on backwards compatibility (or arguing
against that based on bootstrapping costs, etc..). As I said - that's a
controversy for the wg. The charter should be over https, and the wg can
decide exactly what that means there is no need to litigate it in a charter
discussion.

* I believe adam and mnot are right on the questions of same origin, js,
https:// uris..

* I think its fine for the charter to say the group must document the
security considerations of the source of a name resolution.

-P

---

From: Stephen Farrell <[email-masked]>
Date: Sat, 16 Sep 2017 17:15:40 +0100

On 16/09/17 17:07, Phillip Hallam-Baker wrote:
> We had a re-run of the same issues with DPRIV which began with the
> assertion that a solution must be found within a year. 

I don't recall any such assertion. IIRC, DPRIVE was always
considered as the start, within the IETF, of a marathon.
(At least by anyone credible.)

Perhaps you can provide a pointer to that assertion?

Aside from that, I'm not clear who you think is being
ignored with the current proposal, nor what you think
we ought wait upon, so it'd help me understand your
objections if you could clarify those aspects. (FWIW,
as of now, I don't share your concerns in those respects
at all.)

S.

---

From: Ted Hardie <[email-masked]>
Date: Sat, 16 Sep 2017 10:32:41 -0700

On Fri, Sep 15, 2017 at 6:52 PM, Mark Nottingham <[email-masked]> wrote:

> As before, I read the charter as saying that this protocol will use HTTP
> in the sense of <https://mnot.github.io/I-D/bcp56bis/#used> -- i.e.,
> defining a new URI scheme is out of scope. If that's not clear, it should
> be made explicit.
>
>
So, I don't that this is established.  One mental model for this work is
that DNS, having started with UDP and TCP as transports, has now added a
set of additional secure transports.  Two of those were defined in DPRIV;
this defines another.  From that perspective, any time an application
requires a DNS name to be resolved, the relevant local code would try the
set of secure transports until it got an answer.  The application may not
know which is used and does not specify it; it is simply getting the DNS
answer back that allows it to proceed.  The name of the group (DNS over
HTTP), the justification at the beginning of the charter:

This will enable the domain name system to function over certain paths
where existing DNS methods (UDP, TLS, and DTLS) experience problems. This
will enable the domain name system to function over certain paths where
existing DNS methods (UDP, TLS, and DTLS)
experience problems.

and Paul's input draft all point to that interpretation.  Note especially
that Paul's draft provides the UDP wireformat as response.  To me, that
strongly hints that the results of this get handed to the same bit of code
that would take the UDP wireformat from other transports (like UDP) and do
what it would have done with data retreived from any of those.  That
behavior makes sense for DNS transported over HTTP, where you are talking
to an authoritative server or shared resolver over a new transport.

That order of operations does not make sense as a new resource type
available to web applications, in part because they can't tell from
examining the URI whether the resulting *resource* obeys CORS or not.
There are serious attacks here that even DNSSEC won't catch, because a
malicious server and cooperating JavaScript app could give correct answers
that are non performant (like the search engine instance on the most
distant continent).  And, if there really was a handoff to the local DNS
subsystem for parsing and processing, the JavaScript also wouldn't be able
to tell whether the result they get from that subsystem is the one that the
just retrieved (because a cache entry from some other system may have a
different SOA record and be returned as a result instead).  To avoid that,
they would have build udp wireformat parsers into the downloadable
javascript.

I think if you want the second, a way of making DNS resources available to
web applications, you need a very different approach; it may be valuable,
but I don't believe this charter covers it.  If it is meant to, it needs a
major re-write.

regards,

Ted

---

From: Adam Roach <[email-masked]>
Date: Sat, 16 Sep 2017 12:54:00 -0500

On 9/16/17 12:32, Ted Hardie wrote:
> To avoid that, they would have build udp wireformat parsers into the 
> downloadable javascript.

To be clear, in the scenario I outlined, that's exactly what I was 
intending to describe. It hadn't even occurred to me that one might form 
a model, based on that description, that involved routing the 
information through the local, OS-level stub resolver. Now that you've 
clarified that confusion, I agree: a system that did so would be 
terrifyingly difficult to secure. Let's not do that horrible thing.

And I hope my previous explanation was clear: this isn't the primary use 
case for this work; I used it in my example because it was a very easy 
way to explain the layering issue to anyone with a basic understanding 
of the web platform. I wouldn't over-rotate on it. (That said, I know 
that several people are watching this work precisely because they do 
want to perform these operations in JavaScript. The input draft does not 
preclude doing so, and I see no reason to artificially limit the 
mechanism in a way that prevents it.)

/a

---

From: Mark Nottingham <[email-masked]>
Date: Sun, 17 Sep 2017 13:00:11 +1000

Ted,

On 17 Sep 2017, at 3:32 am, Ted Hardie <[email-masked]> wrote:
> So, I don't that this is established.  One mental model for this work is that DNS, having started with UDP and TCP as transports, has now added a set of additional secure transports.  Two of those were defined in DPRIV; this defines another.  From that perspective, any time an application requires a DNS name to be resolved, the relevant local code would try the set of secure transports until it got an answer.  The application may not know which is used and does not specify it; it is simply getting the DNS answer back that allows it to proceed.  

Every time people start talking in this manner and referring to HTTP as a "transport", I get flashbacks to WS-* and what a glorious failure that was.

> The name of the group (DNS over HTTP), the justification at the beginning of the charter: 
> 
> This will enable the domain name system to function over certain paths where existing DNS methods (UDP, TLS, and DTLS) experience problems. This will enable the domain name system to function over certain paths where existing DNS methods (UDP, TLS, and DTLS) 
> experience problems. 
> 
> and Paul's input draft all point to that interpretation.  Note especially that Paul's draft provides the UDP wireformat as response.  To me, that strongly hints that the results of this get handed to the same bit of code that would take the UDP wireformat from other transports (like UDP) and do what it would have done with data retreived from any of those.  That behavior makes sense for DNS transported over HTTP, where you are talking to an authoritative server or shared resolver over a new transport.  

I don't disagree that the charter lays out that the goal is to enable the use case of DNS using HTTP semantics -- that's hopefully uncontroversial.

> That order of operations does not make sense as a new resource type available to web applications, in part because they can't tell from examining the URI whether the resulting *resource* obeys CORS or not.

It's not clear why that's an important property. Why is it necessary?

> There are serious attacks here that even DNSSEC won't catch, because a malicious server and cooperating JavaScript app could give correct answers that are non performant (like the search engine instance on the most distant continent).  

Who would be consuming these answers? How is this different from configuring your system to use a malicious DNS resolver (either in an application or the OS)?

> And, if there really was a handoff to the local DNS subsystem for parsing and processing, the JavaScript also wouldn't be able to tell whether the result they get from that subsystem is the one that the just retrieved (because a cache entry from some other system may have a different SOA record and be returned as a result instead).  To avoid that, they would have build udp wireformat parsers into the downloadable javascript.
> 
> I think if you want the second, a way of making DNS resources available to web applications, you need a very different approach; it may be valuable, but I don't believe this charter covers it.  If it is meant to, it needs a major re-write.

I agree there are significant risks when using DNS. I think the question is what to do about it.

One thing the WG could do would be to write some Security Considerations about the different ways this could be sub-optimal or even dangerous. 

I don't see how giving the protocol a new URI scheme avoids these risks, given that the defined resources would be available over HTTP still.

Cheers,

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sat, 16 Sep 2017 12:07:48 -0400

Responding to the thread as a whole:

1) I see no evidence that HTTP/2 is suited to Web Services or will be
dominant in that role. HTTP/2 was designed to serve Web Browsing to the
exclusion of all other concerns. Which was the right choice to make.

Web Services that are not merely information fetch protocols rarely make
any use of HTTP features at all except for framing and to increase the
number of ports by using URIs as ports. Raw TCP/IP transport is no longer
practical due to the large number of firewalls and NATs and 2^16 ports
would be insufficient anyway.

2) Web Services over some form of QUIC are almost certain to be popular.

QUIC addresses pretty much the exact same set of concerns that the use of
HTTP/1.1 for Web Services does and finesses the problem of TCP/IP being
designed for a different age. If QUIC was not being developed, a lot of Web
Service developers might well look at HTTP/2 but as things stand, I have
zero interest in HTTP/2 because I know that it is a dead end for Web
Services.

This is a *good thing* BTW. There are only two types of traffic: Web
Browsing and non-Web browsing. Does it really make sense to suggest that
they both over the same protocol?

3) This is the wrong time to do this work.

Failed experiments come at the cost of creating obstacles that get in the
way of real progress. The same argument is made every time one of these
experiments is proposed and we get the same result. During chartering the
argument is "We are just concentrating on one problem, this does not
exclude anyone else", After the working group is chartered it is "Hands off
our turf", after the RFCs are published and nobody is implementing them it
is "we tried and we proved that nobody else could have solved the problem".

There is a growing list of these failed projects, lets just pick DANE. DANE
was meant to be a way to publish TLS certificates and to communicate 'must
use TLS' security policy. There are numerous technical and commercial
reasons that combination was doomed to fail even if the deployment platform
was not DNS which makes the difficulty of everything squared. The proposal
did not have support from the Web Browser providers whose co-operation was
essential and killed attempts to sell DNSSEC through DNS Registrars (most
of whom make their margin on WebPKI affiliate fees). Input from all
stakeholders was rejected.

If you recall, CAA was originally proposed by myself and Ben Laurie of
Google. The reason Ben dropped out was that I was forced to remove the
security policy dimension of CAA. Now given that CAs are now required to
support CAA by CABForum, doesn't this mean that there was a real cost to
letting the DANE group bully us out of that space?

[This is not how I would do security policy now BTW, I would look to use
the TXT records as described in RFC 6763 to incorporate the same sort of
data that is specified in HTTP Key Pinning for Web Services.]

We had a re-run of the same issues with DPRIV which began with the
assertion that a solution must be found within a year. This restricted the
range of technology solutions to a set that were utterly inappropriate.
Currently, the WG is still functioning but it has no support from any
deployment stakeholder I am aware of.

The point I am making here is that DNS is the wrong layer in the stack for:

* Working Groups with a narrow scope
* Working Groups attempting to achieve a result in a narrow time scale
* Working Groups that insist on owning the topic.
* Working Groups that refuse to engage the necessary stakeholders

---

From: Tim Wicinski <[email-masked]>
Date: Sun, 17 Sep 2017 14:24:04 -0400

> as of now, I don't share your concerns in those respects

As DPRIV co-chair, I agree with Stephen's assertion that this was always 
going to be a marathon.  Now Phillip is correct in some respects - I 
felt *a* solution for the stub to recursive resolver piece could be 
worked out within a year.  But I've always felt the IETF was all about 
iteration: Let's come up with a solution; let's write some code and 
deploy some infrastructure; let's measure the behavior and the 
usefulness of what was done; and in the interim let's keep looking at 
other ideas.

The next steps within DPRIV are around the recursive resolvers talking 
to authoritative servers; and this is something Terry (our wonderful AD) 
and myself see as a much harder problem, and one most likely that will 
end in failure.

tim

---

From: Ted Hardie <[email-masked]>
Date: Mon, 18 Sep 2017 10:20:16 -0700

On Sat, Sep 16, 2017 at 8:00 PM, Mark Nottingham <[email-masked]> wrote:

> answer back that allows it to proceed.
>
> Every time people start talking in this manner and referring to HTTP as a
> "transport", I get flashbacks to WS-* and what a glorious failure that was.
>
>
If it helps, I am happy to say "facilitating protocol".  The mental model
question for the charter is really:

Does this add a new tool for DNS systems attempting resolution to use when
previous efforts are blocked?  So any DNS resolution might use it, whether
from a browser, an app, or system call, but that those would not *specify*
it be used?

Does this add a method for Web application to directly resolve DNS resource
records using a resolver self-identified in the Javascript?  So DNS
resolutions are instantiated and consumed by Javascript without any
intermediation by the local DNS resolver or the browser's DNS rules?

Does this charter aim for the working group to do both?

As currently written, I see the charter describing 1.  There has been an
argument that it also do 2 or that 2 becomes possible when 1 is specified
and is thus automatically part of the scope.  If that is the case, I
believe the charter needs a re-write to describe it.

> > and Paul's input draft all point to that interpretation.  Note
> especially that Paul's draft provides the UDP wireformat as response.  To
> me, that strongly hints that the results of this get handed to the same bit
> of code that would take the UDP wireformat from other transports (like UDP)
> and do what it would have done with data retreived from any of those.  That
> I don't disagree that the charter lays out that the goal is to enable the
> use case of DNS using HTTP semantics -- that's hopefully uncontroversial.
>
If it goes into a browser or system cache, it is an important property; it
may also be important depending on the UI result.  If the
JavaScript-internal resolution process feeds other parts of the page, it
may even be a problem.

> distant continent).
> Who would be consuming these answers? How is this different from
> configuring your system to use a malicious DNS resolver (either in an
> application or the OS)?
>
> Because the JavaScript you download could pick the resolver.  The OS and
browser are largely trusted; the JavaScript is largely not.

> > And, if there really was a handoff to the local DNS subsystem for
> parsing and processing, the JavaScript also wouldn't be able to tell
> whether the result they get from that subsystem is the one that the just
> retrieved (because a cache entry from some other system may have a
> > I think if you want the second, a way of making DNS resources available
> to web applications, you need a very different approach; it may be
> valuable, but I don't believe this charter covers it.  If it is meant to,
> it needs a major re-write.
>
> One thing the WG could do would be to write some Security Considerations
> about the different ways this could be sub-optimal or even dangerous.
>
> I don't see how giving the protocol a new URI scheme avoids these risks,
> given that the defined resources would be available over HTTP still.
>
>
It gives the browser something to look at.  If it rejects udp-wireformat
mime types being returned from HTTPS URIs but accepts them from dnsh URIs,
it can handle the data differently.  I don't know that browsers want to do
that, mind you, I'm simple saying that the working group could decide that
this was a reasonable facility to consider.  Ruling out ways for the
ecosystem to distinguish this from other web resources seems to be the
wrong way to go, at least to me.

regards,

Ted

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 18 Sep 2017 17:29:52 +0000

On Sep 18, 2017, at 10:20 AM, Ted Hardie <[email-masked]> wrote:
> Does this add a new tool for DNS systems attempting resolution to use when previous efforts are blocked?  So any DNS resolution might use it, whether from a browser, an app, or system call, but that those would not *specify* it be used?
> 
> Does this add a method for Web application to directly resolve DNS resource records using a resolver self-identified in the Javascript?  So DNS resolutions are instantiated and consumed by Javascript without any intermediation by the local DNS resolver or the browser's DNS rules?
> 
> As currently written, I see the charter describing 1.

Then that may be a failure of the current charter text. 

>  There has been an argument that it also do 2 or that 2 becomes possible when 1 is specified and is thus automatically part of the scope.  If that is the case, I believe the charter needs a re-write to describe it.  

In the many discussions leading up to the -00 wording for the charter (which became much longer in IESG discussion), #2 was the clear use case.

--Paul Hoffman

---

From: Adam Roach <[email-masked]>
Date: Mon, 18 Sep 2017 13:17:10 -0500

On 9/18/17 12:29 PM, Paul Hoffman wrote:
> In the many discussions leading up to the -00 wording for the charter (which became much longer in IESG discussion)

$ wc charter-ietf-doh-00-00.txt
       19     127     831 charter-ietf-doh-00-00.txt

$ wc charter-ietf-doh-00-06.txt
       19     168    1124 charter-ietf-doh-00-06.txt

I'm not sure a 41-word expansion really qualifies as "much longer," 
especially given that 53 of those words are new text requiring 
coordination with other WGs that have a vested interest in this topic.

This conversation might be more productive if we hedge away from hyperbole.

/a

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 18 Sep 2017 18:35:50 +0000

On Sep 18, 2017, at 11:17 AM, Adam Roach <[email-masked]> wrote:
> I'm not sure a 41-word expansion really qualifies as "much longer," especially given that 53 of those words are new text requiring coordination with other WGs that have a vested interest in this topic.

Good point.

> This conversation might be more productive if we hedge away from hyperbole.

Indeed, and I apologize for injecting that last bit of hyperbole here. FWIW, it is my intention to be a good document editor and follow WG consensus on what needs to be added as the eventual WG discussion evolves.

--Paul Hoffman

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 19 Sep 2017 10:26:25 +1000

Hi Ted,

Sorry, threading is a bit confusing below (thanks, GMail).

> On 19 Sep 2017, at 3:20 am, Ted Hardie <[email-masked]> wrote:
> 
> If it helps, I am happy to say "facilitating protocol".  The mental model question for the charter is really:
> 

That sounds like an implementation choice, not a protocol decision. What in the protocol could constrain that?

> Does this add a method for Web application to directly resolve DNS resource records

Well, once it's available over HTTP, that's certainly possible. A quick search for "DNS lookup online" shows many people doing that already, albeit with different formats.

> using a resolver self-identified in the Javascript? So DNS resolutions are instantiated and consumed by Javascript without any intermediation by the local DNS resolver or the browser's DNS rules?

What does "a resolver self-identified in the Javascript" mean, exactly?

Are you supposing some sort of rendezvous system where I can "install" a DOH resolver from one origin and have it affect requests sent to another?

Doing so isn't possible on the current Web, so enabling it would require some fairly heavy lifting at the W3C and/or WHATWG (which on the face of it, they're not likely to think is sane). I can only hope that defining such a thing is out of scope for this WG, as we truly don't have the expertise here.

> As currently written, I see the charter describing 1.  There has been an argument that it also do 2 or that 2 becomes possible when 1 is specified and is thus automatically part of the scope.  If that is the case, I believe the charter needs a re-write to describe it.  

See above.

> If it goes into a browser or system cache, it is an important property; it may also be important depending on the UI result.  If the JavaScript-internal resolution process feeds other parts of the page, it may even be a problem.

When you say "cache", do you mean HTTP or DNS? I'm afraid I still don't get what you're looking for here.

> Because the JavaScript you download could pick the resolver.  The OS and browser are largely trusted; the JavaScript is largely not.

OK, this seems to indicate you *do* think that somehow arbitrary JS can take over DNS resolution for the system or browser. What led you to that conclusion?

> It gives the browser something to look at.  If it rejects udp-wireformat mime types being returned from HTTPS URIs but accepts them from dnsh URIs, it can handle the data differently.
> 
>  I don't know that browsers want to do that, mind you, I'm simple saying that the working group could decide that this was a reasonable facility to consider.  Ruling out ways for the ecosystem to distinguish this from other web resources seems to be the wrong way to go, at least to me.

Again, I don't think this WG should be attempting to allow any sort of automated control of browser or system DNS resolution from the Web (e.g., JS, triggered by arbitrary URI schemes, mime types, whatever); I've seen zero desire from any implementer to allow that, it's fraught with security, privacy and other issues, and has dubious benefit.

The use case that I believe most have in mind is "as a user, I want to configure my [browser, OS] to use *this* DOH service for DNS resolution" -- where that configuration is manual; e.g., a configuration textbox or dropdown in the browser, or a file in /etc. It might be made more user-friendly; e.g., it could be automatic when the user goes into the ill-defined "private mode." 

The current charter allows that. I *think* the issues you're concerned about are in a very different area -- roughly, "automated control of DNS resolution." I'm not sure where you got the sense that this was on the table, but if it will help, write it out of the charter.

Cheers,

---

From: Eliot Lear <[email-masked]>
Date: Tue, 19 Sep 2017 07:35:51 +0200

Hi Mark,

> The use case that I believe most have in mind is "as a user, I want to configure my [browser, OS] to use *this* DOH service for DNS resolution" -- where that configuration is manual; e.g., a config…

Your first sentence should probably be recognizable in the charter (it's
not, and thus all the email).  That would at least allow for operations
that are congruent with existing methods so that split DNS and malware
protection functions can take place.  It also at least roughly matches
the security considerations text already in the draft.

As to the 2nd sentence, ain't nothing stopping that, but some text
should probably make it into the draft that *someone* is going to know
what queries you're making.  That's not a charter issue, of course.

Eliot

---

From: Ted Hardie <[email-masked]>
Date: Tue, 19 Sep 2017 09:59:47 -0700

Howdy,

I'll try to snip pieces not salient without hindering attribution; hope
that helps.

On Mon, Sep 18, 2017 at 5:26 PM, Mark Nottingham <[email-masked]> wrote:

> > If it helps, I am happy to say "facilitating protocol".  The mental
> model question for the charter is really:
> >
> > Does this add a new tool for DNS systems attempting resolution to use
> when previous efforts are blocked?  So any DNS resolution might use it,
> whether from a browser, an app, or system call, but that those would not
> *specify* it be used?
>
I'm talking about the goals here.  If the intent is to have this
facilitating protocol hot-swappable for any other method of interacting
between a DNS client and DNS server, we have a set of tasks in front of the
working group and a good idea of where the trade-offs should lean.

> Well, once it's available over HTTP, that's certainly possible. A quick
> search for "DNS lookup online" shows many people doing that already, albeit
> with different formats.
>
>
> > using a resolver self-identified in the Javascript? So DNS resolutions
> are instantiated and consumed by Javascript without any intermediation by
> the local DNS resolver or the browser's DNS rules?
>
> Are you supposing some sort of rendezvous system where I can "install" a
> DOH resolver from one origin and have it affect requests sent to another?
>
>
Can I have JavaScript retrieve a resource like
https://dns.initial-origin.example/query-for-dns?www.major-search-engine.example
then use the result in place of the browser's DNS routines or the system
DNS routines for retrieving https://www.major-search-engine.example/ within
that JavaScrit application?  If that is possible, then I need to know where
the DNS data retrieved can be reused and I need to know whether the
rendering distinguishes in any way between data so retrieved and data
retrieved by a more trusted element.   Does the data end up in the
browser's DNS cache?  Does a hover over an element show that this URI would
be using a JavaScript supplied resolver to retrieve the location should I
click?

> Doing so isn't possible on the current Web, so enabling it would require
> some fairly heavy lifting at the W3C and/or WHATWG (which on the face of
> it, they're not likely to think is sane). I can only hope that defining
> such a thing is out of scope for this WG, as we truly don't have the
> expertise here.
>
>
Interestingly, that's not what I understood others' answer to be.  Their
view was that since
https://dns.initial-origin.example/query-for-dns?www.major-search-engine.example
was within the initial-origin, resources from it would be treated as same
origin.  If I understood correctly the code that would limit those
resources to same origin isn't present and would have to run after the UDP
wireformat was parsed (otherwise there are trivial attacks in returning
additional data that cache poisons whatever the scope of use turns out to
be).

> > I don't disagree that the charter lays out that the goal is to enable
> the use case of DNS using HTTP semantics -- that's hopefully
> uncontroversial.
> >
> > If it goes into a browser or system cache, it is an important property;
> it may also be important depending on the UI result.  If the
I mean DNS cache.  My apologies for the earlier inexactness.

> >  > There are serious attacks here that even DNSSEC won't catch, because
> a malicious server and cooperating JavaScript app could give correct
> answers that are non performant (like the search engine instance on the
> most distant continent).
> >
> OK, this seems to indicate you *do* think that somehow arbitrary JS can
> take over DNS resolution for the system or browser. What led you to that
> conclusion?
>
>
The goal to use this as a swappable facilitating protocol for DNS
resolution led me to that conclusion; in that usage, the resulting DNS data
would populate the relevant DNS cache.  Re-using the same system within
JavaScript naively would have very bad properties; some segregation to
handle the different levels of trust is required.

>
>
> >
> >  I don't know that browsers want to do that, mind you, I'm simple saying
> that the working group could decide that this was a reasonable facility to
> consider.  Ruling out ways for the ecosystem to distinguish this from other
> web resources seems to be the wrong way to go, at least to me.
>
> Again, I don't think this WG should be attempting to allow any sort of
> automated control of browser or system DNS resolution from the Web (e.g.,
> JS, triggered by arbitrary URI schemes, mime types, whatever); I've seen
> zero desire from any implementer to allow that, it's fraught with security,
> privacy and other issues, and has dubious benefit.
>
> Should I take it that you disagree with the assertion that if we build for
goal 1 (a swappable facilitating protocol) that we have automatically built
a mechanism that is callable within a JavaScript application (which, as I
understand it, Adam and others believe)?

> The use case that I believe most have in mind is "as a user, I want to
> configure my [browser, OS] to use *this* DOH service for DNS resolution" --
> where that configuration is manual; e.g., a configuration textbox or
> dropdown in the browser, or a file in /etc. It might be made more
> user-friendly; e.g., it could be automatic when the user goes into the
> ill-defined "private mode."
>
>
Would you consider a system in which the local browser or OS tested for the
availability of a DOH server at a supplied address within scope (that would
be one way to re-use the current DHCP-supplied servers, for example)?

The current charter allows that. I *think* the issues you're concerned
> about are in a very different area -- roughly, "automated control of DNS
> resolution." I'm not sure where you got the sense that this was on the
> table, but if it will help, write it out of the charter.
>
> My concern isn't just that it be out of scope of the charter, its that it
either be not in the capability set of the resulting work or well-handled
in that context.  Folks asserting that it could not be eliminated from the
capability set for JavaScript applications caused me to focus on the
latter.  If the work can be constrained such that this does not arise, so
much the better.

regards,

Ted

---

From: Adam Roach <[email-masked]>
Date: Tue, 19 Sep 2017 12:28:48 -0500

On 9/19/17 11:59 AM, Ted Hardie wrote:
> Folks asserting that it could not be eliminated from the capability 
> set for JavaScript applications caused me to focus on the latter.

To be fair, it's kind of hard to draw a line around what can't be done 
from JavaScript.

https://bellard.org/jslinux/vm.html?url=https://bellard.org/jslinux/buildroot-x86.cfg

What's under discussion here is level of convenience.

/a

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 20 Sep 2017 17:15:53 +1000

On 20 Sep 2017, at 2:59 am, Ted Hardie <[email-masked]> wrote:
> 
> Howdy,
> 
> I'll try to snip pieces not salient without hindering attribution; hope that helps.

Thanks, doing likewise below. I've tried to manually reconstruct the quoting; apologies if there are errors.

> Can I have JavaScript retrieve a resource like https://dns.initial-origin.example/query-for-dns?www.major-search-engine.example then use the result in place of the browser's DNS routines or the system DNS routines for retrieving https://www.major-search-engine.example/ within that JavaScrit application?

No.

The most you could do -- assuming when you say "JavaScript application" you mean Web page (because JS can be run elsewhere, e.g., NodeJS; what's important is the constraints that the environment put upon it) -- is reuse that result within that page (and thanks to Service Worker, the origin as well, unless other pages opt out of SW), yes you can, today. 

Mind you, there's nothing special about the proposal on the table that makes it easier. 

Also, doing so is pretty tortured for very limited gain; off the top of my head (handwave warning) you'd need to install a SW (or without it, create a bunch of event handlers in the page itself) to intercept requests, do your faux DNS, and then handle the response. This would work for embedded assets (e.g., JS, CSS, images) reasonably well on modern browsers, I think, but once you follow a link to another origin (or page, if SW isn't used and you don't control that page), the "real" DNS used would show up in the location bar, and you'd lose the ability to interfere.

This has been done before, e.g., people doing "live" load balancing / etc. from JS.

>  If that is possible, then I need to know where the DNS data retrieved can be reused and I need to know whether the rendering distinguishes in any way between data so retrieved and data retrieved by a more trusted element.

Outside the context in which it was loaded? Nowhere.

> Does the data end up in the browser's DNS cache? 

From random JS (SW or otherwise) on the Internet? It doesn't. The only way that JS can affect the DNS cache is to request lookups, which uses the configured resolution mechanism, not what the JS asks it to use. I.e., there is no proposal on the table to have a new JS interface 'setDnsResolver()', AFAICT.

If the user configures the browser to use the DOH service, it might indeed cache the results (in the DNS or HTTP caches; probably the former, because perf on the latter is a problem in most browser implementations). 

Security considerations might be needed for the case when a user transitions from DOH to anther resolution mechanism -- but really that's not much different than changing your system DNS resolver.

>  Does a hover over an element show that this URI would be using a JavaScript supplied resolver to retrieve the location should I click?

That's not actually specified behaviour anywhere, last I looked. 

> Interestingly, that's not what I understood others' answer to be.  Their view was that since  https://dns.initial-origin.example/query-for-dns?www.major-search-engine.example  was within the initial-origin, resources from it would be treated as same origin.  If I understood correctly the code that would limit those resources to same origin isn't present and would have to run after the UDP wireformat was parsed (otherwise there are trivial attacks in returning additional data that cache poisons whatever the scope of use turns out to be).

Same origin for the purposes of what? The use case here is really, really ill-defined.

> The goal to use this as a swappable facilitating protocol for DNS resolution led me to that conclusion; in that usage, the resulting DNS data would populate the relevant DNS cache.  Re-using the same system within JavaScript naively would have very bad properties; some segregation to handle the different levels of trust is required.

OK. If I read you correctly, you seem to be assuming that browsers (and other systems?) will somehow automatically handle responses that use a particular media type (or a specific URI scheme, or whatever) with elevated privileges (e.g., inserting them into the browser/OS DNS cache). I don't think this is part of the proposal. If someone has proposed that, please to point to the message so we can engage that idea.

> Should I take it that you disagree with the assertion that if we build for goal 1 (a swappable facilitating protocol) that we have automatically built a mechanism that is callable within a JavaScript application (which, as I understand it, Adam and others believe)?

I think Adam and others believe that you *could* use this protocol from JavaScript (in a Web browser or otherwise) in a limited fashion (as outlined above), in that you would be bound by the security model of the environment you're working within. I don't think that is a major use case for this work, but it is a possible one.

I don't think that anyone wants to establish new Web APIs to allow JavaScript to manipulate the browser/OS DNS resolution process or state. I certainly do not.

Adam et al - If these statements aren't accurate, please say so.

More to the point, the IETF is *not* the appropriate venue to be making core changes to the browser security model; at the very least, if we were doing that, we'd need to be coordinating *very* closely with the Web Application Security WG in the W3C. 

> Would you consider a system in which the local browser or OS tested for the availability of a DOH server at a supplied address within scope (that would be one way to re-use the current DHCP-supplied servers, for example)?

Possibly. "Manual" is probably the wrong word above -- the important part is that it's not under the control of a Web API for browsers. I doubt we'll consider it in-scope to specify other mechanisms (e.g., we don't control POSIX), but a protocol augmentation along those lines *might* be in-scope (although I'd prefer to leave it out; the more we put into this WG, the more chances of getting distracted by shiny things). 

> My concern isn't just that it be out of scope of the charter, its that it either be not in the capability set of the resulting work or well-handled in that context. 

As above, defining this protocol won't change the capability of Web scripting by even the smallest amount. People do what they can today, and those capabilities will be the same after this is defined.

>  Folks asserting that it could not be eliminated from the capability set for JavaScript applications caused me to focus on the latter.  If the work can be constrained such that this does not arise, so much the better.

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

---

From: Ted Hardie <[email-masked]>
Date: Wed, 20 Sep 2017 10:17:37 -0700

Howdy,

Comments in-line, with some snippage to help keep it readable.

On Wed, Sep 20, 2017 at 12:15 AM, Mark Nottingham <[email-masked]> wrote:

> >> Are you supposing some sort of rendezvous system where I can "install"
> a DOH resolver from one origin and have it affect requests sent to another?
> >
> https://dns.initial-origin.example/query-for-dns?www.
> major-search-engine.example then use the result in place of the browser's
> DNS routines or the system DNS routines for retrieving
> https://www.major-search-engine.example/ within that JavaScrit
> application?
>
> No.
>
> The most you could do -- assuming when you say "JavaScript application"
> you mean Web page

Yes, I mean JavaScript application downloaded into a browser.

> (because JS can be run elsewhere, e.g., NodeJS; what's important is the
> constraints that the environment put upon it) -- is reuse that result
> within that page (and thanks to Service Worker, the origin as well, unless
> other pages opt out of SW), yes you can, today.
>
I have to disagree with this.  Standardizing this method should make this
easier by having a common format produced by servers and consumed by
clients.

> Also, doing so is pretty tortured for very limited gain; off the top of my
> head (handwave warning) you'd need to install a SW (or without it, create a
> bunch of event handlers in the page itself) to intercept requests, do your
> faux DNS, and then handle the response. This would work for embedded assets
> (e.g., JS, CSS, images) reasonably well on modern browsers,

So the scope of the problem is:  a malicious piece of JavaScript can embed
a DNS service into a web page such that some resources can be retrieved
using its resolution rather than the browser or system library.  It's not
clear how the user would determine that this was the case, so there is a
risk of mis-attribution within the web page.

That there is no intent to allow that information to be further propagated
is certainly useful to know, but if I understand you (and Adam) correctly,
this problem must be handled somewhere because of the intersection of this
proposal and JavaScript capabilities in a modern browser.

As a charter question, is the description of the problem and/or proposals
around it in scope for this proposed working group, or do we need to pass
th problem to someone else.  If someone else, who?

> OK. If I read you correctly, you seem to be assuming that browsers (and
> other systems?) will somehow automatically handle responses that use a
> particular media type (or a specific URI scheme, or whatever) with elevated
> privileges (e.g., inserting them into the browser/OS DNS cache). I don't
> think this is part of the proposal. If someone has proposed that, please to
> point to the message so we can engage that idea.
>
>
I think you and I agree that if an OS or browser configuration frob
specifies a recursive resolver that uses DOH, that the results go where
ever they would have gone had the same information come in via UDP, TCP,
TLS, or DTLS.  From the information in this email, we agree that taking DNS
responses from a DOH recursive resolver specified in a download JavaScript
application would currently be limited to that application and those from
the same origin (and that building anything to take it further would be
unwise).  There's some work to do on how to handle misattribution within
that context, but it is not the same scope as the OS/browser configured
data.

> I think Adam and others believe that you *could* use this protocol from
> JavaScript (in a Web browser or otherwise) in a limited fashion (as
> outlined above), in that you would be bound by the security model of the
> environment you're working within. I don't think that is a major use case
> for this work, but it is a possible one.
>
> I don't think that anyone wants to establish new Web APIs to allow
> JavaScript to manipulate the browser/OS DNS resolution process or state. I
> certainly do not.
>
> More to the point, the IETF is *not* the appropriate venue to be making
> core changes to the browser security model; at the very least, if we were
> doing that, we'd need to be coordinating *very* closely with the Web
> Application Security WG in the W3C.
>
> Should we be passing the charter by the Web Application Security WG in the
W3C now for comments?

> As above, defining this protocol won't change the capability of Web
> scripting by even the smallest amount. People do what they can today, and
> those capabilities will be the same after this is defined.
>
>
It will change the relationship of that Web scripting capability with the
DNS (or at least make that relationship much easier).  Given where the DNS
is in our stack, that's an important change.  If an attacker can take
information from an origin and have it treated as DNS data, it become the
foundation of retrievals from other origins.

To hideously over-simplify, the same origin security model presumes that
resources from an origin share a scope.  But if the origin is a recursive
resolver among other capabilities, the resources retrieved may provide data
about where to get other resources from outside that scope.

As long as there no APIs which push that data past the same origin
boundary, the problem with that is limited to misattribution within the
same origin.  But it is still a problem because of the role DNS info plays.

> >  Folks asserting that it could not be eliminated from the capability set
> for JavaScript applications caused me to focus on the latter.  If the work
> can be constrained such that this does not arise, so much the better.
>
> 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.
>
> Agreed, and I think this a very valuable piece of work to get done,
especially for the multiplexing properties of H2 or QUIC.

> 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.
>
>
While this is no doubt unintended, this tends to give a "everything is
already ruined" flavor to your response.  If we're standardizing this, I
think we need to take how this data is integrated and presented as part of
the overall deployment problem. If we're not the right folks to do that
part of the work, I think we need to get the right folks involved as soon
as possible and to put coordination with that community into the charter
along with DNSOP and the others already listed.

3. Future handwavy things like making DNS updates over HTTP -- very
> ill-defined and not important for this discussion
>
>
Yeah, I can't even tell from this whether you mean clients updating their
info a la DNS dynamic update  a la RFC 3007 or you mean push style updates
of fresh responses from a recursive resolver.  You can certainly leave the
first out.  Whether you can leave the second out or not depends on an
interaction between the HTTP caching model and the DNS caching model (That
is, if a configured DOH server pushes a new response to a query that hasn't
been asked yet, it would go into the HTTP cache in anticipation of the
question being asked.  When, though, that would get parsed and turned into
DNS data isn't clear to me.)

regards,

Ted

---

From: Adam Roach <[email-masked]>
Date: Wed, 20 Sep 2017 12:24:57 -0500

On 9/20/17 12:17, Ted Hardie wrote:
> That there is no intent to allow that information to be further 
> propagated is certainly useful to know, but if I understand you (and 
> Adam) correctly, this problem must be handled somewhere because of the 
> intersection of this proposal and JavaScript capabilities in a modern 
> browser. 

This can be done with or without any work in the IETF. If the hack mnot 
describes is possible[1], then having a standardized format for 
launching such queries (rather than doing the *exact* same thing in a 
proprietary syntax) neither helps nor hinders the attack.

That said, I want to stress quite heavily that I don't think this kind 
of attack is possible due to the scoping rules around which resources a 
service worker is allowed to handle.

/a

____
[1] I'm extremely dubious that this could be pulled off even for normal 
resources; for HTTPS-secured resources, replacing the host with the 
result of DNS resolution would cause cert validation to fail, so it 
definitely can't be mounted there.

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 21 Sep 2017 08:27:57 +1000

On 21 Sep 2017, at 3:17 am, Ted Hardie <[email-masked]> wrote:
> I have to disagree with this.  Standardizing this method should make this easier by having a common format produced by servers and consumed by clients.  

In the case you're concerned about -- hostile JS -- the server that hosts the malicious JS is the same party that produces the poisoned DNS response. Even if it's cross-origin, the attack implies that they're coordinating. Defining the wire format for those messages is trivial; I suppose we're doing a small amount of work for them, but that work isn't any barrier to the attack.

> So the scope of the problem is:  a malicious piece of JavaScript can embed a DNS service into a web page such that some resources can be retrieved using its resolution rather than the browser or system library.

No. The scope of the problem is that once someone malicious has Javascript executing within a context, it's effectively game over for that context. Much of the focus of Web Application Security over the last few years has been on reducing that attack surface, especially where it's not intentional (e.g., CSP). 

Again, there is no magical way for JavaScript to plug itself into the system DNS library. There *is* a magical way for JavaScript to monkey patch pretty much anything within the page load -- that's what we're talking about here. What this WG does doesn't affect that ability, even on the margins; it's already there.

>  It's not clear how the user would determine that this was the case, so there is a risk of mis-attribution within the web page.  

This is a pre-existing risk, and browser vendors, the WHATWG and W3C have spend significant time considering and mitigating it (in a nutshell, only trust the browser chrome, which is *not* under the control of JS). We do not own this problem.

> That there is no intent to allow that information to be further propagated is certainly useful to know, but if I understand you (and Adam) correctly, this problem must be handled somewhere because of the intersection of this proposal and JavaScript capabilities in a modern browser.  

It's already handled.

> As a charter question, is the description of the problem and/or proposals around it in scope for this proposed working group, or do we need to pass th problem to someone else.  If someone else, who?

It's not in-scope here, and since it's already handled, we don't need to pass it anywhere else.

> I think you and I agree that if an OS or browser configuration frob specifies a recursive resolver that uses DOH, that the results go where ever they would have gone had the same information come in via UDP, TCP, TLS, or DTLS.

Yes, provided it was from the same source.

> From the information in this email, we agree that taking DNS responses from a DOH recursive resolver specified in a download JavaScript application would currently be limited to that application and those from the same origin (and that building anything to take it further would be unwise).

Where 'context' is defined by the Web security model (which, like DNS, is specified a bit all-over-the-place, but still works somehow) -- yes.

>  There's some work to do on how to handle misattribution within that context, but it is not the same scope as the OS/browser configured data.

I strongly disagree that there's work to do -- this is already within the existing security model of the Web platform. 

> Should we be passing the charter by the Web Application Security WG in the W3C now for comments?

If that would help us move along, sure.

> It will change the relationship of that Web scripting capability with the DNS (or at least make that relationship much easier).  Given where the DNS is in our stack, that's an important change.  If an attacker can take information from an origin and have it treated as DNS data, it become the foundation of retrievals from other origins.
> 
> To hideously over-simplify, the same origin security model presumes that resources from an origin share a scope.  But if the origin is a recursive resolver among other capabilities, the resources retrieved may provide data about where to get other resources from outside that scope.  
> 
> As long as there no APIs which push that data past the same origin boundary, the problem with that is limited to misattribution within the same origin.  But it is still a problem because of the role DNS info plays.

Right, but this is already possible today, and easy for someone to implement, because the Web allows you to create little protocols between JS and the server on-the-fly.

> While this is no doubt unintended, this tends to give a "everything is already ruined" flavor to your response.

That indeed wasn't intentional; the Web still works pretty well, although I wouldn't bet on the long-term stability of the hair colour of any given Web security professional.

>  If we're standardizing this, I think we need to take how this data is integrated and presented as part of the overall deployment problem. If we're not the right folks to do that part of the work, I think we need to get the right folks involved as soon as possible and to put coordination with that community into the charter along with DNSOP and the others already listed.

Imagine we're charting a working group for a financial data format -- it's important that it has integrity and authority, and it's a target for attackers, as are DNS records. The position you're taking seems to be (roughly) that we need to make sure that people don't use the standard financial data format to misrepresent other people's finances in the case that there's a malicious piece of JS on a Web page. 

Without trivialising that attack, having a defined format for the data doesn't change its nature (and remember, we're not even really defining a format; the current proposal is to reuse an existing format in HTTP messages), and (again) we lack the expertise and authority in this area.

I'm fine if we feel we need to confirm this with WebAppSec or other parties before chartering. Beyond that, IMO adding any tasks to the WG's plate to address it is a poor use of the IETF's resources.

---

From: Adam Roach <[email-masked]>
Date: Wed, 20 Sep 2017 17:54:09 -0500

The dichotomy you lay out doesn't make sense because HTTP already has a 
well-defined security model. As it stands, HTTPS  implies the use of 
trusted public roots, and CAB Forum Baseline Requirements section 9.2.1 
forbids the issuance of a cert for IP addresses. One of the things that 
is appealing about HTTPS as a substrate (for better or worse) is that it 
has a well-defined and proven scalable system for the kind of security 
issues you describe below.

The issue with putting discovery in this charter is that it's the wrong 
community of interest and expertise for what you propose. I would 
imagine that this is the same reason that RFC3315bis is being done in 
DHC rather than V6OPS (although -- full disclosure -- that decision is a 
bit outside of what I tend to track).

/a

On 9/20/17 10:14 AM, Toerless Eckert wrote:
> On Fri, Sep 15, 2017 at 08:44:53AM -0700, The IESG wrote:
> [...]
> I disagree on this becoming a working group unless the charter says either:
>
> a) Discovery is in scope
>
> I have no specific preferences of what discovery is done, i just
> think that the security discussion needs to take the discovery being used
> into account. I can already see how DoH clients will just use some
> configured IP address for the DoH server and accept whatever self-signed
> TLS certs are being offered. And the industry thinks its great security
> improvement because it uses TLS. I am sure there are enough people willing
> to work on DoH that would be able to write down how to do that discovery piece
> more securely, so why stop them doing it by writing "out of charter".
>
> or
>
> b) Security is optional. The documents will sprinkle some security fairy
> dust in by mandating simple buzzwords like TLS Vmax so we can escape further
> security discussions.
>
> ;-)
>
> Cheers
>      Toerless
>

---

From: Adam Roach <[email-masked]>
Date: Wed, 20 Sep 2017 18:39:47 -0500

Correction -- it was flagged to me that I read the BR text too quickly; 
the prohibition here is against RFC 1918 IP addresses, not IP addresses 
in general. The general notion stands, however, that cert holders of IP 
address certs need to first demonstrate control of that address to 
obtain the cert in the same way as certs that refer to names.

/a

On 9/20/17 5:54 PM, Adam Roach wrote:
> The dichotomy you lay out doesn't make sense because HTTP already has 
> a well-defined security model. As it stands, HTTPS  implies the use of 
> trusted public roots, and CAB Forum Baseline Requirements section 
> 9.2.1 forbids the issuance of a cert for IP addresses. One of the 
> things that is appealing about HTTPS as a substrate (for better or 
> worse) is that it has a well-defined and proven scalable system for 
> the kind of security issues you describe below.
>
> The issue with putting discovery in this charter is that it's the 
> wrong community of interest and expertise for what you propose. I 
> would imagine that this is the same reason that RFC3315bis is being 
> done in DHC rather than V6OPS (although -- full disclosure -- that 
> decision is a bit outside of what I tend to track).
>
> /a
>
> _______________________________________________
> Doh mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/doh

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 20 Sep 2017 22:56:43 -0400

Replying to many threads.

1) I am glad to hear that it is agreed that any WG in this area will 'be a
marathon'. This is an important problem and it needs to be done right. And
that means discussing the set of use cases to be addressed, developing
requirements and only then looking at solutions. Do it right or not at all.

2) WS-* did too achieve its principal goal of making work for consultants.
It looked promising at first and then...

3) We might well want to delay a decision on this issue until after the IAB
ename workshop which might well lead to a game changer.

4) I agree with Mark Nottingham that this is an API thing and that IETF
does not own the specs where the key APIs are defined. That is WebAPIs for
JS (W3C) and POSIX.

But here is the thing, if IETF says a DNS interface should look like X then
by golly, I bet W3C and POSIX etc. will be only too happy to follow the
lead. And the strange thing is that IETF has already got a DNS Interface
which is really, really good and not the ones I proposed:

https://tools.ietf.org/html/rfc6763

It has Apple's name on the spec so there is one major platform on board.
And it is 2013 and supported by quite a bit of running code. The only real
problem with the spec is that it is presented as 'one option' on how to do
service discovery.

Please, do not give me six ways to do a thing, give me one. And do not let
application developers choose either. Pick one method that serves all the
requirements and tell people to stick to it unless there is reason not to.
Standards are all about taking away choices that don't matter. Have six
ways to implement service discovery and I have to implement whichever one
is picked for a protocol myself. Pick just one as the default and it will
be there for me in a library.

Yes, we can grandfather legacy protocols like HTTP and SMTP. But lets not
force everyone to implement everything.

The only problem I have with RFC6763 is that the power of the idea had to
be hidden to get through process. This draft takes the ideas in RFC6763 and
takes them to their logical conclusion:

http://prismproof.org/Documents/draft-hallambaker-json-web-service.html

In short, what I think the Javascript, C, C# API for service discovery
should look like is:

Connection = Interface.GetService (<address>, <protocol>)

for example:

Connection = Interface.GetService ("example.com", "_http._tcp")

That is it. I want all the extraneous stuff to go away or be hidden as
options. It should be possible for the DNS records to force use of a
security enhancement (e.g. a specific version of TLS with specific trust
anchor)

That API could be implemented using existing DNS protocol at the client
certainly. The incentive to change the client-resolver protocol would be
motivated by latency, not by functionality. The big problem with DNS is
that the protocol is only reliable for one request and one response and
even if you could do multiple requests in one packet, the discovery
mechanisms are more complex and inherently require multiple round trips.

---

From: Eliot Lear <[email-masked]>
Date: Thu, 21 Sep 2017 09:02:41 +0200

Hi,

> decision is a bit outside of what I tend to track).

The IETF has provenance over the DNS standards, and that ought not be so
quickly relinquished.  That includes discovery, which we have covered in
the past through mechanisms such as DHCP and RA.  We needn't be the only
ones to speak on the subject nor need there be only a single method
defined within IETF, but not speaking about it at all runs the risk of
creating a massive mess for enterprise deployments, because if the wrong
resolver is discovered, any number of functions commonly used in
enterprises will break, not the least of which would be malware
detection.  Perhaps enterprises could put up with that if they knew how
to regain the capability, and that ties back to discovery (and scoping).

Within the IETF, because the group isn't formed, you can't say whether
or not you have the correct community of interest engaged to do any of
the work because you have bypassed the BoF process that asks important
questions.  In fact, in this thread, apart from two people (myself and
PHB), I'm not sure ANYONE outside the author or the IESG and IAB has
actually stood up and said they're interested in this work.  But even
putting that aside, because you haven't held a BoF, you don't really
know whether or not you will have the right people in the room to handle
discovery.  And people are having trouble answering THAT question
because the goal is not clear (although mnot seems to have some notions
which sound ok).

What bothers me about this discussion is that adding a DHCP option is
not difficult, and the current operating model of the dhcp working group
is that they don't do options, but leave that to other wgs.  And so you
are creating a vacuum for this possibility through the exclusion clause
in the charter.

I am**not saying that the work has to be done all at once, by the way,
or in one document.  The discussion on the IETF list demonstrates, if
nothing else, that at least one clear theory of operation should also be
documented.

Eliot

---

From: Adam Roach <[email-masked]>
Date: Thu, 21 Sep 2017 02:45:34 -0500

On 9/21/17 2:02 AM, Eliot Lear wrote:
> In fact, in this thread, apart from two people (myself and PHB), I'm 
> not sure ANYONE outside the author or the IESG and IAB has actually 
> stood up and said they're interested in this work.

Quoting the DISPATCH minutes for IETF 99:

> Alexey: Art ADs will talk to Int and Sec ADs about dprive. Don't have an
> answer now. It's clear there is some interest. Need to find a place for it.
>
> Cullen: show of hands willing to read drafts and do work. Wow - tons.

/a

---

From: Ask Bjørn Hansen <[email-masked]>
Date: Thu, 21 Sep 2017 01:34:14 -0700

> On Sep 16, 2017, at 9:07, Phillip Hallam-Baker <[email-masked]> wrote:
> 
> 1) I see no evidence that HTTP/2 is suited to Web Services or will be dominant in that role. HTTP/2 was designed to serve Web Browsing to the exclusion of all other concerns. Which was the right choice to make.

HTTP/2 is also better for services with many small requests, in particular on high latency connections (or where each response might be slow to start…).

Ask

---

From: Ask Bjørn Hansen <[email-masked]>
Date: Thu, 21 Sep 2017 01:35:09 -0700

I find it curious that much of the debate has been about a particular “DNS consumer” use case; I think dns-over-http can do more (and as was pointed out, application APIs seem a bit out of scope).

If you think of the DNS “flow” as

     consumer — client — resolver server — auth

(just to make my example above clearer; in case I am mixing up the proper terms used here, another example):

    application — OS stub resolver — [network] — bind/powerdns resolver/… — bind/nsd/powerdns auth/…

While I’d like access to lower level DNS information in browser javascript as much as everyone else, limiting “doh” as just a facility to bypass the OS resolver (and maybe the resolver server) seems a bit limited. I think the target should be something that could (eventually) be used in the rest of the “flow”, too.

From the dnsoverhttp group last November:

> On Nov 22, 2016, at 20:47, Shane Kerr <[email-masked]> wrote:
> 
> One thing that really stuck with me at the dnsoverhttp bar-BoF was when someone said that DNS is adopting features that look like HTTP (DNS sessions handling, DNS RR server-side push, etc.), and that HTTP is adopting features that look like DNS (sending certificate chains, providing address information, etc.).

The someone was me.

My thought is that if we’re changing the DNS protocol (or adding another…) there might be a big practical advantage in building on the huge implementation investments being made in QUIC.

The “value” in DNS is the delegation and data model, not the current “bits on the wire” protocol. For future features (privacy, encryption between resolvers and auth, etc) maybe a different protocol would be appropriate.

(Still quoting Shane)
> I wonder if our models are starting to break down? Having two protocols
> with seemingly very little in common adopting the same features kind of
> implies that our abstractions are broken, right?

It is (eventually) working out for IPv6! :-)

Ask

---

From: Adam Roach <[email-masked]>
Date: Thu, 21 Sep 2017 03:57:19 -0500

On 9/21/17 3:35 AM, Ask Bjørn Hansen wrote:
> While I’d like access to lower level DNS information in browser javascript as much as everyone else, limiting “doh” as just a facility to bypass the OS resolver (and maybe the resolver server) seems a bit limited.

I think the conversation has perhaps become side-tracked by an example I 
used for pedagogical purposes. If you look at the text in the charter 
and the text in the named input document, the limitation you posit isn't 
present.

/a

---

From: Eliot Lear <[email-masked]>
Date: Thu, 21 Sep 2017 11:28:48 +0200

You still don't have a reasonable answer for discovery.

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 21 Sep 2017 21:41:02 +1000

> You still don't have a reasonable answer for discovery.

Discovery isn't necessary for the primary use case -- user-driven configuration of their browser.

We can specify a DHCP option, but since it won't have any qualitative benefits over "normal" DHCP-configured DNS, I suspect it will get almost no implementation or deployment. So it's effectively busy work for the WG.

---

From: Eliot Lear <[email-masked]>
Date: Thu, 21 Sep 2017 13:56:37 +0200

Mark,

I'll stop after this message.  Please see below:

Earlier you wrote:

> The use case that I believe most have in mind is "as a user, I want to configure my [browser, OS] to use *this* DOH service for DNS resolution" -- where that configuration is manual; e.g., a configuration textbox or dropdown in the browser, or a file in /etc.

Please get your story straight.  Bypassing enterprise DNS entails all
the risks I previously mentioned.  No one here as mentioned a means to
mitigate those risks.  The only way I can think of is by tying this
function into the OS and using the existing discovery mechanisms.  But
if all you've got as a browser, everything looks like Javascript, I suppose.

Eliot

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 21 Sep 2017 14:12:47 +0200

Hi,

The issue with this charter I have is that unless you specify one or 
several usages one can't evaluate or write security considerations or 
even discuss the actual security properties of the resulting component. 
Or rather the statement you can do is very limited. And I think the 
below quote from the charter is quite misleading, even if accurate.

Den 2017-09-15 kl. 17:44, skrev The IESG:
> The use of HTTPS

So, yes HTTPS will provide two properties. The DNS data provided are 
from the "entity" given by Server's cert, and it is provided 
confidentiality and integrity protected between that server and my 
client. However, without discussing a particular usage of this format, 
the system security properties and especially what trust I can place in 
the data as well as what privacy that is provided is unknown.

Just to show how strange this can be lets compare two different usages 
with quite different properties are present.

1. After having connected to a web site, the web application uses its 
own servers to resolve the DNS information for resources the client side 
application needs by submitting those resolve requests to the same 
origin server. In this case we keep the usage within the same trust 
domain. The distributed web application uses the mechanism internally 
with resolvers that it is configured to be trusted. Each web service has 
its own resolver and the DNS resolution is internal and separated 
between applications.

2. Using some autoconf setting, the free WIFI access point at Joe's 
Coffe announces a DNS over HTTPS stub resolver. The only difference from 
current DHCP DNS server setting is that the communication between the 
client and resolver at the gateway is that communication is secured, 
thus preventing active and passive attacks from other entities in the 
same WIFI/LAN. But otherwise the trust possible in responses from the 
resolver has not changed. Nor has the privacy aspects in respect to the 
infrastructure and what happens upstream of the LAN gateway.

I am quite worried that by simply defining a format and not discuss how 
it will be used, people will lock on to those three words from the 
charter: "integrity and confidentiality" and think this resolves everything.

Also which "old" use cases that is really intended to cover and by which 
entities are really not clear. As "new use cases" are ruled out of 
scope. So, is the browser contacting an recursive resolver without going 
through OS a new or an OLD use case?

I really want more clarity on what the WG really should do as its first 
steps and what usage considerations it needs to write!

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Media Technologies, Ericsson Research
----------------------------------------------------------------------
Ericsson AB                 | Phone  +46 10 7148287
Torshamnsgatan 23           | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: [email-masked]
----------------------------------------------------------------------

---

From: Ted Hardie <[email-masked]>
Date: Thu, 21 Sep 2017 07:05:10 -0700

On Thu, Sep 21, 2017 at 4:41 AM, Mark Nottingham <[email-masked]> wrote:

> We can specify a DHCP option, but since it won't have any qualitative
> benefits over "normal" DHCP-configured DNS, I suspect it will get almost no
> implementation or deployment. So it's effectively busy work for the WG.
>
>
I think you're underestimating the value of a switch to a multiplexing
facilitating protocol/transport.  Once this has gotten its legs under it, I
suspect that this approach for connecting to caching resolver will perform
better than any of traditional upd/tcp connections or the tls/dtls
approaches DPRIVE created.

And there is some discussion on that to be done, especially around whether
you can re-use the current DHCP option (since it does not specify a port)
and try this opportunistically or you should use a new option.

Just my view, of course,

Ted

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 21 Sep 2017 13:40:59 -0400

On Thu, Sep 21, 2017 at 4:34 AM, Ask Bjørn Hansen <[email-masked]>
wrote:

> HTTP/2 is also better for services with many small requests, in particular
> on high latency connections (or where each response might be slow to
> start…).
>

​If Web Services actually used HTTP features other than Firewall bypass and
framing of transactions, then HTTP/2 might be attractive. ​Given how little
of the HTTP stack is used and given that QUIC is a much closer match, that
is the route I want to take.

I think it likely QUIC will eat up COAP as well.

Just think of QUIC a way of doing TCP/2 in a way that is compatible with
the protocol stacks as deployed in the field. At some point there will be a
way to specify the service endpoint in a consistent fashion.

---

From: Mark Nottingham <[email-masked]>
Date: Fri, 22 Sep 2017 11:07:38 +1000

I suppose, although it would be good to understand if perf problems to a dhcp configured resolver are widely encountered. 

I wouldn’t be against text in the charter that allows the wg to consider mirroring currently defined (by the ietf) dns discovery mechanisms. I’d be against definition of new ones. 

Sent from my iPhone

> On 22 Sep 2017, at 3:40 am, Phillip Hallam-Baker <[email-masked]> wrote:
> 
> 
>> On Thu, Sep 21, 2017 at 4:34 AM, Ask Bjørn Hansen <[email-masked]> wrote:
>> 
>> 
> ​If Web Services actually used HTTP features other than Firewall bypass and framing of transactions, then HTTP/2 might be attractive. ​Given how little of the HTTP stack is used and given that QUIC is a much closer match, that is the route I want to take.
> 
> Just think of QUIC a way of doing TCP/2 in a way that is compatible with the protocol stacks as deployed in the field. At some point there will be a way to specify the service endpoint in a consistent fashion.
> 
>

---

From: Eliot Lear <[email-masked]>
Date: Fri, 22 Sep 2017 07:03:58 +0200

Hi,

On 9/22/17 3:07 AM, Mark Nottingham wrote:
> I suppose, although it would be good to understand if perf problems to
> a dhcp configured resolver are widely encountered. 
>
> I wouldn’t be against text in the charter that allows the wg to
> consider mirroring currently defined (by the ietf) dns discovery
> mechanisms. I’d be against definition of new ones.

I know I wrote my last message would be my last, but I thought it would
be useful to indicate that the above would be fine with me.

Eliot

---

From: Toerless Eckert <[email-masked]>
Date: Wed, 20 Sep 2017 17:14:59 +0200

a) Discovery is in scope

or

;-)

Cheers
    Toerless

---

From: Toerless Eckert <[email-masked]>
Date: Thu, 21 Sep 2017 01:50:31 +0200

Thanks, Adam

Your first paragraph is looking to me like a stub of the explanation
that i am looking for. Eg: The DoH server MUST include a domain name,
which then allows you to validate the certificate in the same way
against public root as any other domain names, etc. pp.
You still need some resolution from that domain name to IP address which
may not be DNS, but it would not have a security impact anymore. Thats
whats called the resolution and may be out of charter ?
Did this capture the essence ?

How about the issues known from browsers with public roots. Good enough tom
make DoH consistent with the issues your browser already has ?

Cheers
    Toerless

On Wed, Sep 20, 2017 at 05:54:09PM -0500, Adam Roach wrote:
> The dichotomy you lay out doesn't make sense because HTTP already
> has a well-defined security model. As it stands, HTTPS  implies the
> use of trusted public roots, and CAB Forum Baseline Requirements
> section 9.2.1 forbids the issuance of a cert for IP addresses. One
> of the things that is appealing about HTTPS as a substrate (for
> better or worse) is that it has a well-defined and proven scalable
> system for the kind of security issues you describe below.
> 

-- 
---
[email-masked]

---

From: Toerless Eckert <[email-masked]>
Date: Thu, 21 Sep 2017 01:51:50 +0200

Whow, that sounds grizzly for dynamically allocated IP addresses on broadband links.

On Wed, Sep 20, 2017 at 06:39:47PM -0500, Adam Roach wrote:
> Correction -- it was flagged to me that I read the BR text too
> quickly; the prohibition here is against RFC 1918 IP addresses, not
> IP addresses in general. The general notion stands, however, that
> cert holders of IP address certs need to first demonstrate control
> of that address to obtain the cert in the same way as certs that
> refer to names.
> 
> /a
> 
> >has a well-defined security model. As it stands, HTTPS  implies
> >the use of trusted public roots, and CAB Forum Baseline
> >Requirements section 9.2.1 forbids the issuance of a cert for IP
> >addresses. One of the things that is appealing about HTTPS as a
> >substrate (for better or worse) is that it has a well-defined and
> >proven scalable system for the kind of security issues you
> >describe below.
> >
> >would imagine that this is the same reason that RFC3315bis is
> >being done in DHC rather than V6OPS (although -- full disclosure
> >-- that decision is a bit outside of what I tend to track).
> >
> >/a
> >

-- 
---
[email-masked]

---

From: Tony Finch <[email-masked]>
Date: Fri, 22 Sep 2017 13:12:48 +0100

> approaches DPRIVE created.

DNS over TCP already supports out-of-order responses. The reason it has
historically not performed very well is that server implementations have
handled queries on a TCP connection serially rather than concurrently.

But this is improving. BIND 9.11 (for example) supports concurrent queries
with out-of-order responses over TCP and TCP fast open, so queries over
TCP should perform well, and better than UDP for large responses.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/  -  I xn--zr8h punycode
Faeroes, Southeast Iceland: Southeasterly 4 or 5, increasing 6 to gale 8
later. Moderate or rough, occasionally very rough later. Showers, rain later.
Good, becoming moderate or poor later.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 22 Sep 2017 12:00:43 -0400

On Thu, Sep 21, 2017 at 9:07 PM, Mark Nottingham <[email-masked]> wrote:

> I suppose, although it would be good to understand if perf problems to a
> dhcp configured resolver are widely encountered.
>
> I wouldn’t be against text in the charter that allows the wg to consider
> mirroring currently defined (by the ietf) dns discovery mechanisms. I’d be
> against definition of new ones.
>

​+1

​I think that everyone really needs to take a look at this spec:
https://tools.ietf.org/html/rfc6763. It is not the best description of a
general DNS discovery mechanism because it was not allowed to be presented
as such. It had to be couched as an 'option'.

The DNS folk think that the answer to every problem is a new RR and they
are oblivious to the fact that the DNS protocol does not allow that. Even
if you can populate the records into the DNS your provider uses, the fact
that you can only query for one record at a time or for all records makes
use of multiple RRs for discovery unworkable.

What I would like to see is 'take RFC6763 as the starting point and define
a common set of tags for use in TXT'​

---

From: Patrick McManus <[email-masked]>
Date: Fri, 22 Sep 2017 12:36:58 -0400

On Fri, Sep 22, 2017 at 12:24 PM, Warren Kumari <[email-masked]> wrote:

>
> Yup -- RFC7766, S6.2.1.1 says you should do this, as does RFC7858
> ("Specification for DNS over Transport Layer Security (TLS)").
>
> double yup. https >=h2 offers a couple, really minor in the grand scheme
of things, similar advantages beyond that too. One is a rather seamless (no
additional specification necessary) upgrade to httpOverQuic when that
happens which will help with the tcp level in-order suboptimality.. the
other is multiplexing within any partial response (as opposed to just
reordering whole responses) that is blocking the wire (slow to generate
additional records, or big things like axfr..). They're just nice to haves
but they should help with the tail cases.

>
> DPRIVE solves much of this, but one weakness is that it is still
> clearly DNS traffic.

yep.

---

From: Eliot Lear <[email-masked]>
Date: Fri, 22 Sep 2017 19:23:27 +0200

Hi Warren,

Just a point of information:

On 9/22/17 6:24 PM, Warren Kumari wrote:
> Unfortunately you cannot separate case 1 from case 2 -- if you make it
> something that enterprise folk can detect / block (on BYOD devices)
> then you have provided that facility to everyone.

Good guys generally have an existing security association with the
device (if a bad guy has a security association with the box, we call it
0wn3d).

Eliot

---

From: Warren Kumari <[email-masked]>
Date: Fri, 22 Sep 2017 12:24:02 -0400

So, these are only my personal views / no hats / etc, but to my mind
one of the main reasons that I'd like to see Doh! succeed is for
censorship resistance (in parallel with the dprive work).
Currently plain-text DNS leaks a huge amount of privacy information;
DPRIVE solves much of this, but one weakness is that it is still
clearly DNS traffic[0]. This allows bad, evil, no-good totalitarian
regimes to block it and force you to use resolvers under their control
and so can control what you can reach, or watch where you are going
and send the secret police to "re-educate" you if you are looking at
things you shouldn't be.
.
.
Now, reread the previous sentence with s/ bad, evil, no-good
totalitarian regimes / friendly corporate IT folk / and s/ the secret
police / human resources /.
This allows friendly corporate IT folk to block it and force you to
use resolvers which they control and so can contol what you can reach,
or watch where you are going and send human resources to re-educate
you if you are looking at things you shouldn't be.

This is (I believe) what Elliot was pointing out -- this is important
information for enterprises - it is used to limit liability, ensure
employees are not "wasting time", and corporate security to detect
that they need to re-image Bob's machine *again* because he persists
in clicking questionable links and installing random bits of malware.

Unfortunately you cannot separate case 1 from case 2 -- if you make it
something that enterprise folk can detect / block (on BYOD devices)
then you have provided that facility to everyone. I believe that this
is simply the "encryption should be outlawed / backdoored because it
helps <insert bad guy here>." argument in another guise[1].

If Doh! is done right in my view it should be indistinguishable from
other web traffic and / or the collateral damage from blocking it
would be (hopefully!) politically untenable.

W
[0]: either because it is using the domain-s ports (853) or through
fingerprinting / heuristics of the TLS stream if you do something like
just run it over port 443.
[1]: luckily this isn't at all controversial, and isn't going to suck
this thread down another rat-hole.

-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf

---

From: Warren Kumari <[email-masked]>
Date: Fri, 22 Sep 2017 15:47:39 -0400

> device (if a bad guy has a security association with the box, we call it

Yes, and no (and why I specified BYOD) -- a number of enterprises
allow employees to bring in personal phones / tablets / computers and
use them on the corporate network... without requiring that they
install a profile / place the devices under management -- I've lost
the reference (I'd thought it was off the BYOD wikipedia page), but
the number of organizations doing this was scary (to me!). Now,
perhaps these same organizations don't currently monitor their
employee usage through DNS...

W

---

From: Martin Thomson <[email-masked]>
Date: Mon, 25 Sep 2017 20:24:25 +1000

(I apologize for not reading all 62 messages in this thread first
before replying.  Damned vacations.)

On Sat, Sep 16, 2017 at 2:44 AM, Ted Hardie <[email-masked]> wrote:
> deployments it already means that).

I think that this is not just fine, but correct.  I would object to a change.

We should target HTTP, not a specific version of it.

> While the working group may, of course, change that to
> support HTTP 1.1 and/or QUIC, it might be useful for the charter to indicate
> which of these is potentially in scope.

I would assume, from the title, that it does not matter which of these
protocols is used, therefore the HTTP working group is the primary
point of collaboration.

> If the community is sure now that
> HTTP over QUIC is in scope, for example, having that noted in the charter by
> adding the QUIC working group to list of working groups to consult would be
> useful.

If the QUIC working group produces something that is incapable of
carrying HTTP semantics, then they have failed.  Badly.

Similarly, if this proposed working group produces a protocol that
relies on semantics of a particular version of HTTP such that it
cannot be used with QUIC, then they too have failed.

I don't see any need to consult with QUIC specifically.  I predict
that we can use informal channels, since many of the same people will
be in the two rooms.

> [...] The working group could, of course,
> change that, but it would seriously shift the direction of its input
> document to do so).

If we do that, then we are not meeting the charter as stated.

>>   Apr 2018 - [...]

It was originally Dec 2017, so this is about 3 times as long.

---

From: Adam Roach <[email-masked]>
Date: Mon, 25 Sep 2017 17:56:05 -0500

Thanks to everyone who commented on the proposed charter for 
DNS-over-HTTPS. I have noted four main categories of discussion:

 1. Whether to rule specific versions of HTTP in or out of scope of the
    charter.  While the consensus here was rough, there were more
    proponents of leaving the version out than baking it in. I further
    observe that leaving version out of the charter does not preclude
    the WG from reaching consensus that requires or precludes certain
    versions from being used.

 2. Discovery of DNS-over-HTTPS servers. Again, consensus was rough, but
    I find slightly more people in favor of allowing discovery than
    those opposed to its inclusion. I will be adding language to the
    charter proposal that allows such work if those parties interested
    in specifying such mechanisms show up in the working group. If no
    such critical mass shows up, the WG will be allowed to close without
    performing such specification.

 3. Scope of work: whether DNS-over-HTTPS servers are accessed normal
    stub resolver libraries or via JavaScript. The proposed charter now
    contains text clarifying that the JavaScript use case is not the
    primary motivation, but that the WG will not take steps to preclude it.

 4. Regarding the question of whether to perform the work at all (or
    whether to perform the work now): the analysis for starting a
    working group generally hinges on whether a viable group of willing
    and capable participants exists to complete such work, without
    regard to those who wish the work not to take place. While
    exceptions to this generality may certainly exist, I find no reason
    the proposed working group is special in this dimension.

The revised version of the proposed charter can now be found at:

https://datatracker.ietf.org/doc/charter-ietf-doh/

/a

---

From: Ted Hardie <[email-masked]>
Date: Mon, 25 Sep 2017 16:03:00 -0700

Adam,

Thanks for summarizing the discussion and its outcomes.  Looking at the
revised charter, I noticed that it currently says "The use of HTTPS and its
existing PKI provides integrity and confidentiality, and it also allows the
transport to interoperate with common HTTPS infrastructure and policy."
The choice not to specify a particular version means that there may be more
than one transport.  You may wish to rephrase this or elide it to reflect
the decision taken on that point.

regards,

Ted

On Mon, Sep 25, 2017 at 3:56 PM, Adam Roach <[email-masked]> wrote:

>    charter.  While the consensus here was rough, there were more proponents of
>    leaving the version out than baking it in. I further observe that leaving
>    version out of the charter does not preclude the WG from reaching consensus
>    that requires or precludes certain versions from being used.
>
>    2. Discovery of DNS-over-HTTPS servers. Again, consensus was rough,
>    but I find slightly more people in favor of allowing discovery than those
>    opposed to its inclusion. I will be adding language to the charter proposal
>    that allows such work if those parties interested in specifying such
>    mechanisms show up in the working group. If no such critical mass shows up,
>    the WG will be allowed to close without performing such specification.
>
>    contains text clarifying that the JavaScript use case is not the primary
>    motivation, but that the WG will not take steps to preclude it.
>
>    whether to perform the work now): the analysis for starting a working group
>    generally hinges on whether a viable group of willing and capable
>    participants exists to complete such work, without regard to those who wish
>    the work not to take place. While exceptions to this generality may
>    certainly exist, I find no reason the proposed working group is special in
>    this dimension.
>

---

From: Adam Roach <[email-masked]>
Date: Mon, 25 Sep 2017 18:11:53 -0500

On 9/25/17 6:03 PM, Ted Hardie wrote:
> Thanks for summarizing the discussion and its outcomes.  Looking at 
> the revised charter, I noticed that it currently says "The use of 
> HTTPS and its existing PKI provides integrity and confidentiality, and 
> it also allows the transport to interoperate with common HTTPS 
> infrastructure and policy."  The choice not to specify a particular 
> version means that there may be more than one transport.  You may wish 
> to rephrase this or elide it to reflect the decision taken on that point.

Thanks. I've tweaked it to read: "...and it also allows interoperation 
with common HTTPS infrastructure and policy."

/a

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 26 Sep 2017 00:16:26 +0100

A nit, a question and a comment:

> transport to interoperate with common HTTPS infrastructure and policy."

Nit: Not sure if it's worth nothing, but the integrity service here
is different from DNSSEC, and clients need to be cognizant of that.
Probably obvious though.

> the decision taken on that point.

This para:

"
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.
"

... strikes me as weird, given that it didn't say what is the
"primary" use-case. I think that needs fixing or may cause
confusion later. The question is: did I miss where you said what
was the primary use-case?

The comment: I find this version no better than the last in
terms of saying that the WG needs to consider the scope within
which DNS answers are used. And that was my major issue with
the last iteration, so overall, this version doesn't seem that
much better to me. My suggestion is to add text along these
lines:

"The WG will analyse the security and privacy issues that could
arise from accessing DNS in this manner. For example it'd clearly
be bad if JavaScript from random web sites could poison the OS's
DNS cache (though hopefully no implementation would allow that).
The manner in which that analysis is documented will be decided
by the WG."

Cheers,
S.

---

From: Adam Roach <[email-masked]>
Date: Mon, 25 Sep 2017 18:38:30 -0500

> is different from DNSSEC, and clients need to be cognizant of that.

It's not different; it's in addition to. The mechanism being described 
would pass DNSSEC information through unscathed.

> was the primary use-case?

It's pretty similar to DPRIVE (or, really, DNS in general). I see that 
DPRIVE does have some text that seems to serve the purpose, so I'll copy 
it over with minor tweaks like so:

> 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.

> The manner in which that analysis is documented will be decided

What I'm seeing here is that the IETF isn't going to propose any changes 
to the web security model. In most cases, I think this goes without 
saying; but since you and Ted have both raised the issue, I suppose it 
bears mention in the charter. I've tweaked your phrasing a bit:

> The Working Group will analyze the security and privacy issues that could
> arise from accessing DNS over HTTPS. In particular, the Working Group will
> ensure that access to DNS information from a JavaScript context will 
> not have
> adverse impact on the host operating system's DNS cache. The manner in 
> which
> such analysis is performed will be decided by the working group.

/a

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 26 Sep 2017 00:49:29 +0100

Hiya,

> would pass DNSSEC information through unscathed.

Again, it's a nit, but I've not clue what "not different" in the
above means. (Since DNSSEC is different:-)

>> Resolvers.Â  While access to DNS-over-HTTPS servers from JavaScript
>> running in

I'm fine with that. I'll be interested to see if others are
also.

>> such analysis is performed will be decided by the working group.

I'd be just about ok with that. My problems with your rephrasing
are:

- I'm not sure the WG can "ensure" a lack of adverse impact, so
  why make it a requirement, if it's not possible?

- Pollution of the OS's cache may not be the only bad thing that
  can happen, so that needs to be an example.

- I'm fine that a WG decide how to document stuff, but saying
  they can decide the manner in which such analysis is performed
  seems to me like you could drive a giant cart and horses-
  galore through that loophole, and that phrasing seems to
  nearly invite that, and I've seen WGs do just that kind of
  thing. I'd like that you or some other AD could ask to be
  pointed at the analysis results and for those to at minimum
  need a WG-list thread, so saying "do the work, document it
  however you like" seems like a better plan to me.

Cheers,
S.

---

From: Martin Thomson <[email-masked]>
Date: Tue, 26 Sep 2017 10:04:39 +1000

>   however you like" seems like a better plan to me.

How about just:

The Working Group will analyze the security and privacy issues that
could arise from accessing DNS over HTTPS. In particular, the Working
Group will consider the interaction of DNS and HTTP caching.

I don't think that we need the JS piece in there.  There are special
concerns there, but I think that we're all enough aware of those
concerns that we can reach a conclusion of sorts in the working group.

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 26 Sep 2017 01:06:02 +0100

> Group will consider the interaction of DNS and HTTP caching.

Yep, that's better than my earlier suggestion.

S.

---

From: Adam Roach <[email-masked]>
Date: Mon, 25 Sep 2017 19:50:05 -0500

> Yep, that's better than my earlier suggestion.

Sold.

/a

---

From: Patrick McManus <[email-masked]>
Date: Mon, 25 Sep 2017 20:52:17 -0400

fine by me

---

From: Cullen Jennings <[email-masked]>
Date: Tue, 26 Sep 2017 09:43:36 -0500

If we need this to worry about what form of HTTP we are sending it over, we are doing it something very wrong - ether this or HTTP. And if this WG needs to worry about how the HTTP is transported over UPD, or TCP or v4 or v6, then we have the wrong charter. 

> On Sep 15, 2017, at 1:24 PM, Paul Hoffman <[email-masked]> wrote:
> 
> =>> This working group will standardize encodings for DNS queries and responses