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

On Fri, Apr 24, 2020 at 11:40 AM Paul Hoffman <paul.hoffman@icann.org>
wrote:

> On Apr 24, 2020, at 11:09 AM, Ben Schwartz <bemasc=
> 40google.com@dmarc.ietf.org> 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.
>

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--
> Add mailing list
> Add@ietf.org
> https://www.ietf.org/mailman/listinfo/add
>