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

Brian Dickson <brian.peter.dickson@gmail.com> Thu, 31 October 2019 19:17 UTC

Return-Path: <brian.peter.dickson@gmail.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 E8035120827 for <dns-privacy@ietfa.amsl.com>; Thu, 31 Oct 2019 12:17:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Level:
X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-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=gmail.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 AsuBKrUzwl_6 for <dns-privacy@ietfa.amsl.com>; Thu, 31 Oct 2019 12:17:25 -0700 (PDT)
Received: from mail-vs1-xe2a.google.com (mail-vs1-xe2a.google.com [IPv6:2607:f8b0:4864:20::e2a]) (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 8BB65120800 for <dns-privacy@ietf.org>; Thu, 31 Oct 2019 12:17:25 -0700 (PDT)
Received: by mail-vs1-xe2a.google.com with SMTP id b184so1307025vsc.5 for <dns-privacy@ietf.org>; Thu, 31 Oct 2019 12:17:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=k8GYO5uQSSbAO/U8M6l16OhFLgsaEtN6qWTv04W7m4E=; b=FE4/j3wH3pMT9192othA1AWgGEbMXDyZaU6WP7wajvJ2j7ETiGyXjRi+GFxl/gbqMl A4pjfwDOJiONDeNkbwzeLcn2vWoNm3O6nTu+mBvfJ28/ut7WPgl1sfnOAzfDRUkmejwp cS/egikGRdorYEhoFRXLHmD/gllHaO6V4ZQEbIwp8UCuVLYnpSMc7yNGEVLMkSILZqho XhNWLFwkN1zC8KRTV1YnFKlLb052UHSu+zINi7AwCXt1nQ9ShVxpfi27YcPiLLndzaQV UdaXYVOcbFWKeF2nWzLMSNhQfsslV4OZco01iequ833rdb22SQhYaOoHPu3U55N5lyip 4l2w==
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=k8GYO5uQSSbAO/U8M6l16OhFLgsaEtN6qWTv04W7m4E=; b=W8q0BNsHvgCoeiEtQXFjpvVWxWvr96SnCoMVyZI/xonOJBAavZKUfFx2qXF08XKYYY wMx2C+MbfJeVsqxAPPADYsC+gJ2x/f+4hb8y9GcjKz+SXcvYRoOupS87gpQEVTU6QI+z 7sBbaj/GVvtMZ1Qi28Ekv8+9Pne5xKOdZlr47CzkMGIBxnvsv8s0hbTVM3OmvyaW417E z4bpGvbRAH+mKmlMaYrvUzAE3iXMWHx9G84mknfCRAnBvYozN82w4vkdJ+2DG90XBsyX 0j5C8FVQBvbrgfvguWav4PK+kZrUSmtl8pDWmoCkHMmBWdd3a4mDDY05jsvQtXb//zZM 13hQ==
X-Gm-Message-State: APjAAAUFvK14OkDwkO7SQ3AtIvP3Lq3w63CDsF19+oXPw0LLttcqoGPR H8U/DVfqGXLi6l6guONaQJSxlQ5x/l3ybdlvea8=
X-Google-Smtp-Source: APXvYqyxJP8gm7ayv7suz7g3orDr8IzlJlbotdVpha13ZGuecTnLvjPmqYd2X6lBUs4/3Qm5LHqWdk8sOmlMJKafRMU=
X-Received: by 2002:a67:f5d7:: with SMTP id t23mr3621062vso.75.1572549444487; Thu, 31 Oct 2019 12:17:24 -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> <BAD38F3A-5344-410A-BC8A-A25DD66257A6@cable.comcast.com> <3333A176-94CA-4CD5-9BDD-A5AB499F5346@rfc1035.com>
In-Reply-To: <3333A176-94CA-4CD5-9BDD-A5AB499F5346@rfc1035.com>
From: Brian Dickson <brian.peter.dickson@gmail.com>
Date: Thu, 31 Oct 2019 14:16:52 -0500
Message-ID: <CAH1iCiqf_iAp4TRtCrnCOqB2S71RmhG9EeYeugENDtJKEXWWww@mail.gmail.com>
To: Jim Reid <jim@rfc1035.com>
Cc: "Livingood, Jason" <Jason_Livingood@comcast.com>, dns-privacy@ietf.org
Content-Type: multipart/alternative; boundary="00000000000007d0f7059639b33a"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dns-privacy/ZcrprxqXYxRS_nSJsQ1QoaHfdbQ>
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:17:28 -0000

On Thu, Oct 31, 2019 at 12:11 PM Jim Reid <jim@rfc1035.com> wrote:

>
>
> > On 30 Oct 2019, at 18:40, Livingood, Jason <Jason_Livingood@comcast.com>
> wrote:
> >
> > I agree that this is not a technical issue of scaling the root; that
> quantity of queries per day and second is not a big problem. Rather, as you
> note, it is a layer-9 issue. But I don't think we should constrain our
> requirements development & protocol design because of this.
>
> In principle, I agree with you. Though in practice, I'm questioning if it
> makes sense to work on ADoT unless there's a strong likelihood it will get
> mainstream deployment and adoption. [What's the point of producing
> something that won't see widespread use?] And surely if there's going to be
> ongoing protocol design work, that needs to take account of the concerns of
> those who run busy authoritative servers? AFAICT apart from a recent ID
> from Verisign, they have not been part of the discussion so far.
>
>
I think there will be both interest and deployment, sufficient to justify
the effort.

IMHO, including the ability for authority operators to signal support, may
be sufficient to address the concerns about the root servers, including
that they may have different levels of interest in supporting DoT.

E.g. Having a well-defined record at or under the NS name that indicates
support for transport protocols would enable each root-server.net instance
to signal whether DoT queries might be answered.

That itself might crack open another can of worms: DNSSEC signing of
root-servers.net, including possible naming choices for the root servers
(qv related investigative work that was being done by the RSSAC Caucus.)

One idea that was not considered previously, that just occurred to me: have
root-servers.net be DNSSEC signed, but without a secure delegation. It
would be an island of security that could be optionally be securely
accessible via adding a new trust anchor, specifically if/when a particular
resolver wishes to use ADoT to authority servers. I believe it would not
impact the priming responses.

(Also, I think the ADoT requirements should include an assumption that ADoT
is not supported unless the nameserver name explicitly signals such at or
under the nameserver's name.)

Brian