Subject: [Doh] I-D Action: draft-ietf-doh-resolver-associated-doh-03.txt

From: [email-masked]
Date: Sun, 24 Mar 2019 01:14:54 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the DNS Over HTTPS WG of the IETF.

        Title           : Associating a DoH Server with a Resolver
        Author          : Paul Hoffman
	Filename        : draft-ietf-doh-resolver-associated-doh-03.txt
	Pages           : 10
	Date            : 2019-03-24

Abstract:
   Browsers and web applications may want to know if there are one or
   more DoH servers associated with the DNS recursive resolver that the
   operating system is already using.  This would allow them to get DNS
   responses from a resolver that the user (or, more likely, the user's
   network administrator) has already chosen.  This document describes
   two protocols for a resolver to tell a client what its associated DoH
   servers are.  It also describes a protocol for a client to find out
   the address of the resolver it is using, if it cannot find that
   address by an operating system API or some other means.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-doh-resolver-associated-doh/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-doh-resolver-associated-doh-03
https://datatracker.ietf.org/doc/html/draft-ietf-doh-resolver-associated-doh-03

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-doh-resolver-associated-doh-03

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Paul Hoffman <[email-masked]>
Date: Sun, 24 Mar 2019 08:20:22 +0000

The diffs here are what I think have general agreement from the discussion about this draft so far, but I may have missed things. Comments are still quite welcome.

As for the late discussion of using the URI RRtype instead of TXT, I would not know what to put in the "priority" and "weight" values. That alone seems enough reason to leave this as a TXT record, but others might disagree. It's not a lot of effort to change the text to the URI RRtype, but I don't want to do so unless it is actually better than TXT.

--Paul Hoffman

---

From: Joseph Lorenzo Hall <[email-masked]>
Date: Sun, 24 Mar 2019 10:12:20 +0100

Couple of small things:

typo, Intro: "Users typically configure their DNS recursive resolvers with
through automatic configuration"

I don't get the "Do53" abbreviation, but I'll grab you and maybe you can
help me make sense of it (a very small thing considering you could have
said DoPotatoes or whatever).

Are there any outcomes you can see where IANA is compelled to delegate the
SUDNs here? Or where an authoritarian government might require resolvers to
collide, if that makes sense?

In privacy considerations the draft says, "can increase communication
privacy because of the TLS protection." I'm wondering if it makes sense to
say explicitly "confidentiality and integrity" in a parenthetical near
privacy?

Thanks for this work, feel free to respond on-list if helpful!

On Sun, Mar 24, 2019 at 09:20 Paul Hoffman <[email-masked]> wrote:

> The diffs here are what I think have general agreement from the discussion
> about this draft so far, but I may have missed things. Comments are still
> quite welcome.
>
> As for the late discussion of using the URI RRtype instead of TXT, I would
> not know what to put in the "priority" and "weight" values. That alone
> seems enough reason to leave this as a TXT record, but others might
> disagree. It's not a lot of effort to change the text to the URI RRtype,
> but I don't want to do so unless it is actually better than TXT.
>
> --Paul Hoffman
> _______________________________________________
> Doh mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/doh
>
-- 
Joseph Lorenzo Hall
Chief Technologist, Center for Democracy & Technology [https://www.cdt.org]
1401 K ST NW STE 200, Washington DC 20005-3497
e: [email-masked], p: 202.407.8825, pgp: https://josephhall.org/gpg-key
Fingerprint: 3CA2 8D7B 9F6D DBD3 4B10  1607 5F86 6987 40A9 A871

---

From: nusenu <[email-masked]>
Date: Sun, 24 Mar 2019 09:46:00 +0000

Paul Hoffman wrote:
> The diffs here are what I think have general agreement from the
> discussion about this draft so far, but I may have missed things.
> Comments are still quite welcome.

Thanks for the update, I had a look at the diff:

draft-ietf-doh-resolver-associated-doh-03.txt:
>  	   If DNS queries sent from stub resolvers to recursive resolvers are	
> 		 	   not sent over transports that assure data integrity and server	
> 		 	   authentication, the "DoH servers from DNS" and "Resolver addresses	
> 		 	   from DNS" protocols are susceptible to on-path attackers directing a	
> 		 	   user to a DoH server that is not actually associated with their	
> 		 	   resolver.  Do53 is not a secure transport, and neither is DoT using	
> 		 	   the opportunistic profile.	
> 		 		
> 		 	   The DNS responses used in "DoH servers from DNS" and "Resolver	
> 		 	   addresses from DNS" cannot be validated with DNSSEC [RFC4033], and	
> 		 	   thus even a validating stub resolver would treat them the same as any	
> 		 	   other DNS responses in unsigned zones.

Thanks for adding this to the security section. 
Maybe also add a sentence about the downgrade attack weakness of the protocol?

I'm wondering about the reasoning for not adding additional safeguards 
to reduce the window of opportunity for attackers exploiting the weaknesses
in the DoH server discovery mechanism as suggested in [1]?

> "If the DoH client has a DoH URI configured already, 
> it MUST NOT override the DoH URI learned through the discovery
> mechanisms in this document."

[...]

> extend: 
> 
>> A client MUST re-issue the queries in "DoH Servers from DNS" and
>> "Resolver Addresses from DNS" every time the configured resolver in
>> the operating system changes 
> 
> with:
> 
> or whenever the client's IP address changes
> (even if the resolver does not change). 

[...]

> "The mechanism in section 2 is the safest and MUST be attempted first."
> 
> 
> You could also consider some downgrade attack protections where the attacker
> simply blocks 443 to force the unauthenticated mechanism in section 3.
> 
> Such a protection could be implemented via an additional field in the JSON file
> by borrowing max-age from HSTS.
> https://tools.ietf.org/html/rfc6797#section-6.1.1

kind regards,
nusenu

[1] https://mailarchive.ietf.org/arch/msg/doh/295yrI72xt0eSnYueiOuqVpSj4s

-- 
https://twitter.com/nusenu_
https://mastodon.social/@nusenu

---

From: Paul Hoffman <[email-masked]>
Date: Sun, 24 Mar 2019 09:58:29 +0000

Thanks for the quick read!

On Mar 24, 2019, at 10:12 AM, Joseph Lorenzo Hall <[email-masked]> wrote:
> 
> Couple of small things:
> 
> typo, Intro: "Users typically configure their DNS recursive resolvers with through automatic configuration"

Fixed.

> I don't get the "Do53" abbreviation, but I'll grab you and maybe you can help me make sense of it (a very small thing considering you could have said DoPotatoes or whatever).

I thought it was clearer than than "DoU/T". It is short for "DNS over port 53".

> Are there any outcomes you can see where IANA is compelled to delegate the SUDNs here?

No, very definitely not. That's why the "IANA Considerations" say explicitly MUST NOT. IANA follows the rules from the RFCs defining new entries.

> Or where an authoritarian government might require resolvers to collide, if that makes sense?

Governments, authoritarian or not, can intercede in the DNS in many ways.

> In privacy considerations the draft says, "can increase communication privacy because of the TLS protection." I'm wondering if it makes sense to say explicitly "confidentiality and integrity" in a parenthetical near privacy?

Sure.

--Paul Hoffman

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Mon, 25 Mar 2019 12:01:36 +0100

On Sun, Mar 24, 2019 at 01:14:54AM -0700,
 [email-masked] <[email-masked]> wrote 

> 	Filename        : draft-ietf-doh-resolver-associated-doh-03.txt

My biggest issue is that the rationale in section 1 has many weak points:

* "There is a use case for browsers and web applications". Why not for
local limited resolvers like stubby or systemd-resolve? We assume they
will always prefer DoT?

* "much less often, they use manual configuration" Less often but more
and more, to workaround failures and/or censorships. On a gamer forum,
these days, any report of an issue, whatever the issue is, elicit a
suggestion "switch to [some public DNS resolver]"

* "In a common scenario" "Common" is way too vague for something which
exists in *some* corporate networks but never (I hope so!) in public
ISPs.

Otherwise, even after reading the whole thread "Reviewing
Resolver-Associated DOH", I don't understand why https is required in
section 2. We don't require DNSSEC in section 3, so why having
stronger requirments for HTTP? Since having certificates for IP
addresses will be difficult in practice, why not just accepting http
as well as https? (Or, <horror>https without cert. checking</horror>.)

Editorial:

* in section 5, server is written serer.

* in section 1, "Users typically configure their DNS recursive
resolvers with through automatic configuration" With through?

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 25 Mar 2019 11:32:29 +0000

> local limited resolvers like stubby or systemd-resolve? We assume they

Yes.

> suggestion "switch to [some public DNS resolver]"

I'll remove the "much".

> exists in *some* corporate networks but never (I hope so!) in public

Good catch; fixed.

> resolvers with through automatic configuration" With through?

Both fixed.

--Paul Hoffman

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 25 Mar 2019 11:36:56 +0000

> as well as https? (Or, <horror>https without cert. checking</horror>.)

The reason I didn't drop down to http: is that doing so evokes the <horror> response, even though you are quite correct that the other two methods given in this document do not offer any authentication. So, let me ask the WG:

Would this document be better off with all three methods being equally unauthenticated? Doing so would remove the "but you can't get IP address certificates!" argument that keeps coming up (even though that is overstated). Doing so would simplify the security considerations by making all three protocols have the same obvious weakness.

An alternative is to have two URI, one with https: and one with http:, and explain that trying the first might be a good idea but to fall back to the second if authentication fails.

Thoughts?

--Paul Hoffman

---

From: "Ralf Weber" <[email-masked]>
Date: Mon, 25 Mar 2019 16:05:48 +0100

Moin!

> Comments are still quite welcome.
I have some questions after reading -03 (and skipping -02 ;-)
- The resolver IP addresses returned from DNS on section 4 are these 
Do53 server addresses or DoH server address or are they just the IP to 
start the process in section 2 (maybe 3)?
- On section 3 a non compliant current server will return NXDomain. What 
are we going to do with this answer (treat is as no DoH associated)?

> As for the late discussion of using the URI RRtype instead of TXT, I 
> would not know what to put in the "priority" and "weight" values. That 
> alone seems enough reason to leave this as a TXT record, but others 
> might disagree. It's not a lot of effort to change the text to the URI 
> RRtype, but I don't want to do so unless it is actually better than 
> TXT.
Another option could be a new RRType, given that it doesn’t have to be 
provisioned on auth servers it should not be that difficult to roll it 
out. We still could use the special name or just ask .

So long
-Ralf
—--
Ralf Weber

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 25 Mar 2019 15:25:46 +0000

On Mar 25, 2019, at 4:05 PM, Ralf Weber <[email-masked]> wrote:
> - The resolver IP addresses returned from DNS on section 4 are these Do53 server addresses or DoH server address or are they just the IP to start the process in section 2 (maybe 3)?

They are the IP addresses of the Do53 resolver that the computer is using. I'll make that clearer in the next draft.

> - On section 3 a non compliant current server will return NXDomain. What are we going to do with this answer (treat is as no DoH associated)?

Yes, that was the intention. I'll clarify that.

> Another option could be a new RRType, given that it doesn’t have to be provisioned on auth servers it should not be that difficult to roll it out. We still could use the special name or just ask .

I have been told that some OSs have "send a TXT request" API call, but I have not verified that. If so, then TXT records will have an advantage. Otherwise, using a new RRtype is cleaner.

Can someone who from the application implementation world verify or refute my hazy memory of API calls for TXT records?

--Paul Hoffman

---

From: Ben Schwartz <[email-masked]>
Date: Mon, 25 Mar 2019 12:03:35 -0400

On Mon, Mar 25, 2019 at 11:25 AM Paul Hoffman <[email-masked]>
wrote:

> They are the IP addresses of the Do53 resolver that the computer is using.
> I'll make that clearer in the next draft.
>
> alone seems enough reason to leave this as a TXT record, but others might
> provisioned on auth servers it should not be that difficult to roll it out.
> We still could use the special name or just ask .
>
> I have been told that some OSs have "send a TXT request" API call, but I
> have not verified that. If so, then TXT records will have an advantage.
> Otherwise, using a new RRtype is cleaner.
>
> Can someone who from the application implementation world verify or refute
> my hazy memory of API calls for TXT records?
>

POSIX systems generally lack such an API.

--Paul Hoffman

---

From: Ben Schwartz <[email-masked]>
Date: Mon, 25 Mar 2019 12:10:29 -0400

On Mon, Mar 25, 2019 at 7:37 AM Paul Hoffman <[email-masked]> wrote:

> The reason I didn't drop down to http: is that doing so evokes the
> <horror> response, even though you are quite correct that the other two
> methods given in this document do not offer any authentication. So, let me
> ask the WG:
>
> Would this document be better off with all three methods being equally
> unauthenticated? Doing so would remove the "but you can't get IP address
> certificates!" argument that keeps coming up (even though that is
> overstated). Doing so would simplify the security considerations by making
> all three protocols have the same obvious weakness.
>
> An alternative is to have two URI, one with https: and one with http:, and
> explain that trying the first might be a good idea but to fall back to the
> second if authentication fails.
>
> Thoughts?
>

Given that the protocol is called "DNS over HTTPS", running it over
unencrypted HTTP seems like a contradiction.  It also complicates any
security status indication by introducing a mode that no longer offers any
confidentiality benefit over standard DNS.

Apart from security issues, insecure HTTP is generally restricted to
HTTP/1.1.  DoH implementations are strongly encouraged to use HTTP/2,
because HTTP/1.1 requires in-order responses.  Running DoH over HTTP/1.1
increases the likelihood of performance problems.

--Paul Hoffman

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 25 Mar 2019 16:12:09 +0000

> POSIX systems generally lack such an API.

Yes, of course, but I had heard that many OSs add it.

--Paul Hoffman

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 25 Mar 2019 16:15:40 +0000

> On Mar 25, 2019, at 5:10 PM, Ben Schwartz <[email-masked]> wrote:
> 
> On Mon, Mar 25, 2019 at 7:37 AM Paul Hoffman <[email-masked] <mailto:[email-masked]>> wrote:
> On Mar 25, 2019, at 12:01 PM, Stéphane Bortzmeyer <[email-masked] <mailto:[email-masked]>> wrote:
> Given that the protocol is called "DNS over HTTPS", running it over unencrypted HTTP seems like a contradiction.  It also complicates any security status indication by introducing a mode that no longer offers any confidentiality benefit over standard DNS.

This may be a misunderstanding. The protocol in section 2 is not running DoH, it is for finding a DoH server, in this case, asking for data from a .well-known location. We can choose whatever protocol we want for that; in Section 3, we use DNS.

> Apart from security issues, insecure HTTP is generally restricted to HTTP/1.1.  DoH implementations are strongly encouraged to use HTTP/2, because HTTP/1.1 requires in-order responses.  Running DoH over HTTP/1.1 increases the likelihood of performance problems.

Again, this is not about running DoH.

---

From: nusenu <[email-masked]>
Date: Mon, 25 Mar 2019 19:27:00 +0000

Paul Hoffman wrote:
> Would this document be better off with all three methods being
> equally unauthenticated? Doing so would remove the "but you can't get
> IP address certificates!" argument that keeps coming up (even though
> that is overstated). Doing so would simplify the security
> considerations by making all three protocols have the same obvious
> weakness.
> 
> An alternative is to have two URI, one with https: and one with
> http:, and explain that trying the first might be a good idea but to
> fall back to the second if authentication fails.
> 
> Thoughts?

Since implementations might choose to implement only 
the authenticated discovery portion using authenticated https
I'd suggest to keep https in.

---

From: tirumal reddy <[email-masked]>
Date: Tue, 26 Mar 2019 09:47:23 +0100

> I'd suggest to keep https in.

Agreed, and with our proposal in
https://tools.ietf.org/html/draft-reddy-dprive-bootstrap-dns-server-02, the
query for URI templates can use FQDN instead of
IP address, and the HTTPS server certificate can be validated by the DoH
client.

-Tiru

---

From: Patrick McManus <[email-masked]>
Date: Tue, 26 Mar 2019 11:25:38 +0100

On Tue, Mar 26, 2019 at 9:48 AM tirumal reddy <[email-masked]> wrote:

> https://tools.ietf.org/html/draft-reddy-dprive-bootstrap-dns-server-02,
> the query for URI templates can use FQDN instead of
right. The weakness here is that validating a name that probably comes from
an unauthenticated source is not a very strong signal. That seems inherent
in the draft, but maybe worth calling out more explicitly.

otoh - and out of scope for this draft - the DoH client could do some kind
of validation beyond the name.. like looking for a x509 attribute (and
cross signature) indicating some kind of better-business like endorsement
of privacy practices. So I think validation in the scope of
associated-resolver is a desirable property even though the usually
validated thing, the name, is a little less valuable here.

---

From: tirumal reddy <[email-masked]>
Date: Tue, 26 Mar 2019 11:46:26 +0100

On Tue, 26 Mar 2019 at 11:25, Patrick McManus <[email-masked]> wrote:

> right. The weakness here is that validating a name that probably comes
> from an unauthenticated source is not a very strong signal.
>

No, the name is coming from a authenticated source. The explicit trust
store to validate the local DoH server certificate can also be used to
validate the S-NAPTR lookup
response is authentic using DNSSEC.

> That seems inherent in the draft, but maybe worth calling out more
> explicitly.
>
> of privacy practices.

The draft discusses a privacy certificate extension that helps the endpoint
identify the privacy preserving data policy of the DNS
server. The extension contains a URL that points to the privacy
preserving data policy.

> So I think validation in the scope of associated-resolver is a desirable
> property even though the usually validated thing, the name, is a little
> less valuable here.
>

The name is a reference identifier for validating the local DoH server
certificate.

Cheers,
-Tiru

---

From: Patrick McManus <[email-masked]>
Date: Tue, 26 Mar 2019 12:02:42 +0100

I'm sorry - I quoted your draft name when I was referring to Paul's.

On Tue, Mar 26, 2019 at 11:46 AM tirumal reddy <[email-masked]> wrote:

>> otoh - and out of scope for this draft - the DoH client could do some
>> kind of validation beyond the name.. like looking for a x509 attribute (and

---

From: tirumal reddy <[email-masked]>
Date: Tue, 26 Mar 2019 12:10:46 +0100

No worries. My point is client must be configured with a explicit trust
store to validate the local DoH server certificate.
The network domain name can be retrieved from the explicit trust store
itself.

-Tiru

On Tue, 26 Mar 2019 at 12:02, Patrick McManus <[email-masked]> wrote:

>>>> IP address, and the HTTPS server certificate can be validated by the
>>>> DoH client.
>>>>
>>>>

---

From: Erik Nygren <[email-masked]>
Date: Tue, 26 Mar 2019 09:24:29 -0400

> As for the late discussion of using the URI RRtype instead of TXT, I
would not know what to put in the "priority" and "weight" values.
> That alone seems enough reason to leave this as a TXT record, but others
might disagree.
> It's not a lot of effort to change the text to the URI RRtype, but I
don't want to do so unless it is actually better than TXT.

Being able to specify at least priority (even if using fixed/equal weights)
seems valuable,
as many large networks architect their DNS infrastructure have "primary"
and "secondary" site clusters.
The primary and secondary clusters are often sized and located differently,
such as with the primary
being more widely distributed and the secondary more centrally deployed.
I suspect this desire to have a ordered preference but with failover will
carry over to DoH.

       Erik

---

From: Erik Nygren <[email-masked]>
Date: Tue, 26 Mar 2019 18:46:26 -0400

On Tue, Mar 26, 2019 at 6:26 AM Patrick McManus <[email-masked]>
wrote:

> from an unauthenticated source is not a very strong signal. That seems
> inherent in the draft, but maybe worth calling out more explicitly.
>

Right.  It typically comes from unauthenticated DHCP or RDNSS.

One thought I've pondered is whether there is a way to apply policy to the
hostname in the DoH template URL, as that is an authenticated hostname.
For example, clients could validate against a blacklist of known-bad DoH
server hostnames/domains.  This may not scale well enough to be viable.
But we are inherently getting unauthenticated data from an unauthenticated
source.  But that unauthenticated data is something which is possible to
authenticate and possibly authorize based on the hostname.

A similar model is done in Provisioning Domains where unauthenticated PvDs
come from the network and are used to construct well-known URLs:
https://tools.ietf.org/html/draft-ietf-intarea-provisioning-domains-04

How to make this practical is where I get stuck.  :-)

       Erik

---

From: "Winfield, Alister" <[email-masked]>
Date: Wed, 27 Mar 2019 08:24:15 +0000

On Tue, Mar 26, 2019 at 6:26 AM Patrick McManus <[email-masked]<mailto:[email-masked]>> wrote:

right. The weakness here is that validating a name that probably comes from an unauthenticated source is not a very strong signal. That seems inherent in the draft, but maybe worth calling out more explicitly.

One thought I've pondered is whether there is a way to apply policy to the hostname in the DoH template URL, as that is an authenticated hostname.  For example, clients could validate against a blacklist of known-bad DoH server hostnames/domains.  This may not scale well enough to be viable.  But we are inherently getting unauthenticated data from an unauthenticated source.  But that unauthenticated data is something which is possible to authenticate and possibly authorize based on the hostname.

You could equally state that the user has to ‘approve’ all new DoH templates. Each has its own issues and in any reasonable scheme its likely you’d need both. One to capture users approval to use a particular DoH provider (including accepting their privacy policy t&c’s whatever). The other so that some form of policy protecting the user from malicious DoH can be applied. The issue is as ever managing such lists without creating the ‘click through’ problem on the choices side.  (read users never read stuff that pops up too often). Or issues with the curation of the blacklist and arguments on what is malicious and what is good for the user.

(Next is a very early thought so I may yet find a reason not to like it)

Another option that I’m liking more the longer I consider it is a notary mechanism. This is like your blacklist but has properties that avoid the who audits / polices the lists. So your notaries provide white and black lists for DoT/DoH even Do53. Anything outside the list SHOULD present something to the user with the policy information provided. Yes that could be lie but that’s not something we can fix.

Not saying I’ve thought this through completely but its feels scalable and doesn’t significantly impede new DoH providers. Users will self-police the notaries and that side can be as simple or complicated as they like including having multiple lists with different privacy properties.

A similar model is done in Provisioning Domains where unauthenticated PvDs come from the network and are used to construct well-known URLs:  https://tools.ietf.org/html/draft-ietf-intarea-provisioning-domains-04<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-ietf-intarea-provisioning-domains-04&data=02%7C01%7Calister.winfield%40sky.uk%7Ce5888ce57e4d4e46148d08d6b23cf5c8%7C68b865d5cf184b2b82a4a4eddb9c5237%7C0%7C0%7C636892372261334679&sdata=A7Z7O%2FO6qU7r54%2BaItzHeIfdDP2ulQ%2FfPp8LZ3QSc3I%3D&reserved=0>

       Erik

Information in this email including any attachments may be privileged, confidential and is intended exclusively for the addressee. The views expressed may not be official policy, but the personal views of the originator. If you have received it in error, please notify the sender by return e-mail and delete it from your system. You should not reproduce, distribute, store, retransmit, use or disclose its contents to anyone. Please note we reserve the right to monitor all e-mail communication through our internal and external networks. SKY and the SKY marks are trademarks of Sky Limited and Sky International AG and are used under licence.

Sky UK Limited (Registration No. 2906991), Sky-In-Home Service Limited (Registration No. 2067075), Sky Subscribers Services Limited (Registration No. 2340150) and Sky CP Limited (Registration No. 9513259) are direct or indirect subsidiaries of Sky Limited (Registration No. 2247735). All of the companies mentioned in this paragraph are incorporated in England and Wales and share the same registered office at Grant Way, Isleworth, Middlesex TW7 5QD

---

From: "Martin Thomson" <[email-masked]>
Date: Sat, 30 Mar 2019 08:48:32 -0400

On Mon, Mar 25, 2019, at 12:37, Paul Hoffman wrote:
> methods given in this document do not offer any authentication. 

There is a different reason that I think is stronger.  We tolerate an exposure on DHCP and other network-layer configuration options (like the v6 RA).  The security implications of those mechanisms are well understood and it is common for networks to deploy systems that limit the opportunity for attacks.  Things like filtering broadcast and RA from end hosts are common.

But the connection to a resolver might be harder to secure in this fashion.  Though it might be possible to narrow the use of unicast port 53 (or 853), such filtering is different.  It is not always the case that the resolver is local in the same way that a DHCP server/relay or gateway is.  For DoH, which might use a service that is completely external to the network, this is more difficult.

Therefore, it is easier to look at this step of the configuration process as being subject to "untrusted" activity and insist on authentication.  It's certainly true that the only basis for authentication is the assertion by the network discovery phase, for which you have no prior expectations.   However, the property we are looking for is that we are talking to the same server that the network intended for us to talk to.  Thus, if the name of the server comes from the same mechanism that gave us an IP address (DHCP), or the system that provides connectivity (RA), then we at least have that much.

If your goal is to talk to the resolver provided by the network, then I believe that to be sufficient.

Hence I would propose a different design for this, bringing DoT into the design.

1. The first step requires no new protocol mechanisms.  To discover DoT, connect to the resolver IP at port 853.  If the server produces a certificate that is valid for the IP address of the resolver, then you are good to proceed.  No new mechanism is required.  (Clients may decide to accept any certificate here if they require opportunistic security, but I would suggest that this is unwise for the aforementioned reasons.  That said, it's better than using Do53, so I'd say it's still worth doing except for the fact that this establishes an expectation on the part of DoT resolvers that having a valid certificate is not required, which is dangerous.)

2. We add a field to DHCP and RA that carries the "DoT resolver".  When this is present, the client resolves this name using the resolver.  This resolution is unsecured.  The client then connects to the resulting IP address and validates the certificate it presents using this name.  This enables easier deployment of DoT because a certificate for a name is easier to get than an IP certificate (it also enables use of 1918 address and the like).

3. We add another field to DHCP and RA that carries the "DoH resolver".  When this is present, the client resolves the associated name using the unsecured resolver.  The client then connects to this endpoint, validates the certificate and proceeds to use DoH.

We could decide not to do the DoT step, but I wanted to include it to illustrate the symmetry of the design.

You will observe that this is significantly simpler than the proposed design.  There are several drawbacks, that I will address:

A. A client in a residential network will not receive this option unless their gateway/relay is configured to relay these values from external network.  The design proposed in the current draft has this property in that the SUDN is forwarded by resolvers that don't understand its purpose.  In this case, endpoints will talk to the DNS proxy in their gateway and not be able to discover a DoH service provided by an ISP.  RFC 5625 points out that it is not generally possible to talk to the external resolver. 

B. This doesn't provide any option for web clients to find the local resolver.  I will separately argue that this is not a valid use case, and moreover that it is one that presents some privacy challenges for clients and networks.  It should not be possible for a web site to be able to use a client's position in the network to access information that it would not otherwise be able to access itself.  Allowing requests to a local resolver might allow access to that sort of information.  Sites are better suited to making requests of configured resolvers.  With DoH, they can make those requests from the client, meaning that the answers will be more suitable for the client's position in the network than their own.  Though this requires that the configured resolver has nodes that are deployed near the client, I believe this to be sufficient.

I think that problem A is pretty significant.  The SUDN option does help there, but it eliminates the weak "authentication" we have.  For anything in this area to work, I think that we would need some other basis for deciding that the DoH server that is identified in this way is OK.  The only idea that I have, which is a poor one, is to configure clients with a list of "trusted" resolvers.  I don't like maintaining these sorts of lists, but it might be the only way to manage it.  No matter what option we choose here, I would prefer that we look at the DHCP/RA steps first.