Subject: [Doh] WGLC #2

From: Ben Schwartz <[email-masked]>
Date: Sat, 19 May 2018 10:47:56 -0400

DOH!

The Working Group Last Call on draft-ietf-doh-dns-over-https-07 raised an
excellent round of discussion.  The chairs believe that all issues raised
in that period have been satisfactorily addressed, and draft-08 reflects
the working group consensus on these questions.  However, to ensure that we
reach the best possible consensus, we are opening a short Working Group
Last Call on this latest draft.

Please review the draft:
https://tools.ietf.org/html/draft-ietf-doh-dns-over-https-08
or the changes
https://tools.ietf.org/rfcdiff?url2=draft-ietf-doh-dns-over-https-08.txt
and attempt to resolve any remaining concerns on the list by Friday May
25th (one week).

Sincerely,
The Chairs

---

From: "Hewitt, Rory" <[email-masked]>
Date: Mon, 21 May 2018 20:41:46 +0000

I know I brought this up in 
https://github.com/dohwg/draft-ietf-doh-dns-over-https/pull/174 and agreed to 
leave it, but I see that Mateusz subsequently brought it up in 
https://www.ietf.org/mail-archive/web/doh/current/msg00557.html...

I would really like to see Section 4 (Selection of DNS API Server) moved to be 
within Section 9 (Security Considerations), perhaps as a subsection (9.1: 
Selection of DNS API Server) and have the normative MUST and SHOULD changed to 
be non-normative 'must' and 'should'.

Specifically, my concern (as voiced in /pull/174)  is that I don't believe we 
should be using normative terms outside of technical implementation details - 
as I said "typically a MUST/REQUIRED/SHALL specifies an action to take and 
there will be some obvious consequences for not taking that action (an error 
thrown). In this case, we're saying "You MUST check that the DNS server you 
want to connect to is trustworthy" without saying how they should do that. And 
since there will be no error message from an untrustworthy DNS server, how 
would they know? It feels like we're taking things that outside of the spec 
(whether/how to trust a DNS server) and making it part of the spec... "

Ben and Patrick may have had valid reasons for disagreeing with me, but as I'm 
not sure if anyone else saw it, I'd like to be sure it's true consensus.

This is the last time I'll bring it up, I swear...

Rory

---

From: Mateusz Jończyk <[email-masked]>
Date: Tue, 22 May 2018 12:16:49 +0200

W dniu 21.05.2018 o 22:41, Hewitt, Rory pisze:
> Selection of DNS API Server) 

Hello,
I was also planning to bring up something about these sections but I was busy.

Both section "Security Considerations" and section "Selection of DNS API Server"
specify which server the client may use but in a different way:

	[...] the client MUST
	establish that the HTTP request URI is a trusted service for the DOH
	query, in other words, a DNS API client MUST only use a DNS API server
	that is configured as trustworthy.

vs

	A client MUST NOT use arbitrary DNS API servers. Instead, a client MUST
	only use DNS API servers specified using mechanisms such as explicit
	configuration.

Such discrepancy is confusing.

If there should be a section "Selection of DNS API Server", the text there
should be just a repetition of what is said in "Security considerations" with a
reference to "Security considerations".

So I would propose the following text for section "Selection of DNS API Server":

	As specified in the section "Security considerations",
	a client MUST NOT use arbitrary DNS API servers.
	Instead, a client MUST only use DNS
	API servers specified using mechanisms such as explicit configuration.

I have sent a corresponding pull request:

	https://github.com/dohwg/draft-ietf-doh-dns-over-https/pull/184

Greetings,
Mateusz

---

From: Sara Dickinson <[email-masked]>
Date: Tue, 22 May 2018 16:37:23 +0100

> On 21 May 2018, at 21:41, Hewitt, Rory <rhewitt=[email-masked]> wrote:
> 

The reason I think it is useful to have Section 4 is that Section 6.3 (Server Push) discusses which URI’s pushes should be accepted from and so is implicitly talking about which servers to use. However _if_ section 4 is moved I think there should at least be a reference in section 6.3 to Section 9.

2 other comments:

1) I previously asked if this spec required that a DNS API Sever should only be used if authentication of the TLS connection was successful. I got conflicting answers from Paul and Martin (‘No we can’t say that’ vs ‘authentication is critical and implicit’) and don’t see anything in this version that resolves this. I know there is other work attempting to address this issue (and more) but the lack of clarity in this document on the topic is still an issue for me. I’d still like to see a single sentence that either
- makes clear the requirement (preferable) or
- states that this is out of scope

2) “If a client of this protocol encounters an HTTP
   error after sending a DNS query, and then falls back to a different
   DNS retrieval mechanism, doing so can weaken the privacy and
   authenticity expected by the user of the client.”

What does authenticity mean here - data integrity or DNSSEC authentication? If it is the latter I would argue to remove it because DNSSEC and transport choice are orthogonal.

Sara.

---

From: Mateusz Jończyk <[email-masked]>
Date: Tue, 22 May 2018 19:29:32 +0200

> The reason I think it is useful to have Section 4 is that Section 6.3 (Server Push) discusses which URI’s pushes should be accepted from and so is implicitly talking about which servers to use. How…

I would argue that section 6.3 "Server Push" is poorly written and needs to be
clarified. I have asked several questions about it in the past:
	https://www.ietf.org/mail-archive/web/doh/current/msg00558.html
in order to better understand it. (I would like to thank Patrick McManus and Ben
Schwartz for explanations I received.)

I propose that it should be rewritten simply to:

	A DNS API client MUST ignore pushed DNS API requests (see {{RFC7540}}
	Section 8.2) whose pushed request URI does not match the configured DNS
	API server.

> - states that this is out of scope

It may happen that the DNS API server is running on a local home router and uses
a self-signed certificate. (I have talked about running a local DNS API server
on a home router before.)
I suppose that in this case the certificate could be supplied as part of a
configuration.

> What does authenticity mean here - data integrity or DNSSEC authentication? If it is the latter I would argue to remove it because DNSSEC and transport choice are orthogonal.

I suppose that it means here data integrity: the server can provide bogus
responses to DNS requests and strip DNSSEC information.

Greetings,
Mateusz

---

From: Mateusz Jończyk <[email-masked]>
Date: Wed, 23 May 2018 09:12:14 +0200

> 	Section 8.2) whose pushed request URI does not match the configured DNS

I have received no response, so have sent a pull request:
	https://github.com/dohwg/draft-ietf-doh-dns-over-https/pull/185

Greetings,
Mateusz Jończyk

---

From: "Hewitt, Rory" <[email-masked]>
Date: Wed, 23 May 2018 16:18:35 +0000

> However _if_ section 4 is moved I think there should at least be a reference in section 6.3 to Section 9.

Oh, that sounds like an excellent idea to me - I'd just really prefer to have all the "security considerations" stuff be in one place (Section 9) and ideally non-normative. But there should certainly be references to that section in many other places in the document.

Thanks,

Rory

-----Original Message-----
From: Sara Dickinson [mailto:[email-masked]] 
Sent: Tuesday, May 22, 2018 8:37 AM
To: Hewitt, Rory <[email-masked]>
Cc: DoH WG <[email-masked]>
Subject: Re: [Doh] WGLC #2

> https://github.com/dohwg/draft-ietf-doh-dns-over-https/pull/174 and 
> agreed to leave it, but I see that Mateusz subsequently brought it up 
> in https://www.ietf.org/mail-archive/web/doh/current/msg00557.html...
> 
> I would really like to see Section 4 (Selection of DNS API Server) 
> moved to be within Section 9 (Security Considerations), perhaps as a subsection (9.1:

2 other comments:

Sara.

---

From: Patrick McManus <[email-masked]>
Date: Wed, 23 May 2018 17:44:39 -0400

On Tue, May 22, 2018 at 11:37 AM, Sara Dickinson <[email-masked]> wrote:

>
> 1) I previously asked if this spec required that a DNS API Sever should
> only be used if authentication of the TLS connection was successful. I got
> conflicting answers from Paul and Martin (‘No we can’t say that’ vs
> ‘authentication is critical and implicit’) and don’t see anything in this
> version that resolves this. I know there is other work attempting to
> address this issue (and more) but the lack of clarity in this document on
> the topic is still an issue for me. I’d still like to see a single sentence
> that either
Martin is right - I'm not sure where the confusion originated.
Authentication is part of HTTPS. I know dprive went down the road of
opportunistic security, but that's not something HTTPS does. (plaintext
http:// might, but we're pretty clear about doh steering clear of that.)

https://github.com/dohwg/draft-ietf-doh-dns-over-https/pull/186

does this work?

 -DNS API client MUST only use a DNS API server that is configured as
trustworthy.
+DNS API client MUST only use a DNS API server that is configured as
+trustworthy. {{RFC2818}} defines how HTTPS verifies the identity of
+a connection with the trusted service.

---

From: Tom Pusateri <[email-masked]>
Date: Wed, 23 May 2018 17:53:32 -0400

> On May 23, 2018, at 5:44 PM, Patrick McManus <[email-masked]> wrote:
> 
> 
> 
> On Tue, May 22, 2018 at 11:37 AM, Sara Dickinson <[email-masked] <mailto:[email-masked]>> wrote:
> 
> Martin is right - I'm not sure where the confusion originated. Authentication is part of HTTPS. I know dprive went down the road of opportunistic security, but that's not something HTTPS does. (plaintext http:// might, but we're pretty clear about doh steering clear of that.)
> 
> https://github.com/dohwg/draft-ietf-doh-dns-over-https/pull/186 <https://github.com/dohwg/draft-ietf-doh-dns-over-https/pull/186>
> 
> does this work?
> 
>  -DNS API client MUST only use a DNS API server that is configured as trustworthy.

How do you define trustworthy? This seems like it would vary for different clients and servers in different environments.

Trustworthiness isn’t binary although somewhere along a sliding scale, it crosses a threshold where you are willing to configure it. But that threshold is different for each client / user.

I don’t think trustworthiness is something the document can require,. especially with RFC 2119 language.

Tom

---

From: Patrick McManus <[email-masked]>
Date: Wed, 23 May 2018 17:54:01 -0400

On Tue, May 22, 2018 at 11:37 AM, Sara Dickinson <[email-masked]> wrote:

> What does authenticity mean here - data integrity or DNSSEC
> authentication? If it is the latter I would argue to remove it because
> DNSSEC and transport choice are orthogonal.
>
>
I'm not a big fan of that text. What it says is true (essentially - if you
don't use HTTPS you don't get the properties of HTTPS), but that's not
really much of a security consideration of this protocol.

I'm going to propose removing the paragraph. thoughts?

---

From: Patrick McManus <[email-masked]>
Date: Wed, 23 May 2018 17:57:15 -0400

On Wed, May 23, 2018 at 5:53 PM, Tom Pusateri <[email-masked]> wrote:

> How do you define trustworthy? This seems like it would vary for different
> clients and servers in different environments.
>

that paragraph says you do it through the configuration. That's not being
changed here.

The addition describes, briefly, that verification of the identity of the
trusted service is something HTTPS does.

---

From: Tom Pusateri <[email-masked]>
Date: Wed, 23 May 2018 18:03:45 -0400

> On May 23, 2018, at 5:57 PM, Patrick McManus <[email-masked]> wrote:
> 
> 
> 
> On Wed, May 23, 2018 at 5:53 PM, Tom Pusateri <[email-masked] <mailto:[email-masked]>> wrote:
> 
> that paragraph says you do it through the configuration. That's not being changed here.

But how does an implementor of the spec ensure something is “configured as trustworthy”?

All the implementor can do is allow it to be configured.

Tom

---

From: Patrick McManus <[email-masked]>
Date: Wed, 23 May 2018 18:36:41 -0400

I don't find the text confusing at all. If you're asking how someone making
a configuration decision decides something is trustworthy, that's not in
scope here (just as the selection of PKI roots are not in scope for HTTPS).
>From the pov of the protocol, a URI is designated as trustworthy via
configuration. The explicit point being made here is that URIs discovered
in some other fashion are not considered trusted by this spec.

On Wed, May 23, 2018 at 6:03 PM, Tom Pusateri <[email-masked]> wrote:

>> How do you define trustworthy? This seems like it would vary for
>> different clients and servers in different environments.
>>
>
>

---

From: Patrick McManus <[email-masked]>
Date: Wed, 23 May 2018 18:57:37 -0400

>         Section 8.2) whose pushed request URI does not match the
a URI does not match a server - it must match a URI. and there need not be
only one configured uri. I think the existing text covers those cases.

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 24 May 2018 21:09:45 +0000

Greetings. WGLC #2 generated some good discussion and overlapping pull requests. We have issued draft -09 to deal with the discussion and make clear the current wording. Please see the diffs and let the WG know if there are still any outstanding issues on which there might be general agreement.

--Paul Hoffman

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 28 May 2018 12:10:43 -0400

> Greetings. WGLC #2 generated some good discussion and overlapping pull requests. We have issued draft -09 to deal with the discussion and make clear the current wording. Please see the diffs and le…

Hi,

I've been a little negligent in keeping up with this work lately, so I
thought I'd take this opportunity to do a complete review.  The
editors are free to take this input, ignore it, hold anything that
crops up for post-WG action, or whatever.

By and large, I find the document clear and easy to read, so
congratulations are due to the editors.

This bit in section 4 strikes me as strange:

    A client MUST NOT use a DNS API
   server simply because it was discovered, or because the client was
   told to use the DNS API server by an untrusted party. 

This feels like it's crying out for a definition of "trusted", and yet
that seems to me like a bad idea.  Today, when you use an open wifi,
you probably don't actually _trust_ the network operator, but you
accept the default DNS server you get from DHCP anyway (unless you're
the sort of nerd who thinks about this sort of thing).  I can't tell
from the text whether that kind of "trust" is supposed to be permitted
by this or not.  I recall some discussion about this in the past, but
if the WG thinks that was resolved the resolution is totally opaque to
an uninformed reader.

Section 5.1 might want to note that the very fact of dependence on
HTTPS means that the spoofing-resilience advantage of random DNS IDs
do not apply to this case, but that DNS API servers are expected to
deliver maximal spoofing resilence in performing any (normal) DNS
resolution they themselves must do.  Maybe this goes without saying,
however.

This text in section 6.1

   The stale-while-revalidate and stale-if-error Cache-Control
   directives ([RFC5861]) could be well suited to a DOH implementation
   when allowed by server policy.  Those mechanisms allow a client, at
   the server's discretion, to reuse a cache entry that is no longer
   fresh.  In such a case, the client reuses all of a cached entry, or
   none of it.

ought to come with a note that this may be dangerous -- that is, if
DNS operators are expecting their TTLs to be respected, this is a
(new) way by which stale data might get re-used.  So, DNS API server
administrators ought to be careful with such a server policy.  Maybe
the warning ought to go in section 10, though it's hard to be sure:
it's partially a warning for everyone _else_ on the Internet,
including people who don't support DOH.

In the same section,

   DNS API clients MUST account for the Age response header's value
   ([RFC7234]) when calculating the DNS TTL of a response.  For example,
   if a RRset is received with a DNS TTL of 600, but the Age header
   indicates that the response has been cached for 250 seconds, the
   remaining lifetime of the RRset is 350 seconds.

makes something plain by implication that might not obviously be clear
otherwise.  In the DNS environment today, many "clients" are stubs,
and they're not very smart.  One thing they do not always do is much
cache control: they get the value from the full-service resolver and,
if there is any local caching at all, it's straight decrementing of
the TTL.  What this passage means is that the data that comes in to a
DNS API client _is not_ suitable to hand straight to the local stub
subsystem: instead, some additional processing MUST be performed in
order to ensure that TTLs are not accidentally extended by accident.
Given the quality of a lot of DNS code in the world, I think this
point should be made quite explicit somewhere in the document.  Again,
it might go in section 10, though it's not obvious to me that this is
an operational consideration.  It's more an architectural one.

-- 
Andrew Sullivan
[email-masked]

---

From: Martin Thomson <[email-masked]>
Date: Tue, 29 May 2018 10:23:27 +1000

> if the WG thinks that was resolved the resolution is totally opaque to

Thanks to Andrew for highlighting this little piece.  His comment
emphasizes the problem we're having here.  And there has been a lot of
back-and-forth on this subject.  I suspect that we might have to tackle the
"trust" question to make progress here.

I've always been unhappy with this text, but understand that the text
exists because other people are nervous about having arbitrary servers
provide DNS responses.  But as Andrew observes, that is precisely what
happens in a lot of scenarios.  Let's not pretend that the tiny few who
override DNS configuration are relevant here; those people are best
accommodated better with specific configuration options that control
defaults.

That's why I originally proposed a change to use "authorization" rather
than trust.  That is, it does not imply a value judgment.  But that's not
getting at the crux of the matter either.

The problem with accepting arbitrary DNS answers is grounded in two pieces
of trust that clients confer on servers:

The first is that stub resolvers frequently offload DNSSEC processing,
relying instead on the AD bit.  Such a resolver is entirely at the mercy of
the DNS API server in this case for answers that might be DNSSEC
authenticated.  That implies a degree of authorization.

The second is that DNSSEC doesn't secure the protocol completely.  DNSSEC
allows for multiple valid answers for a query and the choice of answer can
be important.  DNS-based load balancing uses this, and performance and
security can depend on the answer being selected correctly (at least in the
aggregate).  Here, there's a degree of authorization involved: we assume
that a client picks a server that forwards queries and answers faithfully.

On this latter point, there's a consideration that might be more pertinent:
we assume that the client directs queries to the same server and thereby
gains a consistent set of answers over time.

If we change the text, I think that we could avoid the MUST and say that
this document assumes that DNS API clients configure a single DNS API
server and do not send queries to, or accept answers from, other servers.
Then explain the consequences of configuring a DNS API server in terms of
what "trust" is conferred to that server, as I described above.  That is,
no 2119 language, but more along the lines of an applicability statement;
making it clear that the use of any other style of configuration is not
advisable, or at least making the risks known.

---

From: Patrick McManus <[email-masked]>
Date: Mon, 28 May 2018 21:30:41 -0400

> server and do not send queries to, or accept answers from, other servers.

 I don't think 'single' is the operative part there - and I don't think the
document assumes that beyond a single request needing a single URI. But,
yes, its the "others" that it is looking to exclude.

I also think you're right to imply that we have a tension here between what
we want to exclude now (stumbling across websites offering to be
recursives) and what we want to enable exploring later (stumbling across
websites offering to be recursives :)) in a more comprehensive manor. I'll
offer up some text inspired by 7540's handling of client certs which has a
somewhat similar profile.

This might not be hard to solve - the section is really just using
configuration and trust synonymously and a bit redundanty, but people are
reading more into trust. So perhaps we can just use one term. wdyt of:

"A DNS API client uses configuration to select the URI, and thus the DNS
API server, used for resolution. [RFC2818] defines how HTTPS verifies the
server's identity.

A client MUST NOT use a different URI simply because it was discovered
outside of configuration. Specifically, this specification does not extend
DNS resolution privileges to URIs that are not recognized by the DNS API
client as configured URIs. A future specification may support this case."

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 29 May 2018 11:35:14 +1000

On 29 May 2018, at 11:30 am, Patrick McManus <[email-masked]> wrote:
> 
> "A DNS API client uses configuration to select the URI, and thus the DNS API server, used for resolution. [RFC2818] defines how HTTPS verifies the server's identity.
> 
> A client MUST NOT use a different URI simply because it was discovered outside of configuration. Specifically, this specification does not extend DNS resolution privileges to URIs that are not recognized by the DNS API client as configured URIs. A future specification may support this case."

I was thinking along the same lines, so +1 (although we could have a conversation about whether a MUST NOT is appropriate here...).

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

---

From: Martin Thomson <[email-masked]>
Date: Tue, 29 May 2018 11:35:41 +1000

>   I don't think 'single' is the operative part there - and I don't think
the document assumes that beyond a single request needing a single URI.
But, yes, its the "others" that it is looking to exclude.

> I also think you're right to imply that we have a tension here between
what we want to exclude now (stumbling across websites offering to be

> A client MUST NOT use a different URI simply because it was discovered
outside of configuration.

... or that resources offers a response that is apparently a valid answer
to a DNS API query...

> Specifically, this specification does not extend DNS resolution
privileges to URIs that are not recognized by the DNS API client as
configured URIs. A future specification may support this case."

In my mail, I suggested that we hit the reasons for this restriction, so
that it is clear why this "MUST" appears (I also suggested not using a
MUST).  I think that explaining what the client leans on the server for is
important for understanding the decision to use the big guns here.

---

From: Patrick McManus <[email-masked]>
Date: Mon, 28 May 2018 21:40:02 -0400

,

> order to ensure that TTLs are not accidentally extended by accident.

That's not only what it means, it seems to me that's what it says :).. What
other words would help here? (Noting that this is not always a gateway.
Sometimes the HTTP client is the terminal client.)

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 28 May 2018 23:35:19 -0400

On Mon, May 28, 2018 at 09:40:02PM -0400, Patrick McManus wrote:
> That's not only what it means, it seems to me that's what it says :)

No, that's what it implies, but it's not what it says.  That's
actually what I'm complaining about.  The DNS is the swamp it is
partly because of the number of places in STD13 that depend on
implication rather than instruction for people to do the right thing.
A contract programmer with an alloted 18 hours will spend exactly 18
hours, at most, to do this.  So let's make it explicit.

Perhaps this: "remaining lifetime …seconds.  DNS API clients SHOULD
NOT pass along the received DNS RRset without decrementing the TTL to
match the remaining lifetime.  Doing so may accidentally prolong the
lifetime of a cached DNS RRset, and therefore ought not to be passed
along without strong evidence that the requesting client will process
the resulting cached entries correctly."

That's awkward and needs some work.  But it's at least explicit.

A

-- 
Andrew Sullivan
[email-masked]

---

From: Sara Dickinson <[email-masked]>
Date: Tue, 29 May 2018 10:27:15 +0100

> On 29 May 2018, at 02:30, Patrick McManus <[email-masked]> wrote:
> 
> 
>  I don't think 'single' is the operative part there - and I don't think the document assumes that beyond a single request needing a single URI. But, yes, its the "others" that it is looking to exclude.

+1 Do not limit this to a single configured server. 

> 
> I also think you're right to imply that we have a tension here between what we want to exclude now (stumbling across websites offering to be recursives) and what we want to enable exploring later (stumbling across websites offering to be recursives :)) in a more comprehensive manor. I'll offer up some text inspired by 7540's handling of client certs which has a somewhat similar profile.
> 
> This might not be hard to solve - the section is really just using configuration and trust synonymously and a bit redundanty, but people are reading more into trust. So perhaps we can just use one term. wdyt of: 
> 
> A client MUST NOT use a different URI simply because it was discovered outside of configuration. Specifically, this specification does not extend DNS resolution privileges to URIs that are not recognized by the DNS API client as configured URIs. A future specification may support this case.”

I much prefer the approach of just discussing configuration but I don’t think this goes far enough in answering Andrews question or helping implementors work out exactly what to to. So….

What does ‘configuration’ cover?
- Just direct configuration e.g. via a client API or config file
- Or also dynamic configuration e.g. via DHCP, assuming a future option for this (which raises the question of trust again….)? 

I support only specifying direct configuration in this document but either way making it more explicit.

Sara.

---

From: Ben Schwartz <[email-masked]>
Date: Tue, 29 May 2018 13:59:54 -0400

Thanks for everyone who participated in this WGLC #2, and thanks to the
authors for engaging and making good changes in response to input from the
working group.

The last call is now closed.  In the opinion of the chairs, the group has
reached technical consensus, and invested considerable effort in the
clarity and precision of the text.  The chairs ask the authors to
incorporate any outstanding input on the latest draft as they are able, and
publish a new draft, which we will pass to our Area Director and the IESG.

Thanks again to everyone who has helped throughout the process to make this
an excellent draft.

---

From: Mateusz Jończyk <[email-masked]>
Date: Tue, 29 May 2018 20:28:14 +0200

Hello,

W dniu 29.05.2018 o 03:30, Patrick McManus pisze:
> "A DNS API client uses configuration to select the URI, and thus the DNS API
> server, used for resolution. [RFC2818] defines how HTTPS verifies the server's
> identity.
>
> A client MUST NOT use a different URI simply because it was discovered outside
> of configuration. Specifically, this specification does not extend DNS
> resolution privileges to URIs that are not recognized by the DNS API client as

This does not differ much from the following text:

"A client MUST NOT use arbitrary DNS API servers. Instead, a client MUST only
use DNS API servers specified using mechanisms such as explicit configuration."

which happens to be what is specified by the current draft.

I think that the misunderstanding here stems from the fact that server trust is
specified in two distinct places in the document ("Security Considerations" and
"Selection of DNS API Server") and in each place differently.

I've been proposing over and over to unify both specifications. It is OK if Paul
(if I remember correctly) wants to have server trust defined in a separate
section outside "Security Considerations", but we should make both
specifications similar and make one of them refer to the other.

-----------------------------------------------------------------------------

I have also been thinking about the following mechanism:

A DNS API client would have a list of "trustworthy" DNS API servers, but which
DNS API server from that list is used could be selected using DHCP.

I sent this to the DRIU list [1], as I supposed it is more appropriate there.
But now such topics are being discussed on the DOH mailing list and so I am
posting it here.

It would have the following benefits:

1. Using one's own ISP's DNS server would allow DNS64.

2. It would give network administrators an easy way to choose a DNS provider
across a whole network (using DHCP) and configure it in one place instead of on
multiple machines.

3. It would also enable use of ISP's DNS API server (as a main server or as a
fallback), which would make it possible to share global DNS load across many
ISP's DNS servers. For details, see the quoted mail.

At the same time, it would provide protection against phishing and rogue actors.

Greetings,
Mateusz

[1] https://www.ietf.org/mail-archive/web/driu/current/msg00009.html

---

From: Martin Thomson <[email-masked]>
Date: Wed, 30 May 2018 11:10:25 +1000

We have a parallel discussion running.  Are the chairs declaring that dead?
On Wed, May 30, 2018 at 4:00 AM Ben Schwartz <bemasc=

> The last call is now closed..  In the opinion of the chairs, the group
has reached technical consensus, and invested considerable effort in the
clarity and precision of the text.  The chairs ask the authors to
incorporate any outstanding input on the latest draft as they are able, and
publish a new draft, which we will pass to our Area Director and the IESG.

> Thanks again to everyone who has helped throughout the process to make
this an excellent draft.

>> The Working Group Last Call on draft-ietf-doh-dns-over-https-07 raised
an excellent round of discussion.  The chairs believe that all issues
raised in that period have been satisfactorily addressed, and draft-08
reflects the working group consensus on these questions.  However, to
ensure that we reach the best possible consensus, we are opening a short
Working Group Last Call on this latest draft.

25th (one week).

> _______________________________________________
> Doh mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/doh

---

From: Patrick McManus <[email-masked]>
Date: Tue, 29 May 2018 21:22:54 -0400

Hi Sara,

On Tue, May 29, 2018 at 5:27 AM, Sara Dickinson <[email-masked]> wrote:

>
>
> I much prefer the approach of just discussing configuration but I don’t
> think this goes far enough in answering Andrews question or helping
> implementors work out exactly what to to. So….
>
> - Or also dynamic configuration e.g. via DHCP, assuming a future option
> for this (which raises the question of trust again….)?
>

I would describe [in]direct (or not) as one aspect of discovery, and the
working group has chosen to stay away from discovery in this document.

OTOH as I understand it discovery is the core topic of the DRIU bof, and is
also on topic for this WG in a different document should someone propose
such a thing.

DoH isn't trying to solve that problem with the text under discussion - its
just trying to say that the server(s) need to be bootstrapped and not
discovered via linking and pushing during unrelated HTTP activities. Using
the word "untrusted" was a mistake because it indicated more than that.

-Patrick

---

From: Patrick McManus <[email-masked]>
Date: Tue, 29 May 2018 22:14:17 -0400

I've proposed
https://github.com/dohwg/draft-ietf-doh-dns-over-https/pull/189

Mateusz, it also harmonizes with the security considerations a bit.

On Tue, May 29, 2018 at 9:22 PM, Patrick McManus <[email-masked]>
wrote:

> OTOH as I understand it discovery is the core topic of the DRIU bof, and
> is also on topic for this WG in a different document should someone propose
> such a thing.
>
> DoH isn't trying to solve that problem with the text under discussion -
> its just trying to say that the server(s) need to be bootstrapped and not

---

From: Patrick McManus <[email-masked]>
Date: Tue, 29 May 2018 22:19:23 -0400

I think my objection is that there is no assumption a client is passing
anything along - much less passing it along in dns wireformat. It might
cache it terminally, it might pass it along in http (in which case it would
modify the Age response header as 7234 defines..), etc..

what all of these cases have in common is they need to know what the TTL of
the RRset is at the time it is received, and that's what the text describes.

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 30 May 2018 10:38:33 -0400

Hi,

> working group has chosen to stay away from discovery in this document.

To people who are used to the model of, "I got my resolver from DHCP,"
a thing you get from DHCP is not obviously "discovery".  It's
(auto)configuration.  It's not hard to see how a hotspot portal is
going to extend that metaphor using DOH, and it is still not clear to
me that this text is saying, "Don't do that," though I think it might
be.  

Best regards,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 30 May 2018 14:46:21 +0000

> me that this text is saying, "Don't do that," though I think it might

The new text from the pull request is hopefully clearer:

A DNS API client MUST NOT use a different URI simply because it was discovered
outside of the client's configuration, or because a server offers an unsolicited response
that appears to be a valid answer to a DNS query. This
specification does not extend DNS resolution privileges to URIs that
are not recognized by the DNS API client as configured URIs. Such
scenarios may create additional operational, tracking, and security
hazards that require limitations for safe usage. A future
specification may support this use case.

That "future specification" might come out of DRIU, or from this WG.

--Paul Hoffman

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 30 May 2018 10:47:19 -0400

On Tue, May 29, 2018 at 10:19:23PM -0400, Patrick McManus wrote:
> anything along - much less passing it along in dns wireformat.

It's probably because the "client" and "server" roles in the document
feel more http-y, and less dns-y, at least to me.  I think this stance
is defensible, but it's not immediately obvious to a reader who comes
to the document fresh.

If a DNS API client is functioning as part of a general-purpose
resolution stack, then it is entirely possible that it is also feeding
what it gets on to other components.  In the DNS, as we know, the
distinction between "client" and "server" is not really the right one:
the question is, for any given message, what is the role of the
component sending or receiving data with respect to that message.  A
recursive resolver (yes, yes, a misnomer) can be thought of in that
way as having a resolver side and a server side.  The resolver side is
going to pass on data it gets from other servers to the server side.
And the resolver side itself might not be querying authoritative
servers.  We all know the whole thing is much more complicated than
the usual neat "stub -> full-service-resolver -> authoritative server"
diagram that everyone usually produces.

I'm worried that failing to call attention to this here will cause
implementers to believe in the simple-minded model, and then that a
DNS API client will go on to feed RRsets it gets into some other
subsystem.  And the point is that they can't, because before doing so
they need to decrement the TTL in the handed-on RRset.

Anyway, that was the basis for the comment.

Best regards,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Patrick McManus <[email-masked]>
Date: Wed, 30 May 2018 11:20:51 -0400

> me that this text is saying, "Don't do that," though I think it might
It's not saying that (is not trying to say that?). Primarily its saying if
you're browsing the web minding your own business and some site
unexpectedly provides you a DoH exchange with an address for example.com
don't use it unless that pushing site is one you have configured for
resolution.

Whether or not you do unauthenticated configuration (e.g. DHCP) is not
something it takes a position on.

---

From: Mateusz Jończyk <[email-masked]>
Date: Wed, 30 May 2018 17:59:06 +0200

Hello,

>+A DNS API client MUST NOT use a different URI simply because it was discovered
>+outside of the client's configuration, or because a DNS API server offers an
>+unsolicited response
>+that appears to be a valid answer to a DNS query.

The second part of this sentence is unclear to me. Some people may read it as
prohibiting all Server Pushed messages.
I would reword it as:
	... or simply because some web server offers an unsolicited response
	that appears to be a valid answer to a DNS query.

I think the previous wording in the "Security considerations" section was much
better:
	A client MUST NOT use arbitrary DNS API servers.
	Instead, a client MUST only use DNS
	API servers specified using mechanisms such as explicit configuration.

It only required a rewording of the section "Selection of DNS API server" to
match it.

------------------

By the way, we should clarify the section "Server push". I propose it to read so:

	A DNS API client MUST ignore pushed DNS API requests (see {{RFC7540}}
	Section 8.2) whose pushed request URI is not one that the client
	would have directed the same query to if the client had initiated the
	request.

(which is a modification of the text proposed in
	https://github.com/dohwg/draft-ietf-doh-dns-over-https/pull/185
and suits the comments there).

Greetings,
Mateusz Jończyk

W dniu 30.05.2018 o 04:14, Patrick McManus pisze:
> I've proposed https://github.com/dohwg/draft-ietf-doh-dns-over-https/pull/189
>

---

From: Patrick McManus <[email-masked]>
Date: Wed, 30 May 2018 12:20:33 -0400

I appreciate the comments.

On Wed, May 30, 2018 at 11:59 AM, Mateusz Jończyk <[email-masked]> wrote:

The server selection text that ended up merged is a little different than
what you quoted (partly because we had a similar reaction when rereading)

"A DNS API client MUST NOT use a different URI simply because it was
discovered outside of the client's configuration, or because a server
offers an unsolicited response that appears to be a valid answer to a DNS
query."

the key and clear part there is "a different URI".

>         API servers specified using mechanisms such as explicit
While I normally favor concise (and do like your text), the feedback has
been to err on the side of being more explanatory especially in justifying
use of MUST NOT - so editorially I think what we have is the right thing to
do and I think you did make it better by reconciling it more tightly with
the server selection section.

> It only required a rewording of the section "Selection of DNS API server"
Basically, my response is that this is the same as the security
considerations reasoning. Its helpful to explain a little bit of rationale
and highlight how this differs between push and pull..

---

From: Sara Dickinson <[email-masked]>
Date: Thu, 31 May 2018 10:20:34 +0100

> On 30 May 2018, at 15:46, Paul Hoffman <[email-masked]> wrote:
> 

I agree with Andrew here - the document doesn’t define either configuration or discovery and they are open to interpretation. A reader who has not been privy to the repeated discussions on the mailing list has no context within the document itself to accurately judge the distinction. If these terms were defined it would be easy to state what is in scope and what is out of scope and clarify the document further. If we as a WG struggle to define them then that in itself speaks to a lack of consensus on the problem statement.

I agree the new text is clearer about the push scenario but the general case of ‘configuration’ is still under specified IMHO.

Sara.

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 31 May 2018 13:46:21 +0000

> I agree the new text is clearer about the push scenario but the general case of ‘configuration’ is still under specified IMHO.

Without a discussion here on proposed text about what either of you think configuration is, any attempt that we make has a high chance of making the wording worse for the majority, not better. (My personal preference is to defer this discussion to DRIU because configuration is an issue for all DNS clients, not just those using DOH, but am happy to hear new wording as long as the WG has energy to grind on this.)

--Paul Hoffman

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 31 May 2018 11:11:51 -0400

Hi,

On Thu, May 31, 2018 at 01:46:21PM +0000, Paul Hoffman wrote:
> 
> Without a discussion here on proposed text about what either of you
> think configuration is,

I just think it needs to be clear about what is and isn't covered by
configuration: is autoconf in or out?  One possibility is that it's
supposed to be out, and then something like "explicit configuration,
excluding any autoconfiguration" would be ok.  But I think some people
aren't going to like that.  I suspect that we haven't made up our
minds about this; but it won't do to leave an ambiguity just because
we can't make up our minds.  Readers of this document will need to
know whether only a user may on purpose set up the use of some URI, or
whether the user may configure the system to get stuff automatically
and thereby learn about (and subsequently use) a DNS API server.

The reason I'm on about this is because I can't tell what the
consequences are of the configuration being out of band.  If it just
means, "A user needed to go into their system and directly configure
some URI," then it seems plain the user gets to make an explicit
decision.  But if you can autoconfigure, then that has different
consequences (e.g. maybe you got the URI from your hotspot signon
portal, and now a random hotspot can partly alter your resolution
settings even after you've changed networks).  It's ok with me that we
might want to punt this to DRIU or something, but it needs to be
crystal clear what meaning of "configuration" is intended.

Does this make my concern clearer?

Best regards,

A
-- 
Andrew Sullivan
[email-masked]

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 31 May 2018 15:18:36 +0000

Thanks, this does make it clearer. Proposal: move this sentence:
   Configuration and discovery of the URI Template is done out of band from this protocol.
up to before the first use of the word "configuration", and change it to:

Configuration, discovery, and updating of the URI Template is done out of band from this protocol. Note that configuration might be manual (such as a user typing URI Templatess in the UI for "options") or automatic (such as URI Templates being supplied in responses from DHCP or similar protocols).

Is this sufficient?

--Paul Hoffman

---

From: Mateusz Jończyk <[email-masked]>
Date: Thu, 31 May 2018 20:17:30 +0200

> Configuration, discovery, and updating of the URI Template is done out of band from this protocol. Note that configuration might be manual (such as a user typing URI Templatess in the UI for "optio…
+1 to general idea.

I think that this sentence should follow the first sentence in the section
"Selection of DNS API Server" and be slightly modified:

	A DNS API client uses configuration to select the URI, and thus the DNS
	API server, that is to be used for resolution.
	Configuration, discovery, and updating of the URI is done out 	
	of band from this protocol. Note that configuration might be manual
	(such as a user typing URI Templates in the UI for "options") or
	automatic (such as URI Templates being supplied in responses from DHCP
	or similar protocols).

	[RFC2818] defines how HTTPS verifies the DNS API server's identity.

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 31 May 2018 21:56:22 +0000

I have submitted this as a pull request:
   https://github.com/dohwg/draft-ietf-doh-dns-over-https/pull/190
I actually moved the whole paragraph (not just the sentence) up before adding the clarifications about updating config and config examples.

--Paul Hoffman

---

From: Mateusz Jończyk <[email-masked]>
Date: Fri, 1 Jun 2018 00:45:31 +0200

Please note that "URI Template" is specified later in the text (in "The HTTP
Request") and its usage is not clear in section "Selection of DNS API Server").

This term should be explained in "Selection of DNS API Server", e.g.:
	Configuration, discovery, and updating of the URI Template (and thus the
	DNS API server) is done out of band from this ...

Other that that, the pull request is OK to me.

Greetings,
Mateusz