Re: [dns-privacy] [Ext] Re: ADoT requirements for authentication?

Ben Schwartz <bemasc@google.com> Thu, 31 October 2019 19:49 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 4EFF012006A for <dns-privacy@ietfa.amsl.com>; Thu, 31 Oct 2019 12:49:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.5
X-Spam-Level:
X-Spam-Status: No, score=-17.5 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, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-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 If59mr1vTxCJ for <dns-privacy@ietfa.amsl.com>; Thu, 31 Oct 2019 12:49:13 -0700 (PDT)
Received: from mail-io1-xd31.google.com (mail-io1-xd31.google.com [IPv6:2607:f8b0:4864:20::d31]) (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 6B220120018 for <dns-privacy@ietf.org>; Thu, 31 Oct 2019 12:49:13 -0700 (PDT)
Received: by mail-io1-xd31.google.com with SMTP id k1so8144252iom.9 for <dns-privacy@ietf.org>; Thu, 31 Oct 2019 12:49:13 -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=sUa9s5qj1ZTAJn8+Zne/WQ172fPtXuqxhJ9R/JoMumE=; b=nqt9g8N+BKdIIS/sUd8aUGXfpwwxpzbDuPLb9o7fXy53Rh9Bvd0AbYfL6UCrAsb4Ic 9+FBI9CAXQVyweBB2Ou//Tx1z/6eiwXB+GyAEhSIWoopTNi0B8vy1hZ6xGYI6ghaai5B EGQhzrquKwkUQjb3vd/k9ECbHBjcYrn4hZZRprLXftHjYB2YSjmJziO0DvdRgA8Pp0NK G1Ykj76IVYXaI3iAHUcIEYVh3Z6Q9/dIMUsHamSQrXswb4ZEag3CcyC2bJF0Twp1dXDF gYqL8TrCF8lpmQK9ofZWoEtUD8IIDHGJRY6dZVqVrpuvZVaihOEGULstjYc9wkBGz4fO 4+6w==
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=sUa9s5qj1ZTAJn8+Zne/WQ172fPtXuqxhJ9R/JoMumE=; b=iNFN/d8R2DNABVuDDW1WVT4UyYBObQDh6aRiPzo8PRGGVOPZGavA+L6AKCM7tZD+MZ w+0EIiYC2WvPA53HVSCdYxfkx5KLmvDdBVjBYe9MwkwyizU2hd0CeB1WcZ1EUOkr4l69 Odv6y9p1HMd3ecFn7I8ejWzZBrDmDaJnEjAal0Mu+HPbWhf5f6tbzbTjAvdnlLGol2FJ waqOaG0C2cFV2iLymq6x/ftT6u0gR99lMWi5duHf1YaTayPB/41Z/drW3B/hTSl9Y3ZK CVf51xtGTMAlWL/a5b0vtliT85Za8GRxm9ICiQBjwCICW/mW+iP3bkF0oGZb0GPCyI8S ntzA==
X-Gm-Message-State: APjAAAUde8OeUo6y/NOM2G8KQCt4hLhsCagR/AR/YQWAer4VSM8T1stw 8yWFqIBs5AsCjNTLPNW0HU54fys5ZAxK19L7llt/Dth9ACI=
X-Google-Smtp-Source: APXvYqy6des0uCToa532xpTMNhaT6h43zEme2sjmVNHJJGWnyPTF+kUIQzeNcjeTevOQzprVIArYVeuW7xY2W3QTMVg=
X-Received: by 2002:a6b:6a17:: with SMTP id x23mr5634500iog.193.1572551352323; Thu, 31 Oct 2019 12:49:12 -0700 (PDT)
MIME-Version: 1.0
References: <943e3973-f6a7-9f6e-a66a-33aff835bd5e@innovationslab.net> <503df6fb-b653-476f-055f-15c1a668ba36@innovationslab.net> <5fe86408-35a8-16ea-d22a-9c6c4a681057@icann.org> <CA+9kkMBZUPfWov6B+pgLYuFmZh10dTzwF2PdKs5Vozzssqvzjw@mail.gmail.com> <edf53c16-3be9-786c-dcb1-0edc9fd9711c@icann.org> <CA+9kkMC5ynqK+8QO==5Pi_9edjTkJJ3yLHBHqJFOox8fi1_8HQ@mail.gmail.com> <CAHbrMsAAvadukzifKEj9eEWB91aDjmnu775F_YdtBaUHrHwDDQ@mail.gmail.com> <CA+9kkMCVj3Lte1dooNthm0f6eBPFUGbxdQBGyjB62KD8wn+f-g@mail.gmail.com> <CAHbrMsCU4b7yNwEfq1J0qsX3vbij+bLdXpanPMKaF+h6yqkXKw@mail.gmail.com> <CA+9kkMA9=m67w=yPR4=cNmHvMH29ogzBVzA8GZU_HCBkVNUxOg@mail.gmail.com> <CABcZeBMyrW=D+dyoT3FUvfe+9hM7ZCndv=tZ9B2F170U0Z7obw@mail.gmail.com> <CAHbrMsAgR-Andoxs5WRMp2jE3Gf_1EWWpsrAm3eFc-vGhb5A3w@mail.gmail.com> <CABcZeBNTJYQc_1kbK7cL3S8KcHfEzpNsZaeK=OeYopEpjLF9_Q@mail.gmail.com> <CAHbrMsBaGBx-gye+Y+4Ja_a9Dkvkt6kLva3fzyvrzuuzxECZuw@mail.gmail.com> <CABcZeBP64qr81ccw+cbYy6FuQkgArS=G9_itEt8A_UfN8SO7GA@mail.gmail.com> <BDFD7D8F-BB99-46DF-85AC-922DDF25A1D3@rfc1035.com> <CACsn0c=6Kv5j0SKJkTLxSNSPoz_uA62p1vTjWx=ccVJbnv4f7A@mail.gmail.com>
In-Reply-To: <CACsn0c=6Kv5j0SKJkTLxSNSPoz_uA62p1vTjWx=ccVJbnv4f7A@mail.gmail.com>
From: Ben Schwartz <bemasc@google.com>
Date: Thu, 31 Oct 2019 15:49:00 -0400
Message-ID: <CAHbrMsDwDoTQN8Y5Zk7rSVepjwwyatEyAA6f0oJ9DESmAfHfXg@mail.gmail.com>
To: Watson Ladd <watsonbladd@gmail.com>
Cc: Jim Reid <jim@rfc1035.com>, Eric Rescorla <ekr@rtfm.com>, dns-privacy@ietf.org
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha-256"; boundary="000000000000c8909605963a2470"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dns-privacy/k-EK69AgGMBlyFyvEUt8Nu2bkkc>
Subject: Re: [dns-privacy] [Ext] Re: ADoT requirements for authentication?
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: Thu, 31 Oct 2019 19:49:15 -0000

On Wed, Oct 30, 2019 at 2:37 AM Watson Ladd <watsonbladd@gmail.com> wrote:

>
> The root zone is data: whether one distributes it via DoT, DoH, IPv6, or
> carrier pigeon is irrelevant to the policies that goven what's in it.
>

That is arguably true, but I think we are having this discussion primarily
because of RFC 4035 Section 2.2:

   the NS RRsets that appear at delegation points (that is, the NS
   RRsets in the parent zone that delegate the name to the child zone's
   name servers) MUST NOT be signed

Some of the proposals being discussed here would bootstrap ADoT from the
contents of the NS record at the delegation point.  The problem is that
this record is not signed.  As a result, an attacker could inject a forged
version of these records into a recursive cache, breaking ADoT to the child.

The ideas floated here about ADoT to the root are not, in my view, about
privacy (directly).  They're about using ADoT to protect the integrity of
(currently) unsigned data in the root zone.

An alternative solution is to get ADoT bootstrap info from the child zone,
where it could be signed, before making a query that reveals the next
label.  This could work, but at the cost of an extra roundtrip.  (How often
this latency penalty applies depends on the details of the construction.)