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

Paul Wouters <paul@nohats.ca> Thu, 10 June 2021 15:36 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 CAD963A4454 for <dns-privacy@ietfa.amsl.com>; Thu, 10 Jun 2021 08:36:11 -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 f7y1IDIjMrIE for <dns-privacy@ietfa.amsl.com>; Thu, 10 Jun 2021 08:36:05 -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 7BE3A3A444F for <dns-privacy@ietf.org>; Thu, 10 Jun 2021 08:36:05 -0700 (PDT)
Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 4G17Nf24zHz735; Thu, 10 Jun 2021 17:36:02 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1623339362; bh=Badc7gU913ELrpwW88l7d5BLOmaVfrhQckLEEYdosBQ=; h=From:Subject:Date:References:Cc:In-Reply-To:To; b=GqnHT195HH+Uq7VH80SZq3ZpdwYK0xe9KFJoDlYTSHRftAs/3IZQS3MMcLT3tq8CB GNVbw/B1cU82gQQFt3kv9D5eaqMvpb6omXDT6ZMcc+0iUp3TJPYyrQDS/U4k2C/VVt wkonSGONcFY4B2kMpv6+VKcLJfmSXbAV3IpVUGd8=
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 QfAw0M_Poh-f; Thu, 10 Jun 2021 17:36:01 +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; Thu, 10 Jun 2021 17:36:01 +0200 (CEST)
Received: from smtpclient.apple (unknown [193.110.157.209]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by bofh.nohats.ca (Postfix) with ESMTPSA id 0AAA1803AA; Thu, 10 Jun 2021 11:36:00 -0400 (EDT)
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
From: Paul Wouters <paul@nohats.ca>
Mime-Version: 1.0 (1.0)
Date: Thu, 10 Jun 2021 11:35:58 -0400
Message-Id: <A3153F94-0D87-4FD1-B802-C87BC4EF6F43@nohats.ca>
References: <e79ec68203cab16e1f199438208a124e5bbd2b24.camel@powerdns.com>
Cc: DNS Privacy Working Group <dns-privacy@ietf.org>
In-Reply-To: <e79ec68203cab16e1f199438208a124e5bbd2b24.camel@powerdns.com>
To: Peter van Dijk <peter.van.dijk@powerdns.com>
X-Mailer: iPhone Mail (18E212)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dns-privacy/QVY6A2wHSNlTogdYXRESCUIz60s>
Subject: Re: [dns-privacy] 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: Thu, 10 Jun 2021 15:36:12 -0000

On Jun 10, 2021, at 03:12, Peter van Dijk <peter.van.dijk@powerdns.com> wrote:
> 
> 
> We don't feel that this is an "interim" solution because we don't think
> parent-side SVCB is likely to ever come, or be very useful if it both
> unsigned and rarely available.

Thanks for saying this. Although this is very obvious to those in the DNS/ICANN space, it seems the authors of SVCB still haven’t acknowledged this. It is important as it is pretty fundamental to the solution space.

> We propose that this be the actual,
> long-term solution.

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. It is also dangerous when used via resolvers.

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.

Paul