[dns-privacy] DOTPIN, TLSA, and DiS

Peter van Dijk <peter.van.dijk@powerdns.com> Thu, 19 November 2020 13:06 UTC

Return-Path: <peter.van.dijk@powerdns.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 662413A0E33 for <dns-privacy@ietfa.amsl.com>; Thu, 19 Nov 2020 05:06:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.704
X-Spam-Level:
X-Spam-Status: No, score=0.704 tagged_above=-999 required=5 tests=[AC_FROM_MANY_DOTS=2.325, BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.276, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=no 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 MRnUFpyE-DCW for <dns-privacy@ietfa.amsl.com>; Thu, 19 Nov 2020 05:06:09 -0800 (PST)
Received: from mx3.open-xchange.com (alcatraz.open-xchange.com [87.191.39.187]) (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 3428D3A0FCE for <dprive@ietf.org>; Thu, 19 Nov 2020 05:06:02 -0800 (PST)
Received: from open-xchange.com (imap.open-xchange.com [10.20.30.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx3.open-xchange.com (Postfix) with ESMTPS id 5F3E36A2CF; Thu, 19 Nov 2020 14:06:00 +0100 (CET)
Received: from plato (84-81-54-175.fixed.kpn.net [84.81.54.175]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by open-xchange.com (Postfix) with ESMTPSA id 3E5443C0369; Thu, 19 Nov 2020 14:06:00 +0100 (CET)
Message-ID: <196c57a1f39d73fdbf0e7ee0c597bec2bec94148.camel@powerdns.com>
From: Peter van Dijk <peter.van.dijk@powerdns.com>
To: dprive@ietf.org
Date: Thu, 19 Nov 2020 14:05:59 +0100
Organization: PowerDNS.COM B.V.
Content-Type: text/plain; charset="UTF-8"
User-Agent: Evolution 3.30.5-1.1
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dns-privacy/xOVfHOR6FFFPxsFqM8eB44J-Db0>
Subject: [dns-privacy] DOTPIN, TLSA, and DiS
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, 19 Nov 2020 13:06:10 -0000

Please bear with me while I take you on a rollercoaster :-)

We introduce our three actors:

DOTPIN: https://datatracker.ietf.org/doc/draft-vandijk-dprive-ds-dot-signal-and-pin/ - pin TLS key material in a DS record. Scales badly if one NSset hosts 100k domains, basically preventing you from ever rolling keys. Written in the assumption that software changes at registries are hard, so it only asks them to allow one more DNSKEY Algorithm number. Has great latency properties.

TLSA: frequently touted as an ADoT signal/pin mechanism that would not have all the problems DOTPIN has. Makes sense, but requires some inventive thinking because delegation NSsets are not signed.

DiS: https://datatracker.ietf.org/doc/draft-fujiwara-dnsop-delegation-information-signer/ - a parent side signature over delegation data (NS records and glue), published as another DS record. Written in the assumption that we can actually change registry software (in this case, specifically, the DNSSEC signer).


We give our actors roles in a The Shining/MacGyver fanfic crossover:

DiS assumes registry processes can be changed a little. If we trust that they can change more than just a little, the following combination of factors can be proposed:
1. auth operators publish TLSA records for their NSes
2. the registry, while generating zone files, queries for those TLSA records
3. from the found TLSA records, the registry generates DOTPIN DSes
4. the DOTPIN DSes are published alongside the domain owner's NSes, DSes, and perhaps the DiS

This offers us:
1. TLSA-based keyrolls from a single 'source of truth' (the auth operator), at low delay (however often the registry re-lookups the TLSA and pushes a zonefile update)
2. a secure shortcut straight through the problematic unsigned nature of delegation NSsets
3. zero additional latency delivery of signal/pinning information to resolvers

However:
1. the complex moving parts are now in the registry, instead of in 10-20 pieces of (mostly open source) DNS software
2. as a whole, it's not pretty
3. an operator hosting 100k domains can make the TLD zone file grow by 100k records by publishing one additional (TLSA) record for one of their NSes

Kind regards,
-- 
Peter van Dijk
PowerDNS.COM BV - https://www.powerdns.com/