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

Ben Schwartz <bemasc@google.com> Fri, 11 June 2021 01:01 UTC

Return-Path: <bemasc@google.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 1894C3A21A2 for <dns-privacy@ietfa.amsl.com>; Thu, 10 Jun 2021 18:01:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.598
X-Spam-Level:
X-Spam-Status: No, score=-17.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com
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 fN_D1YleP3ZF for <dns-privacy@ietfa.amsl.com>; Thu, 10 Jun 2021 18:01:49 -0700 (PDT)
Received: from mail-wr1-x432.google.com (mail-wr1-x432.google.com [IPv6:2a00:1450:4864:20::432]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8CA633A219C for <dprive@ietf.org>; Thu, 10 Jun 2021 18:01:49 -0700 (PDT)
Received: by mail-wr1-x432.google.com with SMTP id i94so4195711wri.4 for <dprive@ietf.org>; Thu, 10 Jun 2021 18:01:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=6WPtoFRm1zM+DODBtG1/aOPEmxYMKunkzhm9453ODXc=; b=Tz++8eqjqhf9ChrCUzwdlKfOVKEBGy5u+sQ8wC4FhP9XKOKbWYGmmjTeJ4We5Vx2hn 5bnLiwWxoX0QbldZ1zNvU0UgRzQZ59aZADdbqCKCGJb+2EY3OT5BV1tyflBIXoczXdxp nNsvnMjNji48BJ68FiVASSbdORGhajTQkGEDXPnCAfetGhP1t2o844zU1vicWtCXFiz1 KC4l/ctsXBlYAAns/Y/zrKwO8I4m7+8IbFcCfyXtpMqjbZ/Y5FghmKQas2pMnU20rACI a2McVm+TffZGMO4OIqDLNoPTDlMQ3a4t9+AEAG8WkwiD3r8NGPb541fJx9Ik+0WAtQiO bLcQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=6WPtoFRm1zM+DODBtG1/aOPEmxYMKunkzhm9453ODXc=; b=No7VQWwkw7W6Ce6qHf71bHOg+RQemgaiMP4+bFBcG8pfUdqjn5UBIQs3iVYjCbtEJR x2Tv2izYMwN4j8eHZEAwmHyBsUBNcZ0cYJMnlobkVCqM+YsI7KQdqVOTqHjZxrHoRlIt Vrq5G4ghHcZ15MbgS+ehlF8BTjMgN3PEAEbVGGCKII1fqlHQ1EEOlZxUV4WDQEIHER50 NGulGyBr3PJn84G4H+iPMKY1GpGUWaW6jwtoqcpYz2N+0MsOAdoFzcr3dvHb6sAzfmhj jFZ3lUvAvUg/6n86IgpuKvSKP3JsNJqNwkk+GTOQvSqRPQvitIzFucG0sV5IXeI75bj+ aU5w==
X-Gm-Message-State: AOAM531dgfLBuCWI98IV6Qffey0UBYcgYYYqZlXBYCpJ9PAmfwN/DMH4 tBetLSvYBLMShXVBQRgDRL/6vc+1FHt9KGnXzQJkww==
X-Google-Smtp-Source: ABdhPJyMc88R+ghD1y+MreGpdKnvPehA3IoL0R8DxOQAnEufaj+8XFm+DqijqdEmtUTE140+kskbI534nkC5PacDyfs=
X-Received: by 2002:adf:f708:: with SMTP id r8mr1047328wrp.159.1623373307231; Thu, 10 Jun 2021 18:01:47 -0700 (PDT)
MIME-Version: 1.0
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>
In-Reply-To: <7690a489-eba7-f97f-5d55-5c124b6580b4@nohats.ca>
From: Ben Schwartz <bemasc@google.com>
Date: Thu, 10 Jun 2021 21:01:35 -0400
Message-ID: <CAHbrMsDo2JDadkbHMC_BB11OTJ9R7TexDc9NTLXn3yLsUKmcEw@mail.gmail.com>
To: Paul Wouters <paul@nohats.ca>
Cc: Paul Hoffman <paul.hoffman@icann.org>, "dprive@ietf.org" <dprive@ietf.org>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="000000000000562a1d05c4730d8f"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dns-privacy/PKWTHRo8PbJoc3g8rSJOsAU8orU>
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 01:01:54 -0000

On Thu, Jun 10, 2021 at 3:18 PM Paul Wouters <paul@nohats.ca> 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.
>
> 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 am personally quite interested in this kind of "DNSSEC Transparency"
logging, to try to catch misbehaving parents, but at the moment this is a
hypothetical.  This accountability mechanism is not in place today, and I
do not think that we should introduce it as a requirement for DPRIVE.
Specifically, I do not think "non-repudiability" of secure delegations is a
requirement for this working group at this time.

Our problem is hard enough without stacking it on top of other hard
problems.

...

> 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.


I agree.


> 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.


The ADoX draft starts from an alternative view, based on three observations:
* It's possible to get secured glue records from the root (e.g. with Zone
Digest).
* If the parent does ADoT, this also secures the glue records.
* While it may be difficult to get many TLDs to do ADoT, this is often a
prerequisite anyway: for most domains, the TLD+1 is the most sensitive
label.

I believe in this view.  However, I would also like to see a signal encoded
in the DS record, to support domains whose parent doesn't offer ADoT.  I
believe encoding the relevant information in NS and SVCB records actually
supports this, via a mechanism like DiS [1] or "CNSRRSIG" [2].  I would
like to see a version that (1) can protect the parent NS, (2) can protect
glue-like SVCB records, (3) is compatible with loosely coherent updates to
the glue, and (4) can be published today via CDS or CDNSKEY.  If we are
careful about exactly what we hash in each DS record, I think this is
possible.

[1]
https://datatracker.ietf.org/doc/html/draft-fujiwara-dnsop-delegation-information-signer
[2] https://mailarchive.ietf.org/arch/msg/dnsop/WsnbedpaNuK5bXI35L2wlk7e3rA/