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

Tony Finch <dot@dotat.at> Wed, 30 October 2019 13:51 UTC

Return-Path: <dot@dotat.at>
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 262E912011F for <dns-privacy@ietfa.amsl.com>; Wed, 30 Oct 2019 06:51:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.198
X-Spam-Level:
X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 drhMvE4nwdR3 for <dns-privacy@ietfa.amsl.com>; Wed, 30 Oct 2019 06:51:55 -0700 (PDT)
Received: from ppsw-32.csi.cam.ac.uk (ppsw-32.csi.cam.ac.uk [131.111.8.132]) (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 96A091200DE for <dns-privacy@ietf.org>; Wed, 30 Oct 2019 06:51:55 -0700 (PDT)
X-Cam-AntiVirus: no malware found
X-Cam-ScannerInfo: http://help.uis.cam.ac.uk/email-scanner-virus
Received: from grey.csi.cam.ac.uk ([131.111.57.57]:50432) by ppsw-32.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.136]:25) with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) id 1iPoO5-001ixS-1R (Exim 4.92.3) (return-path <dot@dotat.at>); Wed, 30 Oct 2019 13:51:49 +0000
Date: Wed, 30 Oct 2019 13:51:49 +0000
From: Tony Finch <dot@dotat.at>
To: Ted Hardie <ted.ietf@gmail.com>
cc: Paul Hoffman <paul.hoffman@icann.org>, "dns-privacy@ietf.org" <dns-privacy@ietf.org>
In-Reply-To: <CA+9kkMBZUPfWov6B+pgLYuFmZh10dTzwF2PdKs5Vozzssqvzjw@mail.gmail.com>
Message-ID: <alpine.DEB.2.20.1910301238080.8949@grey.csi.cam.ac.uk>
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>
User-Agent: Alpine 2.20 (DEB 67 2015-01-07)
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dns-privacy/bqozdxvlBIB3AsuDe1kp5HIG0is>
Subject: Re: [dns-privacy] 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: Wed, 30 Oct 2019 13:51:58 -0000

Some miscellaneous thoughts vaguely related to the discussion ...

## nameserver hostnames in certificates

It's not uncommon for zones to use in-bailiwick aliases for their
nameservers, which avoids transitive configuration dependencies and speeds
up resolution because the resolver gets glue with the referral rather than
having to chase down server addresses.

(see discussion of gluelessness on https://cr.yp.to/djbdns/notes.html)

This is obviously problematic for using hostname authentication. I suppose
a server could provide its IP address(es) and official hostnames in its
cert to allow either for authentication...

## third-party secondary servers

If the ADoT status is in the delegation (special DS records, special NS
records) then that implies a nasty co-ordination cost to any changes.

## glueful bootstrapping

If we rely on TLSA records at the nameserver's hostname then there's a fun
bootstrapping problem for in-bailiwick delegations. If a resolver queries
for the TLSA records in the clear then they'll leak the zone name; if it
speculatively tries TLS then it might be really slow waiting for timeouts.

## reverse dns bootstrapping

If the resolver looks for TLSA records in the reverse DNS there's a fun
case where it has a referral for (say) example.com with glue for
ns1.example.com in 192.0.2.1, but then it finds that ns1.example.com is
also a server for 2.0.192.in-addr.arpa. The resolver needs to be able to
re-use the forward DNS glue to get to the reverse DNS zone.

Tony.
-- 
f.anthony.n.finch  <dot@dotat.at>  http://dotat.at/
Great Orme Head to the Mull of Galloway: East or southeast 4 to 6. Smooth or
slight, occasionally moderate in west. Fair. Good.