IETF Logo Mail Archive

Re: [dns-privacy] [Ext] DS glue

Ben Schwartz <bemasc@google.com> Thu, 19 August 2021 17:14 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 C79703A0DA3 for <dns-privacy@ietfa.amsl.com>; Thu, 19 Aug 2021 10:14:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -18.097
X-Spam-Level:
X-Spam-Status: No, score=-18.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.499, 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 fZCwHPLaewQX for <dns-privacy@ietfa.amsl.com>; Thu, 19 Aug 2021 10:14:40 -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 397A43A0DA0 for <dns-privacy@ietf.org>; Thu, 19 Aug 2021 10:14:40 -0700 (PDT)
Received: by mail-wr1-x42b.google.com with SMTP id v4so10118884wro.12 for <dns-privacy@ietf.org>; Thu, 19 Aug 2021 10:14:40 -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=23NObYJz9A9N0x4g6BZ3KKQmfNUOw814xmyecq3H0bw=; b=a7I9WRULRsnPXu9ONM2+ZLNDxYN0pzjawCBa591hjDp2w3kKSWfuGpwr3qaEKk/mSL xrGB3HVHWPh50kZfN3eX3QrN3fVJwIMdjT/o2nmIK70Sbka1jNLszzA6+DD895qTMFGt FedjFjdpMQbShvtauKzMF3fW2v04hrtJXJUnIfohYwRW2BUWY6FdtMN2UKp6dJLo2B2c tcvXzXrCl5OLBXcudJn0uovcDgnxOuq2x8QbEkSVHMj01jNRL3T8Iy0bqZt4EM/7k+Ep qxnLX9j10zd4qYTWP6r84o1VswcW0dzmgogWZNdG283DDTSuJ93U7zCyb0TzdzkZOchR XrZg==
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=23NObYJz9A9N0x4g6BZ3KKQmfNUOw814xmyecq3H0bw=; b=OghtfBprgRKVmRwT7HOGHqJbBiHfbLkFzTtA0jTtJXyIOohTLyGcDLLYgEKYxIrKmu G5xJGQghdqyzXiKwT7TFt2ayGTdK+WDmJo9mZsuo77NVGD4FeiGvrIHBvKnMEVDPkWve QxGPqrq1rEkDa/s/9yDWFpkCz5LAt5ELDAuWdOir0nIE73DOIgMrS8MrLFRixhLRU4TG MDvS0eUudMKoVhEvGVlXNeS1DO+vKsDM17Pl2VdDvrWZD0DwGOemPAVJzcVBr7TbQfc1 bzWJx9lEPra1qNO1nYZujz+jziIOwla8GUTrWMIQ2kDaGkMU+ksLSXJPyysS2cmAkYav 83kw==
X-Gm-Message-State: AOAM532FIEOGyNFQcUgeWtpbOG5jyDI3J19L20rnyeBfWX02u6u4D3BZ obXEN+DMilOF6VdiuQsEyXmj//WqTIJ1pwI2/kvMow==
X-Google-Smtp-Source: ABdhPJzTspbBcZlXNXbbaGJBzaWkJPvppRM5ZSjCmwgMJsTYMO0RHCWam+040J23PJU5PWdfYFpHye2m3oXFArkB1aw=
X-Received: by 2002:adf:a1ca:: with SMTP id v10mr5067006wrv.177.1629393276939; Thu, 19 Aug 2021 10:14:36 -0700 (PDT)
MIME-Version: 1.0
References: <CAHbrMsAXFiPT_P_hdWXborXnbw3YagjW6aXXvGJnxWbtRofB2g@mail.gmail.com> <5f649d68-94be-579a-31c6-6ad02466cd15@time-travellers.org> <CAHbrMsCj8LzJff7BXwnY4TOcOU2POuZfP4h+fyA6VUKeGpksCQ@mail.gmail.com> <E0430A84-D844-4B79-B71F-A92A21942329@icann.org> <CAHbrMsCPPq-o8U4mhFPZ1U+GE+57yneEGo7AD5uDQ_QDDUO0rw@mail.gmail.com> <03FDA925-2BC3-4830-B27B-5F6E19676678@icann.org> <CAPp9mxJM1b4+OFHX0x6QwhoJpE+8Sz82K_e=DJ9EJFaK691_3Q@mail.gmail.com> <4AE29BBE-9B29-4E89-93CF-14153B25FD5C@icann.org> <CAHbrMsBQ88mKx-FLU0KT8W-AGyi=3HS3f5nuSO93-TOo_HTyNw@mail.gmail.com> <936E4261-D804-43B8-B3BB-9D309F8CFAF4@icann.org> <E1E41EDC-8BF9-47D8-97D7-EB6F7EF1A5B3@icann.org> <CAHbrMsAUBWZ6Gs=QsqxRLNR4MjmnieE2RM4KLTUpCP+nE0jDNw@mail.gmail.com> <CAHXf=0q0VE23btHH2j+a-7xVL6vzFxdxidQd5PD2iA6mhxjnNw@mail.gmail.com>
In-Reply-To: <CAHXf=0q0VE23btHH2j+a-7xVL6vzFxdxidQd5PD2iA6mhxjnNw@mail.gmail.com>
From: Ben Schwartz <bemasc@google.com>
Date: Thu, 19 Aug 2021 13:14:25 -0400
Message-ID: <CAHbrMsAxpGVAFBOjBESt_kxnt35EKYTauR4z6s4+PmbZbd7Ldg@mail.gmail.com>
To: Alexander Mayrhofer <alex.mayrhofer.ietf@gmail.com>
Cc: Paul Hoffman <paul.hoffman@icann.org>, DNS Privacy Working Group <dns-privacy@ietf.org>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha-256"; boundary="0000000000007f896005c9ecaf52"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dns-privacy/1UgcaclVKv0Jb3ICDMV_cdgXBrg>
Subject: Re: [dns-privacy] [Ext] DS glue
X-BeenThere: dns-privacy@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Addition of privacy to the DNS protocol <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: Thu, 19 Aug 2021 17:14:46 -0000

Thanks for the review, Alex.  I've just released a new revision that
addresses some of your comments:

https://datatracker.ietf.org/doc/html/draft-schwartz-ds-glue-02

The main change in this revision is the removal of the NSEC approach to
authenticated nonexistence.  This proved too complicated for me to get
right in the examples, and implementers told me that it would not be easy
to implement, as I had hoped.  Instead, draft-02 encodes each RRSet as a
unit, and authenticates nonexistence by encoding an empty RRSet.

On Thu, Aug 19, 2021 at 12:54 PM Alexander Mayrhofer <
alex.mayrhofer.ietf@gmail.com> wrote:
...

> However, i'm a bit more cautious when it comes to generalizing DS-GLUE
> to other use cases, particularly conveying NS records.


I don't think we can avoid placing NS records in DSGLUE.  Authenticating
the NS records is crucial for both out-of-bailiwick and in-bailiwick
delegations.


> It's cool to
> have a generic mechanism to convey arbitrary records, but once those
> records overlap with a "legacy deployment", we need to be very very
> careful about the interactions between those two channels (eg. domain
> name owners expecting they can safely remove the NS records from the
> registry, because they supply those records in DS-GLUE already). I
> think there should be some text in the draft about this in future
> revisions.


OK, I've added that text here:
https://datatracker.ietf.org/doc/html/draft-schwartz-ds-glue-02#section-6.1

Maybe we should even restrict DS-GLUE to a set of
> pre-defined use cases.


draft-02 now does this, by opening a registry of allowed RR types.  As we
reach an understanding of how to interpret other RR types in DS Glue, we
can add them to the registry.

v2.23.0 | Report a Bug | By Email