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

Eric Rescorla <ekr@rtfm.com> Tue, 30 June 2020 01:15 UTC

Return-Path: <ekr@rtfm.com>
X-Original-To: add@ietfa.amsl.com
Delivered-To: add@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BAF23A0EFD for <add@ietfa.amsl.com>; Mon, 29 Jun 2020 18:15:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level:
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mdEBcS7WNB1e for <add@ietfa.amsl.com>; Mon, 29 Jun 2020 18:15:46 -0700 (PDT)
Received: from mail-lf1-x12e.google.com (mail-lf1-x12e.google.com [IPv6:2a00:1450:4864:20::12e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8BE833A0EFB for <add@ietf.org>; Mon, 29 Jun 2020 18:15:45 -0700 (PDT)
Received: by mail-lf1-x12e.google.com with SMTP id g139so10344351lfd.10 for <add@ietf.org>; Mon, 29 Jun 2020 18:15:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=cKSN3BCspMQNSp0jThys/4xG+Yb7+eR69rl5qCJIiV8=; b=KXhWf2/RiB9f9Xx1uep+qJ900nL7vr8aDU24Np9ccGlg5duGqG8bZjFO4l4PpVMZs5 otA4t7+cCmPwAf0+HZ38T5XpnvdR3BgRFuMVI6KupE0oYsXOcCXrXIvTobsBSYYJGE/Q AP1UqqtUJplyAWuOfh1ZHNCuGL6opgyYFOHPTcwsZLw7tL7zZGTxQeLKm/8sfrmTfrmR FsSaa0zs9lm+MImxRH1fbCj3uEA6kFJAHrQM+Tcbv2tZ2jO/tpsjR5F/35WpOikJTkx3 pA+YjsZTpE0IhQlvTMJFgdso2k/G9C5auorG2qSM4++xZXEuQKDRVyPFDzKO2b4tW58d NQYg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=cKSN3BCspMQNSp0jThys/4xG+Yb7+eR69rl5qCJIiV8=; b=nD/AavsBWF4YSm9pdC8neWeonIXk9TZnrqCcNB4hc3SbIKG5v6gCt+neZ78rnGq8Uw xcvMPXhB1F8s2VDd/mvo+QN34PHdI3H8pcBg+DGUwP9oZdLvmsXF1o+BABceBUUnvAbW uVSTI8GzfMjHSOno6poetfq66CVjblubljyJ5p2pFwL0ebrgikzb4+r50KweU7wEjTh8 928dC75QP4woV+68dc7G42qylFclw9bJzpeUtAAx4cJBRMsztJNnVwJEAmptV3f/Ompr HZso/hm2wjH4wFMIj1JoXOVA3/7hD/g8Hagy9bUdmL7tTCN/ROewFgkSpacL8oOd6BQ+ 4A6w==
X-Gm-Message-State: AOAM5318tPJGbXrXuQvXYDfvd1Zpv8yjlDrk/aP7Uh3iZ8qw6pIsUUR8 2yjJHhTVdzHSMOofaGD0eisRD5B+VXO37z6Zzn1kow==
X-Google-Smtp-Source: ABdhPJy9O37ojpqsty0/aBfmuZzIHtjOeKDlpkYy81tqAQkyQka8xGZDwXJrieq4uuyy6HPbWYw8jQjpxq7wZpKY+dg=
X-Received: by 2002:ac2:4c2a:: with SMTP id u10mr10488366lfq.168.1593479743597; Mon, 29 Jun 2020 18:15:43 -0700 (PDT)
MIME-Version: 1.0
References: <CABcZeBPTkWeB40wpTowKvEJ-gXA3AL2e-BE+C_FC7Js7-D0DZQ@mail.gmail.com> <14119.1593367594@localhost> <alpine.OSX.2.22.407.2006281428200.79151@ary.qy> <3615321.ADK9YsXCiF@linux-9daj> <CADZyTkm82y=H48e7TL+wBMN67jrCG2T96kHOdovX0Ds3m_nguw@mail.gmail.com> <CABcZeBMRYRoMVLr937=9T4dyVGzGHYapcrTRZ7nYghdAqzhqOQ@mail.gmail.com> <CADZyTknZTcYXb1JbYANh4uk5xgAedNGnM93y9QORJ2vYR5eJxw@mail.gmail.com>
In-Reply-To: <CADZyTknZTcYXb1JbYANh4uk5xgAedNGnM93y9QORJ2vYR5eJxw@mail.gmail.com>
From: Eric Rescorla <ekr@rtfm.com>
Date: Mon, 29 Jun 2020 18:15:07 -0700
Message-ID: <CABcZeBOqZLpJ1_2-wFae3bM2RvrnA1z++swxfq7xc8E7Ny5ZfQ@mail.gmail.com>
To: Daniel Migault <mglt.ietf@gmail.com>
Cc: Paul Vixie <paul@redbarn.org>, Michael Richardson <mcr+ietf@sandelman.ca>, ADD Mailing list <add@ietf.org>, John R Levine <johnl@taugh.com>
Content-Type: multipart/alternative; boundary="00000000000013a97505a942ea05"
Archived-At: <https://mailarchive.ietf.org/arch/msg/add/5iyCnMVi5PfIVv5NFZKevDWmznk>
Subject: Re: [Add] [Ext] Draft Posting: CNAME Discovery of Local DoH Resolvers
X-BeenThere: add@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Applications Doing DNS <add.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/add>, <mailto:add-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/add/>
List-Post: <mailto:add@ietf.org>
List-Help: <mailto:add-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/add>, <mailto:add-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 30 Jun 2020 01:15:48 -0000

On Mon, Jun 29, 2020 at 5:43 PM Daniel Migault <mglt.ietf@gmail.com> wrote:

>
>
> On Mon, Jun 29, 2020 at 7:15 PM Eric Rescorla <ekr@rtfm.com> wrote:
>
>>
>>
>> On Mon, Jun 29, 2020 at 2:40 PM Daniel Migault <mglt.ietf@gmail.com>
>> 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.

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.

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