Re: [Add] [Ext] Draft Posting: CNAME Discovery of Local DoH Resolvers

[Daniel Migault <[e-mail]>]

On Mon, Jun 29, 2020 at 9:15 PM Eric Rescorla <[e-mail]> wrote:

>
>
> On Mon, Jun 29, 2020 at 5:43 PM Daniel Migault <[e-mail]>
> wrote:
>
>>
>>
>> On Mon, Jun 29, 2020 at 7:15 PM Eric Rescorla <[e-mail]> wrote:
>>
>>>
>>>
>>> On Mon, Jun 29, 2020 at 2:40 PM Daniel Migault <[e-mail]>
>>> wrote:
>>>
>>>> Hi,
>>>>
>>>> I believe the proposal presents some
>>>> similarities to draft-mglt-drdp [1] that is
>>>> using the DNS to proceed to the
>>>> discovery. I see drdp as more generic,
>>>> and would be happy to improve it.
>>>>
>>>> I would be happy to understand why HTTP
>>>> is a better stack to perform the
>>>> discover as opposed to DNS. I think that
>>>> DNS is better as it is the common
>>>> protocol to DoT DoH and DNS, but I might
>>>> be missing something.
>>>>
>>>
>>> I don't quite follow this, as we do not use HTTP.
>>>
>> I thought you were saying using HTTPSSVC was architecturally better
>> - that was section 5 not 4.
>>
>
> Well, S 5 is an empty IANA Considerations section.
>
that was section 5 of adns

>
> In any case, I don't really have a position on whether HTTPSVC is better.
> The text says it "may be" the right answer eventually.
>
>
> I believe that CNAME is to restrictive
>>>> and would not make possible for example
>>>> to have multiple resolvers
>>>>
>>>
>>> This goes back to use case. In our use case, the multiple resolvers
>>> would be supplied by manual configuration of the client. the CNAME is just
>>> a lookup key.
>>>
>>
>> Unless I am missing something, I do not see how the ISP could respond
>> saying and provide the application a resolver that implements DoH, a
>> resolver that implement DoTs, a resolver that implements DoH and DNSSEC
>> validation and let the application pick the one it prefers.
>>
>
> That's correct. As I said, that's not part of our use case, because we're
> only trying to determine which network you are on and then look up the
> resolvers in our TRR list. If we expected ISPs to have >1 kind of resolver
> we'd probably just have them register them all with us and then incorporate
> the list into the binary. I appreciate that this won't work well for many,
> but as I said, this mechanism is targeted at quite a narrow use case.
>
>
>>
>>>
>>>> CNAME does not provide useful necessary
>>>> parameters that may also be useful for a
>>>> DoH resolver DRDP lists among others:
>>>> alpn, ensiconfig, uri template, user
>>>> display, auth_domain, filtering,
>>>> ip_subnet, dnssec, ....
>>>>
>>>> My understanding is that BCP 17 saw SRV
>>>> as a long term solution for CNAME which
>>>> is now superseded by HTTPSVC/SVCB. I see
>>>> SRV as very common in home networks with
>>>> service discovery.
>>>>
>>>> I believe that using a generic is
>>>> problematic as is prevents its resoltion
>>>> to be secured with DNSSEC.
>>>>
>>>
>>> As I said earlier, this goes back to threat model. Please describe the
>>> thrat model where you think DNSSEC helps.
>>>
>>
>> The threat model seems for Comcast and the end user having the traffic of
>> its end users being redirected to Cloudflare instead of the local resolver.
>> Both resolvers are trusted according to Firefox but the end user and the
>> ISP may have a different view. It also means that any information that is
>> not preconfigured cannot be trusted.
>>
>
> Well, I agree that this attack is possible (and is described in S 4) but I
> don't see how DNSSEC prevents it. It's true that if the user is on a
> network operated by "example.com" DNSSEC could be used to secure the
> information that "example.com" wants you to use a given resolver, but the
> problem is that the user has no secure way of discovering that they are on "
> example.com", and therefore the attacker can just substitute in their own
> domain there.
>
If the lookup takes as input the IP addresses or something provided by the
ISP (like the local resolver IP address), the resulting chain is likely to
be from the ISP. DNSSEC is needed to assert it. Another way would be to be
able to display example.com. The user should be able to see how the domain
is associated to the ISP it has subscribed to or if it is being redirected
to a cloud provider.  DNSSEC would make sur the corresponding IP address -
as well as other information - are bound to the displayed domain.

>
> I could of course be wrong about this. If you believe I am, I would
> encourage you to describe the entire discovery chain and where you believe
> DNSSEC acts to prevent attack.
>
> -Ekr
>
>

-- 
Daniel Migault
Ericsson