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

Paul Hoffman <> Fri, 11 June 2021 01:48 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id F2F543A2316 for <>; Thu, 10 Jun 2021 18:48:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id GTpyqluVMwwb for <>; Thu, 10 Jun 2021 18:48:40 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 8FEA33A2313 for <>; Thu, 10 Jun 2021 18:48:40 -0700 (PDT)
Received: from ( []) by ( with ESMTPS id 15B1mcLo019410 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 11 Jun 2021 01:48:39 GMT
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.858.12; Thu, 10 Jun 2021 18:48:37 -0700
Received: from ([]) by ([]) with mapi id 15.02.0858.012; Thu, 10 Jun 2021 18:48:37 -0700
From: Paul Hoffman <>
To: Paul Wouters <>
CC: "" <>
Thread-Topic: [dns-privacy] [Ext] Fwd: New Version Notification for draft-schwartz-dprive-name-signal-00.txt
Thread-Index: AQHXXi1YHkPARjyuyES4VurfDgNBBKsOgMiA
Date: Fri, 11 Jun 2021 01:48:37 +0000
Message-ID: <>
References: <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
x-originating-ip: []
x-source-routing-agent: Processed
Content-Type: multipart/signed; boundary="Apple-Mail=_25800EBE-C8E0-415D-B139-DF7D33E9FC52"; protocol="application/pkcs7-signature"; micalg=sha-256
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.391, 18.0.761 definitions=2021-06-10_14:2021-06-10, 2021-06-10 signatures=0
Archived-At: <>
Subject: Re: [dns-privacy] [Ext] Fwd: New Version Notification for draft-schwartz-dprive-name-signal-00.txt
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 11 Jun 2021 01:48:45 -0000

On Jun 10, 2021, at 3:17 PM, Paul Wouters <> wrote:
> On Thu, 10 Jun 2021, Paul Hoffman wrote:
>>> I understand the desire but I don’t agree as this signal is insecure, and foresee TLDs abusing this as potential nation state monitor / privacy leak.
>> Please say more. I don't see how this proposal leaks anything that could not be trivially determined by probing.
> 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.

> 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"?

>>> I still prefer something with DS than can be signed, and validated by the child as their intend via CDS. With transparency monitoring.
>>> If we are using overloading, might as well overload securely.
>> If you write up a draft, I'm happy to send responses to particular statements in the draft. I don't see how such a DS could be specified in a way that would get more than a trivial amount of deployment. I would be happy to be wrong, given that DS is signed in the parent.
> 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.

--Paul Hoffman