Re: [dns-privacy] Common Features for Encrypted Recursive to Authoritative DNS

Ben Schwartz <bemasc@google.com> Mon, 03 May 2021 21:06 UTC

Return-Path: <bemasc@google.com>
X-Original-To: dns-privacy@ietfa.amsl.com
Delivered-To: dns-privacy@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 126463A1139 for <dns-privacy@ietfa.amsl.com>; Mon, 3 May 2021 14:06:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.598
X-Spam-Level:
X-Spam-Status: No, score=-17.598 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, RCVD_IN_DNSWL_BLOCKED=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 G6D1uxHKwobn for <dns-privacy@ietfa.amsl.com>; Mon, 3 May 2021 14:06:50 -0700 (PDT)
Received: from mail-wm1-x32f.google.com (mail-wm1-x32f.google.com [IPv6:2a00:1450:4864:20::32f]) (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 EA1FC3A0E94 for <dns-privacy@ietf.org>; Mon, 3 May 2021 14:06:49 -0700 (PDT)
Received: by mail-wm1-x32f.google.com with SMTP id s82so4131306wmf.3 for <dns-privacy@ietf.org>; Mon, 03 May 2021 14:06:49 -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=AtqewQaBc8aCjFr3JFynzqK02Vm38YUUhq8AMDOFIzc=; b=IQZfkkCJ7G/1ypst9sLcykoBaXDnienUgrKrdIW8zOosS0L0530wPpD/lROacXNyCm DqY6AkBgeTAnTQhk3QF+sfP+MoiouCILltyl6fwqsdGgmH8WRa/eNRMlOJ6YUosnWYib lyKeN8BijobBNF65+Vg4d2j0BsFhQmWCyGew70uNoQZz86s3vy+JCQcIdBbw9Jpplu6a OVrwYKg4KCqzolAM7HSVpi3psDIQe24DGd3jjAJ+72SuWJ8sKGG9VJm9KBNkH7GwR1pY Dah5NO+WjB2ddl2RuPuco8cgNZx/wLGAc3hpf7DHmeq8RJeDXPw4T6YaxL2Sc7zeSinY 0edw==
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=AtqewQaBc8aCjFr3JFynzqK02Vm38YUUhq8AMDOFIzc=; b=RPVmDEUJzO5r+6i1zSOiNq6H5hobrRrVA8IsmH5wXNlUJK2tiDkm1NvUtObUxPfdpd F8F88caWy17f/1xxgnYMQTYrRI3Qg1A8gMohSgnURS4+7zqBq6R310XEiW2kSn2d/c6r vZN8f4+6aYMqVXOGcBSvER2ApsJ1kFt+RX8uWoQAw14B0eXqBxJngSVyX7kR/8i+MW8z ZKUFo3kN8+NQZ79EHKKSJqdQ65eR127LEGs76SOYEUccNcL1hwUxbNMUQRLJTxw9Q+ra nhdrgCRCWoOIId7LCgSwVJMu+IeVMlaK4OoQgNoZOcccRUpfeIBpIOrJAhcvlARLJ2BY l3YA==
X-Gm-Message-State: AOAM531lTqpTHsmAjpaeT2XcIrV9cdOqTLRBUFYEhVQaY1E0N6foPJmd shIs/DG9lOUblw3jh7SgNuz/R8Vl5TZSc9jLlx1Z7g==
X-Google-Smtp-Source: ABdhPJwORvbeVOLISlzt2gxcZUgbH3gNAqciGgw9O7iwouXulVhaYVDjtlAQojK373WuqZRrKY2iFXyXzyMIgqZlO2I=
X-Received: by 2002:a05:600c:3541:: with SMTP id i1mr489153wmq.97.1620076005827; Mon, 03 May 2021 14:06:45 -0700 (PDT)
MIME-Version: 1.0
References: <161997426960.11261.17005541940248978884@ietfa.amsl.com> <4490d7382c7efb10bf5689f655bf890d7b76bed8.camel@powerdns.com>
In-Reply-To: <4490d7382c7efb10bf5689f655bf890d7b76bed8.camel@powerdns.com>
From: Ben Schwartz <bemasc@google.com>
Date: Mon, 3 May 2021 14:06:34 -0700
Message-ID: <CAHbrMsCAoMQe=kwaeU7w6eZNwwFT8Syc+8j7EeDgBCvMPBsFsQ@mail.gmail.com>
To: Peter van Dijk <peter.van.dijk@powerdns.com>
Cc: DNS Privacy Working Group <dns-privacy@ietf.org>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="000000000000ea40c005c17356e9"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dns-privacy/aUjhy5f0975lGHQ93oHcx4spW4o>
Subject: Re: [dns-privacy] Common Features for Encrypted Recursive to Authoritative DNS
X-BeenThere: dns-privacy@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <dns-privacy.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dns-privacy>, <mailto:dns-privacy-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dns-privacy/>
List-Post: <mailto:dns-privacy@ietf.org>
List-Help: <mailto:dns-privacy-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dns-privacy>, <mailto:dns-privacy-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 03 May 2021 21:06:55 -0000

Thanks for this draft; I think it's clear and could be a helpful
introduction.

>    If the cache has no positive or negative answers for any DNS SVCB
   record for any of a zone's authoritative servers, the resolver needs
   to send queries for the DNS SVCB records for some or all of the
   zone's authoritative servers.

I think it would be worth rephrasing the words "needs to" here.  To me,
this sounds like a normative requirement to perform these queries, but I
suspect that's not what you mean.

>    Because some authoritative servers or middleboxes are misconfigured,
   requests for unknown RRtypes might be ignored by them.  Resolvers
   should be ready to deal with timeouts or other bad responses to their
   SVCB queries.

This sounds a bit pessimistic.  Ralf Weber recently published some figures
showing a ~0.03% failure rate.  For security (in the authenticated case),
any mitigations here are very delicate, and I'm a bit concerned about the
brief treatment here.  (The SVCB draft has an extensive discussion:
https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-svcb-https#section-3.1
.)

>    DNS SVCB records act as advisory information for resolvers about the
   encrypted protocols that are supported.  They can be thought of as
   similar to NS records on the parent side of a zone cut: advisory
   enough to act on, but not authoritative.  Given this, authoritative
   servers that know the DNS SCVB records associated with NS records for
   any child zones MAY include those DNS SCVB records in the Additional
   section of responses to queries to a parent authoritative server.

This sounds like a restatement of the definition of "glue".  Can we simply
declare that these records are "glue"?

--Ben

On Sun, May 2, 2021 at 9:55 AM Peter van Dijk <peter.van.dijk@powerdns.com>
wrote:

> Hello DPRIVE!
>
> in the last two draft revisions of our protocol for unauthenticated
> encryption from resolvers to authoritatives, we adopted the SVCB
> discovery mechanism from draft-rescorla-dprive-adox-latest-00. This
> means that the two documents overlap somewhat, and there would be
> effort needed to keep the mechanisms in sync.
>
> To avoid that problem, instead we present here a separate document that
> contains the parts that the two protocols have in common. Our draft is
> adopted; we understand the authors of the authenticated draft intend to
> ask for adoption soon, as well. If the WG adopts this separate
> document, we will not have to keep the discovery bits in sync between
> the two, and we can hammer out the details of discovery once, in a
> single place.
>
> We imagine this would be much more efficient.
>
> - Paul & Peter
>
>
> -------- Forwarded Message --------
> From: internet-drafts@ietf.org
> To: Paul Hoffman <paul.hoffman@icann.org>rg>, Peter van Dijk <
> peter.van.dijk@powerdns.com>
> Subject: [EXT] New Version Notification for draft-pp-dprive-common-
> features-00.txt
> Date: Sun, 02 May 2021 09:51:09 -0700
>
> A new version of I-D, draft-pp-dprive-common-features-00.txt
> has been successfully submitted by Peter van Dijk and posted to the
> IETF repository.
>
> Name:           draft-pp-dprive-common-features
> Revision:       00
> Title:          Common Features for Encrypted Recursive to Authoritative
> DNS
> Document date:  2021-05-02
> Group:          Individual Submission
> Pages:          7
> URL:
> https://www.ietf.org/archive/id/draft-pp-dprive-common-features-00.txt
> Status:
> https://datatracker.ietf.org/doc/draft-pp-dprive-common-features/
> Htmlized:
> https://datatracker.ietf.org/doc/html/draft-pp-dprive-common-features
> Htmlized:
> https://tools.ietf.org/html/draft-pp-dprive-common-features-00
>
>
> Abstract:
>    Encryption between recursive and authoritative DNS servers is
>    currently being defined in two modes: unauthenticated and fully-
>    authenticated.  These two modes have some features in common, and
>    this document defines those common features so that the documents
>    defining the modes do not need to point to each other.
>
>
>
>
> Please note that it may take a couple of minutes from the time of
> submission
> until the htmlized version and diff are available at tools.ietf.org.
>
> The IETF Secretariat
>
>
>
>
> _______________________________________________
> dns-privacy mailing list
> dns-privacy@ietf.org
> https://www.ietf.org/mailman/listinfo/dns-privacy
>