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

[Paul Hoffman <[e-mail]>]

On Apr 24, 2020, at 11:09 AM, Ben Schwartz <bemasc=[e-mail]> 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