Re: [dns-privacy] re-evaluation of the draft, was Re: [Fwd: New Version Notification for draft-vandijk-dprive-ds-dot-signal-and-pin-00.txt]
Peter van Dijk <peter.van.dijk@powerdns.com> Tue, 09 June 2020 17:26 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 9BBFB3A0AEC for <dns-privacy@ietfa.amsl.com>; Tue, 9 Jun 2020 10:26:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.62
X-Spam-Level:
X-Spam-Status: No, score=-1.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 ZdGREZY8_iKN for <dns-privacy@ietfa.amsl.com>; Tue, 9 Jun 2020 10:26:29 -0700 (PDT)
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 C5E913A0AEA for <dns-privacy@ietf.org>; Tue, 9 Jun 2020 10:26:28 -0700 (PDT)
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 4115B6A25C; Tue, 9 Jun 2020 19:26:25 +0200 (CEST)
Received: from plato (e82143.upc-e.chello.nl [213.93.82.143]) (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 216EA3C02C8; Tue, 9 Jun 2020 19:26:25 +0200 (CEST)
Message-ID: <98ea50619250d5f27ed640251f754195eecccb62.camel@powerdns.com>
From: Peter van Dijk <peter.van.dijk@powerdns.com>
To: dns-privacy@ietf.org
Date: Tue, 09 Jun 2020 19:26:24 +0200
In-Reply-To: <CAHPuVdXVrf83Bjjge88QkaDjC5vTvafmaQ-XtQYBqF5KfA+WNQ@mail.gmail.com>
References: <158987990316.29446.4343920282978207647@ietfa.amsl.com> <a15e2d1df86820f2483516662d3712d8a60161cd.camel@powerdns.com> <eaf5d580-ec3c-bf7e-2987-cc03ebcde80a@huitema.net> <1b323302a42ea7559b9d76b041d4ebef15ac20cc.camel@powerdns.com> <alpine.LRH.2.22.394.2006031140570.9753@bofh.nohats.ca> <3f2d4c33-3dd1-be36-9085-e27b9d98b032@robingeuze.nl> <CAHPuVdXVrf83Bjjge88QkaDjC5vTvafmaQ-XtQYBqF5KfA+WNQ@mail.gmail.com>
Organization: PowerDNS.COM B.V.
Content-Type: multipart/alternative; boundary="=-Pg30VpTkq9JrzBQFxbwV"
User-Agent: Evolution 3.30.5-1.1
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/dns-privacy/0qqHc8Xb6pjues_mdwMLn9-l4jA>
Subject: Re: [dns-privacy] re-evaluation of the draft, was Re: [Fwd: New Version Notification for draft-vandijk-dprive-ds-dot-signal-and-pin-00.txt]
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: Tue, 09 Jun 2020 17:26:31 -0000
Hi Shumon, On Tue, 2020-06-09 at 12:37 -0400, Shumon Huque wrote: > I think TLSA in the child zone could be made to work though, so I think it's > still worth thinking about some more. Here's my suggestion: > > Place the TLSA record at the zone name, i.e. at the apex of the child zone, rather > than at the NS server names: _853._tcp.example.com/IN/TLSA. > > That solves the name authentication problem because the nameserver names > aren't authenticated in the referral, but the zone name is authenticated via the > signed DS RRset. What SNI do you then use when connecting to a name server? > The initial bootstrapping problem can be addressed by using the TLS > DNSSEC chain extension, which can deliver the zone's TLSA > RRset on first contact, in-band in the TLS handshake. You mention the > possibility of "stuffing the TLSA chain in TLS" - I wanted to make sure > you knew the design work for this mechanism is already done: > > https://tools.ietf.org/html/draft-dukhovni-tls-dnssec-chain-01 I know that that is exactly what Robin referred to :) > Using the TLSA RR means that we can now support the full semantics > of TLSA: EE cert, auth, local TA issued cert, or PKIX/WebPKI constraints. No, because you don't know the name server names with certainty, so you're still limited to pinning the key, the last cert in the chain, or using a private CA. WebPKI most certainly is out, because ns.attacker.org could also get a cert from the same public CA. Kind regards, -- Peter van Dijk PowerDNS.COM BV - https://www.powerdns.com/
- [dns-privacy] [Fwd: New Version Notification for … Peter van Dijk
- Re: [dns-privacy] [Fwd: New Version Notification … Mikael Abrahamsson
- Re: [dns-privacy] [Fwd: New Version Notification … Jeremy Harris
- Re: [dns-privacy] [Fwd: New Version Notification … Paul Wouters
- Re: [dns-privacy] [Fwd: New Version Notification … Peter van Dijk
- Re: [dns-privacy] [Fwd: New Version Notification … Peter van Dijk
- Re: [dns-privacy] [Fwd: New Version Notification … Petr Špaček
- Re: [dns-privacy] [Fwd: New Version Notification … Peter van Dijk
- Re: [dns-privacy] [Fwd: New Version Notification … Paul Wouters
- Re: [dns-privacy] [Fwd: New Version Notification … Christian Huitema
- Re: [dns-privacy] [Fwd: New Version Notification … Peter van Dijk
- Re: [dns-privacy] [Fwd: New Version Notification … Paul Wouters
- Re: [dns-privacy] [Fwd: New Version Notification … Peter van Dijk
- Re: [dns-privacy] [Fwd: New Version Notification … Ondřej Surý
- Re: [dns-privacy] [Fwd: New Version Notification … Peter van Dijk
- Re: [dns-privacy] [Fwd: New Version Notification … Paul Wouters
- Re: [dns-privacy] [Fwd: New Version Notification … Peter van Dijk
- Re: [dns-privacy] [Fwd: New Version Notification … Peter van Dijk
- Re: [dns-privacy] [Fwd: New Version Notification … Ben Schwartz
- Re: [dns-privacy] [Fwd: New Version Notification … Petr Špaček
- Re: [dns-privacy] [Fwd: New Version Notification … Peter van Dijk
- Re: [dns-privacy] [Fwd: New Version Notification … Ben Schwartz
- Re: [dns-privacy] [Fwd: New Version Notification … Tony Finch
- Re: [dns-privacy] [Fwd: New Version Notification … Paul Wouters
- Re: [dns-privacy] [Fwd: New Version Notification … Ben Schwartz
- Re: [dns-privacy] [Fwd: New Version Notification … Paul Wouters
- Re: [dns-privacy] [Fwd: New Version Notification … Paul Wouters
- Re: [dns-privacy] [Fwd: New Version Notification … Stephen Farrell
- Re: [dns-privacy] [Fwd: New Version Notification … Petr Špaček
- Re: [dns-privacy] [Fwd: New Version Notification … Paul Wouters
- Re: [dns-privacy] [Fwd: New Version Notification … Shumon Huque
- Re: [dns-privacy] [Fwd: New Version Notification … Eric Rescorla
- Re: [dns-privacy] [Fwd: New Version Notification … Paul Wouters
- Re: [dns-privacy] [Fwd: New Version Notification … Eric Rescorla
- Re: [dns-privacy] [Fwd: New Version Notification … Ben Schwartz
- Re: [dns-privacy] [Fwd: New Version Notification … Paul Wouters
- Re: [dns-privacy] [Fwd: New Version Notification … Petr Špaček
- Re: [dns-privacy] [Fwd: New Version Notification … Peter van Dijk
- Re: [dns-privacy] [Fwd: New Version Notification … Peter van Dijk
- Re: [dns-privacy] [Fwd: New Version Notification … Peter van Dijk
- Re: [dns-privacy] [Fwd: New Version Notification … Tony Finch
- Re: [dns-privacy] [Fwd: New Version Notification … Paul Wouters
- Re: [dns-privacy] [Fwd: New Version Notification … Paul Wouters
- Re: [dns-privacy] [Fwd: New Version Notification … Peter van Dijk
- Re: [dns-privacy] [Fwd: New Version Notification … Paul Wouters
- Re: [dns-privacy] [Fwd: New Version Notification … Peter van Dijk
- Re: [dns-privacy] [Fwd: New Version Notification … Peter van Dijk
- Re: [dns-privacy] [Fwd: New Version Notification … Peter van Dijk
- Re: [dns-privacy] [Fwd: New Version Notification … Paul Wouters
- Re: [dns-privacy] [Fwd: New Version Notification … Paul Wouters
- Re: [dns-privacy] [Fwd: New Version Notification … Christian Huitema
- Re: [dns-privacy] [Fwd: New Version Notification … Peter van Dijk
- [dns-privacy] re-evaluation of the draft, was Re:… Paul Wouters
- Re: [dns-privacy] re-evaluation of the draft, was… Robin Geuze
- Re: [dns-privacy] re-evaluation of the draft, was… Shumon Huque
- Re: [dns-privacy] re-evaluation of the draft, was… Peter van Dijk
- Re: [dns-privacy] re-evaluation of the draft, was… Shumon Huque
- Re: [dns-privacy] NS names, was re-evaluation of … John Levine
- Re: [dns-privacy] NS names, was re-evaluation of … Shumon Huque
- Re: [dns-privacy] re-evaluation of the draft, was… Paul Wouters
- Re: [dns-privacy] NS names, was re-evaluation of … Christian Huitema
- Re: [dns-privacy] re-evaluation of the draft, was… Peter van Dijk
- Re: [dns-privacy] NS names, was re-evaluation of … Shumon Huque
- Re: [dns-privacy] NS names, was re-evaluation of … Paul Wouters
- Re: [dns-privacy] NS names, was re-evaluation of … Shumon Huque
- Re: [dns-privacy] NS names, was re-evaluation of … Bill Woodcock
- Re: [dns-privacy] NS names, was re-evaluation of … Shumon Huque
- Re: [dns-privacy] NS names, was re-evaluation of … Bill Woodcock
- Re: [dns-privacy] NS names, was re-evaluation of … John R Levine
- Re: [dns-privacy] NS names, was re-evaluation of … Brian Dickson
- Re: [dns-privacy] bootstrapping NS names, was re-… John Levine
- Re: [dns-privacy] bootstrapping NS names, was re-… Brian Dickson
- Re: [dns-privacy] bootstrapping NS names, was re-… John R Levine