Subject: [Add] Drafts on upgrading stub-to-resolver communication to encrypted

From: Paul Hoffman <[email-masked]>
Date: Fri, 24 Apr 2020 16:45:29 +0000

Greetings again. We have just published two drafts, draft-pp-add-stub-upgrade and draft-pp-add-resinfo, to address the easier problem that this WG wanted to tackle, namely how a stub can upgrade from plain DNS to encrypted DNS for the resolver it is currently using. The method in draft-pp-add-stub-upgrade is quite simple, but it includes all of the variables that we have heard in the discussion over the last year. The format in draft-pp-add-resinfo is the minimum needed for stub upgrade, but will also possibly be useful for the more difficult discovery protocols being discussed in the WG.

Please let us know if you find these documents useful for the discussion of direct upgrade instead of discovery. Also, please let us know if we have missed any salient points. If so, we could ask the chairs to make these into WG documents.

--Paul Hoffman and Puneet Sood

https://datatracker.ietf.org/doc/draft-pp-add-stub-upgrade/

Name:		draft-pp-add-stub-upgrade
Revision:	00
Title:		Upgrading Communication from Stub Resolvers to DoT or DoH
Document date:	2020-04-24
Group:		Individual Submission
Pages:		7

Abstract:
  This document describes methods for a DNS stub resolver to upgrade
  its communications with a known recursive resolver to include
  encrytion using DoT or DoH.  This protocol is designed for the
  scenario where the stub resolver already has the IP address of the
  recursive resolver.

  Other protocols under develpment address scenarios where the stub
  resolver wants to discover recursive resolvers that use DoT or DoH.
  This document does not cover such discovery.

https://datatracker.ietf.org/doc/draft-pp-add-resinfo/

Name:		draft-pp-add-resinfo
Revision:	00
Title:		DNS Resolver Information Self-publication
Document date:	2020-04-24
Group:		Individual Submission
Pages:		9

Abstract:
  This document describes methods for DNS resolvers to self-publish
  information about themselves.  The information is returned as a JSON
  object.  The names in this object are defined in an IANA registry
  that allows for light-weight registration.  Applications and
  operating systems can use the methods defined here to get the
  information from resolvers in order to make choices about how to send
  future queries to those resolvers.

---

From: Ben Schwartz <[email-masked]>
Date: Fri, 24 Apr 2020 14:09:01 -0400

Thanks for the updated drafts.  I think RESINFO is the most promising path
for resolver upgrade, and I'd like to see it implemented.

The one major change I suggest is to remove the entire HTTPS mechanism from
the RESINFO draft.  This mechanism creates a great deal of complexity,
doesn't follow good practices for HTTPS, and doesn't obviously enable any
additional use cases.  Having multiple competing mechanisms also makes
interoperability less likely.

If "in-band" RESINFO proves insufficient, an HTTPS-based mechanism could
always be added in a later draft.

On Fri, Apr 24, 2020 at 12:46 PM Paul Hoffman <[email-masked]>
wrote:

> Greetings again. We have just published two drafts,
> draft-pp-add-stub-upgrade and draft-pp-add-resinfo, to address the easier
> problem that this WG wanted to tackle, namely how a stub can upgrade from
> plain DNS to encrypted DNS for the resolver it is currently using. The
> method in draft-pp-add-stub-upgrade is quite simple, but it includes all of
> the variables that we have heard in the discussion over the last year. The
> format in draft-pp-add-resinfo is the minimum needed for stub upgrade, but
> will also possibly be useful for the more difficult discovery protocols
> being discussed in the WG.
>
> Please let us know if you find these documents useful for the discussion
> of direct upgrade instead of discovery. Also, please let us know if we have
> missed any salient points. If so, we could ask the chairs to make these
> into WG documents.
>
> --
> Add mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/add
>

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 24 Apr 2020 18:39:18 +0000

On Apr 24, 2020, at 11:09 AM, Ben Schwartz <bemasc=[email-masked]> wrote:
> 
> Thanks for the updated drafts.  I think RESINFO is the most promising path for resolver upgrade, and I'd like to see it implemented.
> 
> The one major change I suggest is to remove the entire HTTPS mechanism from the RESINFO draft.  This mechanism creates a great deal of complexity, doesn't follow good practices for HTTPS, and doesn't obviously enable any additional use cases.  Having multiple competing mechanisms also makes interoperability less likely.

The additional use case that was brought up in earlier work is that a stub that wants to do DoH.
- It does not need to know how to make requests for a new DNS RRtype
- It can use HTTPS as it knows it
- It can get a response that can be authenticated

I understand the desire not to allow unauthenticated HTTPS because of best practices. We can remove that from the draft, but then implementers will likely go ahead and implement it anyway but without guidance about the results. Note that we are only talking about unauthenticated HTTPS *for this one use*, not in general.

> If "in-band" RESINFO proves insufficient, an HTTPS-based mechanism could always be added in a later draft.

Some people said it was insufficient because of inability to authenticate.

--Paul Hoffman

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 24 Apr 2020 11:53:53 -0700

On Fri, Apr 24, 2020 at 11:40 AM Paul Hoffman <[email-masked]>
wrote:

> > Thanks for the updated drafts.  I think RESINFO is the most promising
> path for resolver upgrade, and I'd like to see it implemented.
> >
> > The one major change I suggest is to remove the entire HTTPS mechanism
> from the RESINFO draft.  This mechanism creates a great deal of complexity,
> I understand the desire not to allow unauthenticated HTTPS because of best
> practices. We can remove that from the draft, but then implementers will
> likely go ahead and implement it anyway but without guidance about the
> results. Note that we are only talking about unauthenticated HTTPS *for
> this one use*, not in general.
>

But the HTTPS mechanism is unauthenticated as well. And even if people do
use IP certs, then they mechanism by which they get the IP is largely
unauthenticated.

I agree with Ben; this  mechanism should be removed.

-Ekr

> --Paul Hoffman--

---

From: Mike Bishop <[email-masked]>
Date: Fri, 24 Apr 2020 19:08:27 +0000

I also think RESINFO looks promising.  Publishing DoT and/or DoH endpoints on that resolver seems the obvious next step, and I was surprised that the document didn’t define elements to declare those capabilities.  The DNS record piece seems useful for recursive-to-authoritative as well.  If we permit RESINFO records for other names, an authoritative delegation could pass along the RESINFO of the name server it’s delegating to.

The attractions of the HTTPS option are multiple, particularly for stub-to-resolver.  One is a way to validate the connection to the resolver that you think you’re talking to, of course.  Removing the HTTPS option means you’re just trying the endpoints and seeing if they work, which is sub-optimal.  Further, if (as seems likely) the DoH endpoint is at the same host and port, you’ve already established an HTTPS session which could be used to perform DoH, as described in stub-upgrade.  It also enables you to probe a DoH URI you’ve received elsewhere to ensure that the server actually intends to offer DoH at that URI; while you’d expect a DoH request to fail if not, establishing consent is generally a good idea.  I’d be inclined to keep it, all told.

From: Add <[email-masked]> On Behalf Of Ben Schwartz
Sent: Friday, April 24, 2020 2:09 PM
To: Paul Hoffman <[email-masked]>
Cc: ADD Mailing list <[email-masked]>
Subject: Re: [Add] Drafts on upgrading stub-to-resolver communication to encrypted

On Fri, Apr 24, 2020 at 12:46 PM Paul Hoffman <[email-masked]<mailto:[email-masked]>> wrote:
Greetings again. We have just published two drafts, draft-pp-add-stub-upgrade and draft-pp-add-resinfo, to address the easier problem that this WG wanted to tackle, namely how a stub can upgrade from plain DNS to encrypted DNS for the resolver it is currently using. The method in draft-pp-add-stub-upgrade is quite simple, but it includes all of the variables that we have heard in the discussion over the last year.. The format in draft-pp-add-resinfo is the minimum needed for stub upgrade, but will also possibly be useful for the more difficult discovery protocols being discussed in the WG.

Abstract:

Abstract:

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

---

From: Mike Bishop <[email-masked]>
Date: Fri, 24 Apr 2020 19:16:37 +0000

Hijacking a connection requires being able to subvert connections from that client and spoof the destination IP address.  Getting an IP certificate would require doing that, not from one client’s vantage, but from every vantage the CA chooses to test from.  If the CA tests from multiple vantage points, the IP certificate is a stronger assertion than simply being able to accept your connection.

But let’s say we remove the HTTPS path.  What do we do instead?  Do53 is unencrypted and just as unauthenticated.  Speculative DoT is just as unauthenticated, since either you’ll validate against an IP certificate or take whatever certificate is there.  For the time being, all bootstrapping requires an element of trust.  I don’t dispute the weaknesses you point out; I simply don’t see that we’ve found a better alternative.

From: Add <[email-masked]> On Behalf Of Eric Rescorla
Sent: Friday, April 24, 2020 2:54 PM
To: Paul Hoffman <[email-masked]>
Cc: Ben Schwartz <bemasc=[email-masked]>; ADD Mailing list <[email-masked]>
Subject: Re: [Add] [Ext] Drafts on upgrading stub-to-resolver communication to encrypted

On Fri, Apr 24, 2020 at 11:40 AM Paul Hoffman <[email-masked]<mailto:[email-masked]>> wrote:

But the HTTPS mechanism is unauthenticated as well. And even if people do use IP certs, then they mechanism by which they get the IP is largely unauthenticated.

-Ekr

--Paul Hoffman--
Add mailing list

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 24 Apr 2020 12:28:38 -0700

On Fri, Apr 24, 2020 at 12:16 PM Mike Bishop <[email-masked]> wrote:

> Hijacking a connection requires being able to subvert connections from
> that client and spoof the destination IP address.
>

My assumption was that you would forge the DHCP message that gave the
client the IP.

Getting an IP certificate would require doing that, not from one client’s
> vantage, but from every vantage the CA chooses to test from.  If the CA
> tests from multiple vantage points, the IP certificate is a stronger
> assertion than simply being able to accept your connection.
>

Agreed.

But let’s say we remove the HTTPS path.  What do we do instead?  Do53 is
> unencrypted and just as unauthenticated.  Speculative DoT is just as
> unauthenticated, since either you’ll validate against an IP certificate or
> take whatever certificate is there.  For the time being, all bootstrapping
> requires an element of trust.  I don’t dispute the weaknesses you point
> out; I simply don’t see that we’ve found a better alternative.
>

Oh, I agree with that. My proposal is that we just admit that this is
unauthenticated and live with it until we have an E2E story.

-Ekr

>
> *From:* Add <[email-masked]> *On Behalf Of * Eric Rescorla
> *Sent:* Friday, April 24, 2020 2:54 PM
> *To:* Paul Hoffman <[email-masked]>
> *Cc:* Ben Schwartz <bemasc=[email-masked]>; ADD Mailing list
> <[email-masked]>
> *Subject:* Re: [Add] [Ext] Drafts on upgrading stub-to-resolver
> communication to encrypted
>
>
>
>
>
>
>

---

From: Ben Schwartz <[email-masked]>
Date: Fri, 24 Apr 2020 19:12:52 -0400

Maintaining authentication where it already exists is important.
Introducing authentication where it does not exist is at best difficult.

Currently, any client that identifies its DNS server by IP address has no
authentication, whether or not that IP address is known to the user.  I
don't think we should try to fix that in this draft, especially if it adds
complexity.

As an example of authenticated servers, the only way for an Android user to
explicitly activate DNS over TLS is to specify a server by hostname.  (IP
addresses are not allowed).  That's a case where authentication exists, and
RESINFO maintains it correctly.  With RESINFO, a DNS client on Android
could use the validated DoT channel to discover corresponding DoH endpoints
securely.

I think this is likely to be the pattern of the future.  In cases where
stub resolvers (or forwarders) are intended to use secure DNS, the server
will be specified with a hostname, not just an IP address.

On Fri, Apr 24, 2020 at 3:29 PM Eric Rescorla <[email-masked]> wrote:

>> *Cc:* Ben Schwartz <bemasc=[email-masked]>; ADD Mailing
>> list <[email-masked]>
>> I understand the desire not to allow unauthenticated HTTPS because of
>> best practices. We can remove that from the draft, but then implementers
>> will likely go ahead and implement it anyway but without guidance about the

---

From: Vittorio Bertola <[email-masked]>
Date: Mon, 27 Apr 2020 16:55:19 +0200 (CEST)

> Il 24/04/2020 18:45 Paul Hoffman <[email-masked]> ha scritto:
> 

Thanks for doing this and I support adoption at least for the resinfo draft.

On the resinfo draft, I want to support other comments saying that the HTTP-based mechanism should be removed. As an implementer, having two alternative methods means that you possibly have to implement and maintain both, doubling the work and the potential number of issues. 

I get the point that some clients already speak HTTPS and so why not use it, but there is the other point that all resolvers must speak DNS, so using DNS is the easiest path to widespread implementation on the server side. Not all resolvers will support DoH, so they would have to implement and run an HTTP server just to answer possible discovery queries, since there is no guarantee that even a client willing to speak DoT or DNS will not use the HTTP-based discovery mechanism. 

Even resolver platforms that implement DoH are often doing so by adding a separate layer of front-end HTTP termination servers that convert the messages into DNS queries to the actual resolver, so the resolver itself does not run an HTTP server over its own IP address (the one that the user's system already knows and that would go into the well-known URI), and would have to add one just to this purpose.

Moreover, while the DNS-based mechanism can work with forwarders, including home network CPEs, the HTTP-based one would end up making the request not to the actual resolver but to the CPE. This would entail modifying all CPEs (which is a daunting task that takes years in most big operator environments) and having them relay the HTTP request in some way to the resolver platform (which needs to be implemented).

The DNS-based mechanism, instead, is much more straightforward - it automatically follows the same path that the queries will follow, and so it will reach the correct resolver. Thanks for removing the reverse IP address in the queried domain name, which created problems in the CPE scenario above. I would still like to hear opinions on the classic "new RRTYPE vs TXT record" discussion, as I do not know whether adopting a new RRTYPE would hinder quick support, while TXT records can safely work right now almost in any scenario.

Regarding the second draft: I think it would benefit from a presentation before commenting. Anyway, I was a bit surprised by the fact that it seems to prescribe an algorithm (though configurable) for clients to decide which transport to use. I would rather expect a mechanism that allows clients to retrieve a known unencrypted resolver's equivalent DoT and/or DoH endpoints, through any of the methods supported in draft-resinfo (though, as I said, I really hope we will just end up with the DNS one), and then, what the client does with that information is none of our business.

Anyway, thanks for the work and I look forward to more discussion.

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

---

From: tirumal reddy <[email-masked]>
Date: Tue, 28 Apr 2020 19:49:30 +0530

Are you planning to replace
https://tools.ietf.org/html/draft-ietf-dnsop-resolver-information-01 with
draft-pp-add-resinfo ?

-Tiru

---

From: Eric Orth <[email-masked]>
Date: Tue, 28 Apr 2020 10:59:02 -0400

I generally support both documents and would support ADD adoption.

Re draft-pp-add-stub-upgrade: I do worry that it goes a little bit too far
into "policy" in laying out a specific algorithm, even if it's full of
options to allow clients to choose their own behavior.  Might be better if
framed more explicitly as a "descriptive example" rather than the
prescriptive way to implement it.  But I find the draft overall helpful
just for clearly laying out both the opportunistic DoT and the DoH resinfo
tag.

Re draft-pp-add-resinfo: Definitely think this is the best overall draft we
have for the common problem of retrieving resolver information.  I'm
personally conflicted on the HTTP-based mechanism.  Others have made some
solid arguments against it already in this thread, but I would be sad to
lose our best option for a secure mechanism.  It's correct that the DNS IP
address typically comes from insecure DHCP, but in many cases that is only
exposed on the limited local network or maybe the IP was set on the machine
rather than using DHCP, so the resinfo messages could sometimes (often?)
have a much bigger exposure.  Then again, since the internet seems not
quite ready for CAs to widely give certs for IP addresses, maybe it would
be best to remove it from this draft and create a new draft in the future
once the mechanism becomes more viable.

On Tue, Apr 28, 2020 at 10:19 AM tirumal reddy <[email-masked]> wrote:

> On Fri, 24 Apr 2020 at 22:16, Paul Hoffman <[email-masked]
> <[email-masked]>> wrote:
>

---

From: Eric Orth <[email-masked]>
Date: Tue, 28 Apr 2020 11:05:48 -0400

And another point regarding DNS vs HTTP mechanisms: Is there any concerns
regarding clients with DoH/DoT stubs but that rely on getaddrinfo() from
the system for Classic DNS? Would HTTP be more palatable for those clients?
Then again, if a client has a full DoH/DoT implementation, maybe easier for
them to add a Classic DNS implementation than it would be for many
recursives to add an HTTPS server.

On Tue, Apr 28, 2020 at 10:59 AM Eric Orth <[email-masked]> wrote:

> Re draft-pp-add-resinfo: Definitely think this is the best overall draft
> we have for the common problem of retrieving resolver information.  I'm
>> https://tools.ietf.org/html/draft-ietf-dnsop-resolver-information-01
>> with draft-pp-add-resinfo ?
>>
>> -Tiru
>>