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

Eric Rescorla <ekr@rtfm.com> Fri, 01 November 2019 00:38 UTC

Return-Path: <ekr@rtfm.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 2EC2C120105 for <dns-privacy@ietfa.amsl.com>; Thu, 31 Oct 2019 17:38:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level:
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=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=rtfm-com.20150623.gappssmtp.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 TA6PNC9LDbAG for <dns-privacy@ietfa.amsl.com>; Thu, 31 Oct 2019 17:38:04 -0700 (PDT)
Received: from mail-lj1-x234.google.com (mail-lj1-x234.google.com [IPv6:2a00:1450:4864:20::234]) (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 DCAD51200D5 for <dns-privacy@ietf.org>; Thu, 31 Oct 2019 17:38:03 -0700 (PDT)
Received: by mail-lj1-x234.google.com with SMTP id q2so1977630ljg.7 for <dns-privacy@ietf.org>; Thu, 31 Oct 2019 17:38:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=vp/j4Wf0RHaSCkDDnimbELHXx0gjgXeMIViAUEYnv4I=; b=nx4cVlPdBeGlnD+uU3z8Lsb03FTaukmCyHVpnDcNu9K9PcQyLPBAvW3EJj/tu5in1g RQSHVct7HNBCMOs/T4FRvxAbMS6IWCtBfThK82v6AFmxaR4TW5WCXrw09pHOHy8E5oKC Ajvbk1WBPiXlcSQ+ykf7ta7oM29AmLc8WuEwpNtu1cPy0g67ETYVPf/RZNfwBvQcBASk 4BQiByyZ1VvoEgqy+HoRf1sWB89eK3SH63Bs4HeQ3ZelqsIxaP782Q7KWwfsfLJ8i1Uf YUU2Fq7lDru6n5lTI/P2SXJnLxfFyS1iIzZX4vXtakIChkCBAUrQXAyVD8mS90ihus0a ZTTA==
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=vp/j4Wf0RHaSCkDDnimbELHXx0gjgXeMIViAUEYnv4I=; b=t2QDhXRMvjn41WP+Wc177dn0TZKXG0VL8bajKOUkJAQPFXZY737pQZZ+tmTlYgpFVh wgBRjhSwJsKEHpd0DMeLBPTKyEouzYJZhCc3DvKIwcDPAj+u4F2C7Q0ZEWj+hTy/UYmj bpk3mxxlHSrNgd3U9f99/73vNXsVwxo8qtF9NQAR9LEcowwZel6Ko0IAOVS3a3GM1ekN cBPZru2TCxKsr6yLOLb0ncRYyaanZ4Hdbm+Cs4IFea0xQMiwXbxvnSUiC/2+E83g7gWY KwLiGnvHHSsBbQ1s0NnHKFZao9xK2zXN0afs1sR1MyyRMm9HWospSSzhXpWZ8rDzAYVg itnw==
X-Gm-Message-State: APjAAAX04gv8n0v8yZcvuFRTmAnbAkMVmSB0haWFtxi1e+akuKI4azM3 rf3HtL5WadTpPqbk2HD9h7nXo5ukhY7e2DID+vJC7g==
X-Google-Smtp-Source: APXvYqy+GrUN6DwXH/SWMyZI5XPw3q0OKTBgRO6k8e8VnxofardbY0eA0I89vUGkhPPVjmllBh6YZQDa5ViL+iqGCW8=
X-Received: by 2002:a2e:a303:: with SMTP id l3mr6054587lje.38.1572568682238; Thu, 31 Oct 2019 17:38:02 -0700 (PDT)
MIME-Version: 1.0
References: <CAHbrMsDwDoTQN8Y5Zk7rSVepjwwyatEyAA6f0oJ9DESmAfHfXg@mail.gmail.com> <20191031211222.A6422DBC1C7@ary.qy> <CAH1iCiqYoXMZ0U3yt8AjUXyZVRdDnmHzSpHvYmg++ACZ-U6=zA@mail.gmail.com>
In-Reply-To: <CAH1iCiqYoXMZ0U3yt8AjUXyZVRdDnmHzSpHvYmg++ACZ-U6=zA@mail.gmail.com>
From: Eric Rescorla <ekr@rtfm.com>
Date: Thu, 31 Oct 2019 17:37:25 -0700
Message-ID: <CABcZeBP-k23ZY=f6Lv5A+B+Z_4ar_9ea=G7O+KRriXNLUzKGqw@mail.gmail.com>
To: Brian Dickson <brian.peter.dickson@gmail.com>
Cc: John Levine <johnl@taugh.com>, Ben Schwartz <bemasc@google.com>, dns-privacy@ietf.org
Content-Type: multipart/alternative; boundary="000000000000b0aa1d05963e2def"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dns-privacy/a5EjULDWvQ9aH-srMkVV5LWJnFM>
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: Fri, 01 Nov 2019 00:38:06 -0000

On Thu, Oct 31, 2019 at 2:41 PM Brian Dickson <brian.peter.dickson@gmail.com>
wrote:

>
>
> On Thu, Oct 31, 2019 at 4:12 PM John Levine <johnl@taugh.com> wrote:
>
>> In article <
>> CAHbrMsDwDoTQN8Y5Zk7rSVepjwwyatEyAA6f0oJ9DESmAfHfXg@mail.gmail.com
>> <CAHbrMsDwDoTQN8Y5Zk7rSVepjwwyatEyAA6f0oJ9DESmAfHfXg@mail..gmail.com>>
>> you write:
>> >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..)
>>
>> Thinking about it a little more, I think it is likely that there will
>> be islands of ADoT sort of like there used to be islands of DNSSEC.
>> For example, I expect the people on this list are likely to deploy
>> ADoT long before some of the 2LD's above them. Moreover, all of the
>> problems about getting your DS into the zone above would apply to
>> getting your ADoT signal there.  Even with the cost of an extra lookup
>> it's probably going to work better to have each island describe itself
>> so you don't need an unbroken chain of ADoT from the root.
>>
>
> IMNSHO, ADoT at the leaf + QNAME minimization is all that is required for
> privacy.
> I.e. No need for ADoT anywhere other than at the leaf zone's name server
> (whose NS name might not be in-bailiwick, FYI).
>

Hmm.... I think that's only true if you are assuming that the NS record for
the leaf is DNSSEC secured, but that doesn't seem like a safe assumption.

-Ekr


> Brian
> _______________________________________________
> dns-privacy mailing list
> dns-privacy@ietf.org
> https://www.ietf.org/mailman/listinfo/dns-privacy
>