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

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 <add-bounces@ietf.org> On Behalf Of Ben Schwartz
Sent: Friday, April 24, 2020 2:09 PM
To: Paul Hoffman <paul.hoffman@icann.org>
Cc: ADD Mailing list <add@ietf.org>
Subject: Re: [Add] Drafts on upgrading stub-to-resolver communication to encrypted

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 <paul.hoffman@icann.org<mailto:paul.hoffman@icann.org>> 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.

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

--
Add mailing list
Add@ietf.org<mailto:Add@ietf.org>
https://www.ietf.org/mailman/listinfo/add