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

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 <kondtir@gmail.com> wrote:

> Are you planning to replace
> https://tools.ietf.org/html/draft-ietf-dnsop-resolver-information-01 with
> draft-pp-add-resinfo ?
>
> -Tiru
>
> On Fri, 24 Apr 2020 at 22:16, Paul Hoffman <paul..hoffman@icann.org
> <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
>> https://www.ietf.org/mailman/listinfo/add
>>
> --
> Add mailing list
> Add@ietf.org
> https://www.ietf.org/mailman/listinfo/add
>