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

Peter van Dijk <peter.van.dijk@powerdns.com> Fri, 29 May 2020 13:55 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 4767A3A08D7 for <dns-privacy@ietfa.amsl.com>; Fri, 29 May 2020 06:55:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.621
X-Spam-Level:
X-Spam-Status: No, score=-1.621 tagged_above=-999 required=5 tests=[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 NfubEUH0BWaG for <dns-privacy@ietfa.amsl.com>; Fri, 29 May 2020 06:55:06 -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 AF8C93A08D4 for <dns-privacy@ietf.org>; Fri, 29 May 2020 06:55:06 -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 0D6FA6A301; Fri, 29 May 2020 15:55:04 +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 CB3EF3C02D9; Fri, 29 May 2020 15:55:03 +0200 (CEST)
Message-ID: <f2584afc08bcbc7b1e2de98c23f51a086205b5ba.camel@powerdns.com>
From: Peter van Dijk <peter.van.dijk@powerdns.com>
To: dns-privacy@ietf.org
Date: Fri, 29 May 2020 15:55:03 +0200
In-Reply-To: <alpine.DEB.2.20.2005280037220.18104@grey.csi.cam.ac.uk>
References: <158987990316.29446.4343920282978207647@ietfa.amsl.com> <a15e2d1df86820f2483516662d3712d8a60161cd.camel@powerdns.com> <alpine.LRH.2.21.2005191134560.13722@bofh.nohats.ca> <ec6bc9248179a9ab56ea490f82b14c7e90ffe819.camel@powerdns.com> <alpine.LRH.2.21.2005241222410.4172@bofh.nohats.ca> <36E4371F-BCBE-43F7-9D4B-8439B3FF1D2A@isc.org> <aa745f51e4b7fd0955ae9e444416772b32c75dbf.camel@powerdns.com> <alpine.DEB.2.20.2005280037220.18104@grey.csi.cam.ac.uk>
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: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dns-privacy/gBFmypNs6OnZGx8a8hjyiT9xBG4>
Subject: Re: [dns-privacy] [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: Fri, 29 May 2020 13:55:08 -0000

On Thu, 2020-05-28 at 00:43 +0100, Tony Finch wrote:
> Peter van Dijk <peter.van.dijk@powerdns.com> wrote:
> > On Tue, 2020-05-26 at 09:10 +0200, Ondřej Surý wrote:
> > > 1. Bit 7 of the Flags fields needs to be 0.
> > 
> > Definitely [...] I noted earlier that whatever flags we might need, it's
> > definitely *not* ZONE and SEP.
> > 
> > > 2. This needs a new Protocol number
> > 
> > I understand why you would say that, but I'd love to avoid doing that.
> > I wonder how much 'IETF' pain specifying another protocol number would
> > be, but what worries me more, ironically, is how it changes the format
> > away from normal DNSSEC. The draft was written such that a lot of
> > existing software needs no changes at all - I don't know if changing
> > the protocol number is compatible with that goal.
> 
> This made me wonder if this pseudorecord should be a KEY instead, and then
> I wondered how hard it would be to persuade existing code to generate a DS
> from a KEY.

That could make semantic sense, but would muddle the connection to
'DNSKEY in EPP' and 'CDNSKEY sync from child to parent'; I think it
would add more confusion than the semantic correctness is worth.

> But anyway, this signalling and verification scheme sounds clever and neat.

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