Re: [dns-privacy] [Ext] Fwd: New Version Notification for draft-schwartz-dprive-name-signal-00.txt

Paul Wouters <paul@nohats.ca> Fri, 11 June 2021 22:37 UTC

Return-Path: <paul@nohats.ca>
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 D2A2A3A0FD2 for <dns-privacy@ietfa.amsl.com>; Fri, 11 Jun 2021 15:37:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca
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 1P6TYtPOQtbK for <dns-privacy@ietfa.amsl.com>; Fri, 11 Jun 2021 15:37:12 -0700 (PDT)
Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (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 156313A0FCC for <dprive@ietf.org>; Fri, 11 Jun 2021 15:37:11 -0700 (PDT)
Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 4G1wh34WhwzKHB; Sat, 12 Jun 2021 00:37:07 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1623451027; bh=jxglyEBg147lqoLcUdx1fdN/bBV4/eLhGDucEMekse0=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=lcCmFMihe6CKmhcFhTp5hSRRnXGr2+ZwzQ75S+F3XaDUwGNnDOvc+uvGCdeCmqi+S qRB3kb4nYdjoZcoRPXMuUmXMwrWsRBQbLO+z9nXfpbIcIw3iIAoFzizNoaGKzAuiz3 rrOM/vV9Pj6mHfmoIg/pefKR7pXLRRMc0XC+FaZc=
X-Virus-Scanned: amavisd-new at mx.nohats.ca
Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id qBV1J7vwwu9V; Sat, 12 Jun 2021 00:37:06 +0200 (CEST)
Received: from bofh.nohats.ca (bofh.nohats.ca [193.110.157.194]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Sat, 12 Jun 2021 00:37:05 +0200 (CEST)
Received: by bofh.nohats.ca (Postfix, from userid 1000) id 5918881415; Fri, 11 Jun 2021 18:37:04 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 51D6481414; Fri, 11 Jun 2021 18:37:04 -0400 (EDT)
Date: Fri, 11 Jun 2021 18:37:04 -0400 (EDT)
From: Paul Wouters <paul@nohats.ca>
To: Paul Hoffman <paul.hoffman@icann.org>
cc: "dprive@ietf.org" <dprive@ietf.org>
In-Reply-To: <FCB9F7B7-EF02-4802-B184-C705E974541F@icann.org>
Message-ID: <a2d8c065-d3c1-33d1-784c-be78b5f24094@nohats.ca>
References: <e79ec68203cab16e1f199438208a124e5bbd2b24.camel@powerdns.com> <A3153F94-0D87-4FD1-B802-C87BC4EF6F43@nohats.ca> <F35486C2-02DA-4F7E-804F-CAFEA6EDB967@icann.org> <7690a489-eba7-f97f-5d55-5c124b6580b4@nohats.ca> <FCB9F7B7-EF02-4802-B184-C705E974541F@icann.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII; format=flowed
Archived-At: <https://mailarchive.ietf.org/arch/msg/dns-privacy/M6_CxG-cCzM2euxkegtBzLGpWXc>
Subject: Re: [dns-privacy] [Ext] Fwd: New Version Notification for draft-schwartz-dprive-name-signal-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, 11 Jun 2021 22:37:17 -0000

On Fri, 11 Jun 2021, Paul Hoffman wrote:

>> A nationstate could add unsigned NS glue to their zone for domains they
>> are interested in and trigger people('s resolvers) to go to "their"
>> secure transport IP and do logging.
>
> This is a problem with unsigned NS, not unsigned labels in the name.

Whereever the unsigned data at the parent is, that does not matter. It
could be the imaginary SVCB record at the parent. The problem is that
a nationstate can just add them to their TLD glue, and the child cannot
opt out of resolvers following the path from root to TLD to TLD's
resolver.

>> If you use DS, they would at least have to sign for it _and_ you can
>> verify the DS via CDS so now such a parent would have to do a lot more
>> and leave cryptogrpahic evidence of their efforts.
>
> Is your proposal "DS in parent and matching DNSKEY in the child"?

DS in parent and matching CDS in child. No need to pollute the child's
DNSKEY RRset and complicate validation.

>> We had several proposals written up. I don't think at this point we need
>> more or updated draft text.
>
> What you gave in your eariler is not sufficient for useful analysis, thus not for comparison. See my question above, for example.

We had a long discussion with Peter van Dijk's proposal on what to
encode in the DS or not. Eg do we add pubkey or not. Please read
the archive. If we reach agreement on what to encode and how to encode
it, it can be written as draft. Maybe even as update to Peter's draft.

Paul