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

"John Levine" <johnl@taugh.com> Thu, 31 October 2019 21:12 UTC

Return-Path: <johnl@iecc.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 7B39E120851 for <dns-privacy@ietfa.amsl.com>; Thu, 31 Oct 2019 14:12:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.75
X-Spam-Level:
X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.25, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=A5sIKN7M; dkim=pass (1536-bit key) header.d=taugh.com header.b=J1uMyt2L
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 4xDNb3sD0eqR for <dns-privacy@ietfa.amsl.com>; Thu, 31 Oct 2019 14:12:25 -0700 (PDT)
Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EE81912081B for <dns-privacy@ietf.org>; Thu, 31 Oct 2019 14:12:24 -0700 (PDT)
Received: (qmail 281 invoked from network); 31 Oct 2019 21:12:23 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=117.5dbb4e37.k1910; i=printer-iecc.com@submit.iecc.com; bh=6hjhP0HW378W78UD9cRjhlgk49zTlTvv/ydfNDxET2Q=; b=A5sIKN7MRNepWvDoy+2JqPrhVvxed4aZpyLr1V+POUf2Vdi/EQmO5mv/d20i7U8lweOe3DZgsGzJkR6VYnIVFzGT+uoIljj6arafIB9Z2GWELUrqpZRizo0zjm4SZdiIOPD52c1Jq3vTX9Ay5WX6pepXb2XWXeJz+hgAOm5rXxH4xx8K4SVkvA72kGNS8xgVlARV3TsqrKI3n5tyUAcnaMC5gi5L5BLwAgwYob5IZOjEqjRsloNUg5rjBYCqTyYe
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=117.5dbb4e37.k1910; olt=printer-iecc.com@submit.iecc.com; bh=6hjhP0HW378W78UD9cRjhlgk49zTlTvv/ydfNDxET2Q=; b=J1uMyt2LKJdUNeK2R+p21is2cOGty7w38PomsTvXer31vmwxdfVOUCNVlAIELpm1lt+sdGZCigPBV91GglV4kEn8jOx41nCYiHTzvyVmEgHhaxtHPvWrt3iKvgdQusllfZDkhBXJwHa13WAQ8aJCN28I94sYQJbH5O2/8/hVU90zd0KIKGYltoj17J6ofKmdESDnhoWsRw49Mg1WddQr8gLZO0GPtA1qRau/6B1fD+pAJnVMg85yQ1oZRfYGcxO9
Received: from ary.qy ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPSA (TLS1.2 ECDHE-RSA AES-256-GCM AEAD, printer@iecc.com) via TCP6; 31 Oct 2019 21:12:23 -0000
Received: by ary.qy (Postfix, from userid 501) id A6422DBC1C7; Thu, 31 Oct 2019 17:12:22 -0400 (EDT)
Date: Thu, 31 Oct 2019 17:12:22 -0400
Message-Id: <20191031211222.A6422DBC1C7@ary.qy>
From: John Levine <johnl@taugh.com>
To: dns-privacy@ietf.org
Cc: bemasc@google.com
In-Reply-To: <CAHbrMsDwDoTQN8Y5Zk7rSVepjwwyatEyAA6f0oJ9DESmAfHfXg@mail.gmail.com>
Organization: Taughannock Networks
X-Headerized: yes
Mime-Version: 1.0
Content-type: text/plain; charset="utf-8"
Content-transfer-encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dns-privacy/Z5qfdZM8OGUU-e_SRDsweIfgGdg>
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 21:12:26 -0000

In article <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.

R's,
John

PS: Yes, this is the opposite of what I said yesterday.