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

Eric Rescorla <ekr@rtfm.com> Sat, 27 June 2020 00:36 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 20F083A08E6 for <add@ietfa.amsl.com>; Fri, 26 Jun 2020 17:36:43 -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 q6wPTGcAXHMs for <add@ietfa.amsl.com>; Fri, 26 Jun 2020 17:36:40 -0700 (PDT)
Received: from mail-lf1-x133.google.com (mail-lf1-x133.google.com [IPv6:2a00:1450:4864:20::133]) (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 673203A0820 for <add@ietf.org>; Fri, 26 Jun 2020 17:36:40 -0700 (PDT)
Received: by mail-lf1-x133.google.com with SMTP id o4so6082589lfi.7 for <add@ietf.org>; Fri, 26 Jun 2020 17:36:40 -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=d6Fa56m7GOr2Ih87QoCDKCTmgeI2qJCoJ1740+OG6wc=; b=EePKAS2C9UXMVf451OAZp+dgjXKNEJNOuGASv1lAaWLj8kCmnFxUOPd5MCY5TE1TFV PMh+u+yHsklvy7QitKC2Lw/bDISlV7XPV1SjFyP+grBVNSO5iYlSEFtw91OAgFGz4/kD /27PvyqoR+5oNPyXJ1+XpE3GAYTnoj4qczQt6uZa8r014R7h1NubxjLBhPU9CFnxdban R7Myfa0aG77QeoUPDhJPH0y0dtKcZgfl+7eCrQO8VeuXlvPVnWpKfM5xd9lyLqw8FiCt fMSq21Z0tUb1t5mjLO0tNQn6XiKZiQ9oVriz+JLq7n/1eYUHn9VtdNOkOiDujKXfnsaq +Xbw==
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=d6Fa56m7GOr2Ih87QoCDKCTmgeI2qJCoJ1740+OG6wc=; b=JqJ94J7/6lKd6iTmXOW/Csx5eVwSxobD73Q7ZwO60VoVumXxk77J7v4qzYpljOyp/I nIABYRmYpqtowNGMARDlKj793qsuSPX/tFFqdLtUvFa5lvXMrO39EmlcskxHx6L+zMQh nNovOlwCYkdfZqUjSDsZuLBGa0lHeagnvU0Aw+sMhwMAHtv3dZlIJeAlVOx90DGqmrxt X8WM9LuvWTw6kRlKcBzsTd8LpDmSipJqDqN3Du6t8ktOCb2kP4UWE4YerwXJdCdHuyGN VL1HqAfbE9oBdwDSRIdBWMjWmG1VfcsY6B6396dwT6jKEmb4pmPXzfccrUYPwYweoo7u PIVA==
X-Gm-Message-State: AOAM531zj29744bP1Xm4LBKEnsq1HR9oA0KX0O43WqlMfMO8iDXMNv4V 5ZGbMHffw44YVBrMSp7JAT4hsZ3KU/FRW8sgzNtUTw==
X-Google-Smtp-Source: ABdhPJzhyo/f4HK6beiJK9yCYqQ1SSM3NQvjqH/tolAl7libQ2L6cpQu298w9JOliJD2kHcJrsYaowxWepDoaOzl1nQ=
X-Received: by 2002:ac2:5226:: with SMTP id i6mr3305273lfl.55.1593218198451; Fri, 26 Jun 2020 17:36:38 -0700 (PDT)
MIME-Version: 1.0
References: <CABcZeBPTkWeB40wpTowKvEJ-gXA3AL2e-BE+C_FC7Js7-D0DZQ@mail.gmail.com> <0478F516-47AE-419E-B95D-F546A2F12ABB@icann.org>
In-Reply-To: <0478F516-47AE-419E-B95D-F546A2F12ABB@icann.org>
From: Eric Rescorla <ekr@rtfm.com>
Date: Fri, 26 Jun 2020 17:36:02 -0700
Message-ID: <CABcZeBPMrn_H8EQfw3ksLnsMJd21=BTZ3h29g-rMnKO2SUJOFw@mail.gmail.com>
To: Paul Hoffman <paul.hoffman@icann.org>
Cc: ADD Mailing list <add@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000c4d5ca05a9060451"
Archived-At: <https://mailarchive.ietf.org/arch/msg/add/H_-MgPfSzi4hso77MeCylcZrK2k>
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: Sat, 27 Jun 2020 00:36:43 -0000

On Fri, Jun 26, 2020 at 4:11 PM Paul Hoffman <paul.hoffman@icann.org> wrote:

> On Jun 25, 2020, at 7:05 AM, Eric Rescorla <ekr@rtfm.com> wrote:
>
> > As has been noted previously, the current Firefox DoH/TRR design
> > bypasses the ISP resolver even if the ISP resolver supports DoH.
> >
> > I have just posted draft-rescorla-doh-cdisco-00, which describes a
> > CNAME-based mechanism for discovering when a local resolver supports
> > DoH/TRR. Firefox can then determine whether that resolver is on the
> > TRR list and if so can use it in preference to generic resolver.. The
> > use of CNAME was chosen for pragmatic reasons (laid out in the draft).
> > We're studying other designs but thought it would be a good idea
> > to document this one.
> >
> > See:
> https://www.ietf.org/internet-drafts/draft-rescorla-doh-cdisco-00.txt
>
> A particular relevant part of this draft for this WG is:
>
> 3.2.  Why a CNAME?
>
>    Most other proposed designs (e.g., [I-D.pp-add-resinfo] and
>    [I-D.pp-add-stub-upgrade], and [I-D.pauly-add-resolver-discovery])
>    use new RRtypes.  While this may be the right answer eventually, it
>    is less convenient for immediate deployment, for several reasons:
>
>    1.  It is somewhat more difficult (though not impossible) to look up
>        new RRTypes on the client and provision them on the ISP resolver.
>
>    2.  Some consumer-grade middleboxes (e.g., WiFI routers) may block
>        unknown RRTypes.  The data here is quite old and limited, but
>        still not particularly promising.
>
>    The choice to use a CNAME does have one major drawback: it does not
>    let us provide the URL template but only the name of the resolver.
>    This is not a problem for our system in practice because Firefox will
>    only connect to resolvers on a preconfigured list and thus will use
>    the CNAME as a lookup key for that list.  The Mozilla team is working
>    to measure the rate of new RRType interference and may revise this
>    approach depending on the results of that.
>
>    [[OPEN ISSUE: We are working to measure the rate of new RRType
>    interference and may revise this approach depending on the results of
>    that.]]
>
> Point 1 feels overstated. The clients we are talking about here are modern
> web browsers, which can clearly write whatever they want in their DNS
> queries.


"clearly" is doing a lot of work here. Sure, it's just software so we could
do this. However, Firefox uses the system resolver and in particular calls
getaddrinfo(). So while yes, we could in theory write our own resolver or
plumb to the OS-specific more flexible interfaces (e.g. res_query()) up to
the part of the code that needs this information. Hence, as I said,
"somewhat more difficult (though not impossible)".


I cannot imagine that an ISP resolver that has to also act as an
> authoritative server would have any restriction on what RRtypes they can
> provision.
>

I do not operate such a resolver so I cannot speak to this point.


Point 2 is interesting, and I'm glad to hear that Mozilla and Apple are
> looking into it. The key part of that is what is "unknown" to any such
> middlebox. The research should definitely look at whether CNAME is in the
> list of unknown RRtypes, given that stub resolvers rarely send CNAME
> queries.
>
> The major drawback that is listed does indeed seem major for use cases
> other than Mozilla's TRR. This WG has been discussing other use cases, so
> it feels restrictive to consider a solution that is focused on just that
> one use case unless the middlebox problem is shown to be crippling to the
> use of new and more flexible RRtypes.
>

We haven't asked the WG to consider this draft. As I said in my message, we
thought it would be useful to document it, hence the draft.

-Ekr