Re: [Add] New draft: draft-pauly-add-resolver-discovery

Ben Schwartz <bemasc@google.com> Wed, 27 May 2020 01:03 UTC

Return-Path: <bemasc@google.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 D25753A0C94 for <add@ietfa.amsl.com>; Tue, 26 May 2020 18:03:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.599
X-Spam-Level:
X-Spam-Status: No, score=-17.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 JZquFgU_PF3k for <add@ietfa.amsl.com>; Tue, 26 May 2020 18:03:32 -0700 (PDT)
Received: from mail-wr1-x42b.google.com (mail-wr1-x42b.google.com [IPv6:2a00:1450:4864:20::42b]) (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 9B81A3A0C8F for <add@ietf.org>; Tue, 26 May 2020 18:03:31 -0700 (PDT)
Received: by mail-wr1-x42b.google.com with SMTP id j16so9894875wrb.7 for <add@ietf.org>; Tue, 26 May 2020 18:03:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=CA2ApZfeRQls2GkE9yVUtmPIYqXBkmsAOYz96zTIevE=; b=LAb0ElGYBbD9AcUBn5FKBVgaUs9lvqiaNFULqN7Vpatj14IwUUiCaJB63RJxLKBkzI Gjfgbk3xO8zrY0ZLtCYw6stjC5oND12YPxvA3V1zMYHIYyCEgfNp8Ofdf9CXOaszgv8N mkdK67uPdECDpNUF5NK++Svf8nXXUO/Ofh2Ldh28nrGu5+sTR/po91aJ+vuugDPUtvuF 3GIQ4JvbR/XPiv2Xc3o3XyWSCn33abGpf/3N92ne6kZGdXeMYGWIUCtDFXlC45FUmeG3 mjnN4rT4V27F5XDlTsbmfRJp4VD9nHrbQnaHW7KjPlOYgVyD1uhrw0tBmxAH9Qsr3Sjh SRhQ==
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=CA2ApZfeRQls2GkE9yVUtmPIYqXBkmsAOYz96zTIevE=; b=PZ0HYYMELFukHwl9956+uKNI+AdOf3BDRDKxyn0tjqWMzn7jyApok1XKPzfaJ0humB ZbBaPPEFT1JwzEyS1RXCr5VE4XCmfMfJLYdl6+PXWt8jfRI+vXB51eveTrahOIr5d+al hDQKhw+Xh0fjeu+pNeGaUpRCLnUkUmf5O1ZJVrAKKInd+5FfF5192RTjgmYKZ8kGAuuc PgjmLyqcRVlPLAP1HT0/tWEAsza1RpN7WMmulOtZemm1zWenWghe11waiGQ94pLVFLGO c9d8vIzpUZy+HHgBCPwaBmFQozj7OMAjw754Zw9rsjYILYkmnngSE92zyxMh+y9NB447 U+dw==
X-Gm-Message-State: AOAM531hC5ZjR7MIujqAug7ywgcm5/93WWOtoe8in0fZN0LMdGrAGrR4 O6dcxldli/iC1kfl2ke4CEBzkLySxxDXUwTkxIjYFH4l72ESpQ==
X-Google-Smtp-Source: ABdhPJzM63Z+kyb8pw+DEFN0sI3RIlgCJhdM5/1xpCga90CB1GBhQDKDjbizsZ1odC9wWXblrIQ69ikOPkFdDM+WXZw=
X-Received: by 2002:adf:814a:: with SMTP id 68mr22526776wrm.177.1590541409729; Tue, 26 May 2020 18:03:29 -0700 (PDT)
MIME-Version: 1.0
References: <BC307608-2AC0-4A4A-804C-C9C59DA7EE1D@apple.com>
In-Reply-To: <BC307608-2AC0-4A4A-804C-C9C59DA7EE1D@apple.com>
From: Ben Schwartz <bemasc@google.com>
Date: Tue, 26 May 2020 21:03:17 -0400
Message-ID: <CAHbrMsC6HAUOE5r2PTJwGdtZWxBr3Sj-g1asWHoRK3_H+c54iQ@mail.gmail.com>
To: Tommy Pauly <tpauly=40apple.com@dmarc.ietf.org>
Cc: ADD Mailing list <add@ietf.org>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="000000000000c3b50f05a696c7cc"
Archived-At: <https://mailarchive.ietf.org/arch/msg/add/nBdOpGIdgmu9JshTS8DbkoF_AqM>
Subject: Re: [Add] New draft: draft-pauly-add-resolver-discovery
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: Wed, 27 May 2020 01:03:34 -0000

Thanks for making a simplified form of the proposal to get started.

Section 3.1:

How do you expect TTLs to work?  If the dohuri expires along with the SVCB
record that delivered it, is that actually useful?

More generally, I think this section is extremely close to
https://tools.ietf.org/html/draft-tapril-ns2-00, which is trying to
enable recursive->authoritative DoH.  We should aim for a unified, or at
least coordinated solution to these closely related problems.

Section 3.2:
>   Designated Resolvers that support DoH SHOULD provide a PvD JSON
>   dictionary available at the well-known PvD URI with the path of the
>   DoH server's URI template appended.

Strictly speaking, "https://example.com{/dns}/foo?bar=baz" is a valid DoH
URI template, but it doesn't have a well-defined path.  I think the best
option is probably to encode all DoH PvDs on one origin into a single JSON
object at a fixed well-known location, with the full template as the
top-level key.

With dnsZones, is the idea to enable authenticated split-horizon networks?
The PvD draft defines "dnsZones" but offers no explanation of its
semantics, so I'm having trouble figuring out the intended deployment here.

Section 5:
I think this is an interesting idea, but to comply with SVCB semantics I
would structure this as an SVCB query for dns://resolver.arpa, i.e.  at
_dns.resolver.arpa.  This would resolve to an SVCB RRSet that can enumerate
alternative endpoints with different protocols and parameters.  (This is
again similar to the NS2 proposal.)

I don't understand the motivation for using IP hints in this way.  Normal A
and AAAA records would seem to suffice, and are likely easier to maintain.

I don't understand why you require the IP address to appear in the
certificate.  This would prevent resolvers from directing users to a
trusted third party, creates a fragile binding between the insecure and
secure resolver deployments (e.g. when changing the resolver's IP address),
and rules out this mechanism entirely for home router type configurations.

On Wed, May 20, 2020 at 7:04 PM Tommy Pauly <tpauly=
40apple.com@dmarc.ietf.org> wrote:

> Hello ADD,
>
> We’ve just posted a draft of Adaptive DNS Privacy [1] that’s scoped down
> to talk about resolver discovery and designation mechanisms, both on local
> networks and over the wider Internet. This draft is targeted at the focus
> of the ADD group.
>
> https://tools.ietf.org/html/draft-pauly-add-resolver-discovery-00
>
> This covers:
> - What it means to designate an encrypted resolver
> - How to discover resolvers using SVCB/HTTPSSVC records
> - How to validate designation either by validating DNSSEC on these
> records, or by performing validation with an HTTPS server
> - How to advertise a resolver on the local network
> - How to discover a “companion” DoH server to a directly known resolver
>
> Thanks to Tommy Jensen for his additional input on some of the
> local/direct resolver bootstrapping.
>
> We’ll be publishing other documents that update the behavior for client
> algorithms and the use of Oblivious DoH, but we wanted to present this
> portion individually as the group discusses how best to discover resolvers,
> etc.
>
> Best,
> Tommy
>
> [1] Previous, broader version, here:
> https://tools.ietf.org/html/draft-pauly-dprive-adaptive-dns-privacy-01
> --
> Add mailing list
> Add@ietf.org
> https://www.ietf.org/mailman/listinfo/add
>