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

[Ben Schwartz <[e-mail]>]

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 <[e-mail]> wrote:

>
>
> On Fri, Apr 24, 2020 at 12:16 PM Mike Bishop <[e-mail]> 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 <[e-mail]> *On Behalf Of * Eric Rescorla
>> *Sent:* Friday, April 24, 2020 2:54 PM
>> *To:* Paul Hoffman <[e-mail]>
>> *Cc:* Ben Schwartz <bemasc=[e-mail]>; ADD Mailing
>> list <[e-mail]>
>> *Subject:* Re: [Add] [Ext] Drafts on upgrading stub-to-resolver
>> communication to encrypted
>>
>>
>>
>>
>>
>>
>>
>> On Fri, Apr 24, 2020 at 11:40 AM Paul Hoffman <[e-mail]>
>> wrote:
>>
>> 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.
>>
>>
>>
>> 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
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/add
>>
>>