[dns-privacy] [Fwd: [EXT] New Version Notification for draft-vandijk-dprive-ds-dot-signal-and-pin-01.txt]

Peter van Dijk <peter.van.dijk@powerdns.com> Mon, 13 July 2020 17:16 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 6DD7F3A13EB for <dns-privacy@ietfa.amsl.com>; Mon, 13 Jul 2020 10:16:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.102
X-Spam-Level: *
X-Spam-Status: No, score=1.102 tagged_above=-999 required=5 tests=[AC_FROM_MANY_DOTS=2.999, BAYES_00=-1.9, 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 Kdx7qDLJuj4N for <dns-privacy@ietfa.amsl.com>; Mon, 13 Jul 2020 10:16:39 -0700 (PDT)
Received: from mx4.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 DD7E33A13D2 for <dns-privacy@ietf.org>; Mon, 13 Jul 2020 10:16:38 -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 mx4.open-xchange.com (Postfix) with ESMTPS id 5A1D36A259; Mon, 13 Jul 2020 19:16:35 +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 235D23C0427; Mon, 13 Jul 2020 19:16:35 +0200 (CEST)
Message-ID: <8be56d973ff1757fb6395b5b2abdf90fe73e02ec.camel@powerdns.com>
From: Peter van Dijk <peter.van.dijk@powerdns.com>
To: dns-privacy@ietf.org
Date: Mon, 13 Jul 2020 19:16:34 +0200
References: <159463003055.14524.9899091401351118756@ietfa.amsl.com>
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/8TE295Dfqb7LlMF0g2EaSOvdKyY>
Subject: [dns-privacy] [Fwd: [EXT] New Version Notification for draft-vandijk-dprive-ds-dot-signal-and-pin-01.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: Mon, 13 Jul 2020 17:16:40 -0000

Hello,

please find below revision -01 of our proposal for enabling DoT from
resolver to authoritative.

New in this revision:

* a lot of clarifying text without changing the underlying protocol

* the DNSKEY flags field is now specified to be 257 instead of 0. We
know that this goes against the explicit wishes of some of those who
commented on -00, but we argue in the document that because our algo
TBD will have 'Zone Signing=N' in the IANA DNSKEY algo registry, the
flags do not mean 'ZONE' and 'SEP'. The value 257, meanwhile, is
believed to go down with registries much easier.

* we added a 'Design considerations' section that explains how this
protocol came to be, and why we did not go the TLSA route. You can
click through to it directly via 
https://tools.ietf.org/html/draft-vandijk-dprive-ds-dot-signal-and-pin-01#section-9

Furthermore, we have tried to do a review of this protocol against the
requirements of the DPRIVE phase 2 document.  You can find this review
(which might be updated outside of revisions of this draft or the phase
2 draft) via 
https://github.com/PowerDNS/parent-signals-dot/tree/master/draft-vandijk-dprive-ds-dot-signal-and-pin/yardsticks

We'll be presenting the draft at the IETF108 dprive session.

Kind regards,
Manu, Robin & Peter

-------- Forwarded Message --------
From: internet-drafts@ietf.org
To: Robin Geuze <robing@transip.nl>, Peter van Dijk <
peter.van.dijk@powerdns.com>, Emmanuel Bretelle <chantra@fb.com>
Subject: [EXT] New Version Notification for draft-vandijk-dprive-ds-
dot-signal-and-pin-01.txt
Date: Mon, 13 Jul 2020 01:47:10 -0700

A new version of I-D, draft-vandijk-dprive-ds-dot-signal-and-pin-01.txt
has been successfully submitted by Peter van Dijk and posted to the
IETF repository.

Name:		draft-vandijk-dprive-ds-dot-signal-and-pin
Revision:	01
Title:		Signalling Authoritative DoT support in DS records, with key pinning
Document date:	2020-07-13
Group:		Individual Submission
Pages:		14
URL:            https://www.ietf.org/internet-drafts/draft-vandijk-dprive-ds-dot-signal-and-pin-01.txt
Status:         https://datatracker.ietf.org/doc/draft-vandijk-dprive-ds-dot-signal-and-pin/
Htmlized:       https://tools.ietf.org/html/draft-vandijk-dprive-ds-dot-signal-and-pin-01
Htmlized:       https://datatracker.ietf.org/doc/html/draft-vandijk-dprive-ds-dot-signal-and-pin
Diff:           https://www.ietf.org/rfcdiff?url2=draft-vandijk-dprive-ds-dot-signal-and-pin-01

Abstract:
   This document specifies a way to signal the usage of DoT, and the
   pinned keys for that DoT usage, in authoritative servers.  This
   signal lives on the parent side of delegations, in DS records.  To
   ensure easy deployment, the signal is defined in terms of (C)DNSKEY.

                                                                                  


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat