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

Paul Wouters <paul@nohats.ca> Thu, 10 June 2021 19:17 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 960623A1535 for <dns-privacy@ietfa.amsl.com>; Thu, 10 Jun 2021 12:17:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.096
X-Spam-Level:
X-Spam-Status: No, score=-2.096 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, RCVD_IN_DNSWL_BLOCKED=0.001, 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 uF82ViLLBffE for <dns-privacy@ietfa.amsl.com>; Thu, 10 Jun 2021 12:17:51 -0700 (PDT)
Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::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 DD8043A1536 for <dprive@ietf.org>; Thu, 10 Jun 2021 12:17:50 -0700 (PDT)
Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 4G1DJV4Yndz9nn; Thu, 10 Jun 2021 21:17:46 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1623352666; bh=FLvAVFjQFMHnxQAv0/sEzwkPJ9mGS8+QJj/V3FPQ3lA=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=U1DyWrSKGoB7Y4liFQdFuiWhStkMDgwOP29VyJNH3K18LdlmGX6vXscqzsgf6L4jh Yx1nCzD5erQzY6JzeJVCjXVFaEGnvVgfxM0Wdjzg4aIEDzGZRfYJ5qy6pZIbAt/xf3 NCh9UOS77zy17IxLxNv7L9z5CThEaoB5tQAIeuN0=
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 WLgpFEq0vpOy; Thu, 10 Jun 2021 21:17:44 +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 21:17:44 +0200 (CEST)
Received: by bofh.nohats.ca (Postfix, from userid 1000) id 84FAC80701; Thu, 10 Jun 2021 15:17:43 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 7DCC580700; Thu, 10 Jun 2021 15:17:43 -0400 (EDT)
Date: Thu, 10 Jun 2021 15:17:43 -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: <F35486C2-02DA-4F7E-804F-CAFEA6EDB967@icann.org>
Message-ID: <7690a489-eba7-f97f-5d55-5c124b6580b4@nohats.ca>
References: <e79ec68203cab16e1f199438208a124e5bbd2b24.camel@powerdns.com> <A3153F94-0D87-4FD1-B802-C87BC4EF6F43@nohats.ca> <F35486C2-02DA-4F7E-804F-CAFEA6EDB967@icann.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8BIT
Archived-At: <https://mailarchive.ietf.org/arch/msg/dns-privacy/tKvx2Bc7bnubyg-bdonGEkDznPU>
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: Thu, 10 Jun 2021 19:17:56 -0000

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.

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.

>> 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. We need to decide on what we want to signal,
how many RTTs we are willing to take, and whether or not to attempt to
protect in-bailiwick data.

I feel an insecure signal to signal privacy is the wrong starting point.
With DoH and DoT channels being used in the forwarding chain, we should
really insist on a signal that can be secured and not tampered with. We
are seeing an increase in nation states taking over whole products or
companies to MITM. Another Crypto AG or ANOM might already be running.

A secure signal can only feasably happen within a DS record encoding, as
that is the only secured record we have at the parent. If your position
is that starting from DNSSEC is futile, then we've already given full
control of DNS privacy to the browsers and they will just run with the
current "anycast means privacy" or "oblivious DoH" as the method, so in
that case we are done and no need to work on a draft anymore.

So in a way, we are in a BoF stage for this, not in a WG/draft stage
where it is useful to write down draft text. This is really where I
miss physical IETFs to go brainstorm with people in a single room or
bar.

Paul
ps. the above reasons are also why I am not enthousiastic about
anonymous DNS privacy as proposted in your draft. It does not add
enough privacy/security features compared to what's out there now.