Re: [dns-privacy] re-evaluation of the draft, was Re: [Fwd: New Version Notification for draft-vandijk-dprive-ds-dot-signal-and-pin-00.txt]

Shumon Huque <shuque@gmail.com> Tue, 09 June 2020 17:44 UTC

Return-Path: <shuque@gmail.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 CA6963A0C26 for <dns-privacy@ietfa.amsl.com>; Tue, 9 Jun 2020 10:44:14 -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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 df2BfBy63ojP for <dns-privacy@ietfa.amsl.com>; Tue, 9 Jun 2020 10:44:13 -0700 (PDT)
Received: from mail-ej1-x636.google.com (mail-ej1-x636.google.com [IPv6:2a00:1450:4864:20::636]) (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 2F1043A0C1C for <dns-privacy@ietf.org>; Tue, 9 Jun 2020 10:44:13 -0700 (PDT)
Received: by mail-ej1-x636.google.com with SMTP id x1so23320517ejd.8 for <dns-privacy@ietf.org>; Tue, 09 Jun 2020 10:44:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=qUop5EbJP+Zm5iUtmdYUNZpeNOik0qFC6//JXWR4KOM=; b=HV5wXHr16A/T054WgsyqRxPdMp+eEKjHOdn6FwQYUWQWfb+96W092GWv6ggbO21I9r 9LKBJOcB2j6WFdFuE/nglZUmBGXkUWaKeog+uDJ5wrdiChUSlnr/CbDTWhZSo9xnzoTf ct+qUwn1HOcJF2QOzr6hStmeryDwKUKtcrh4agvJejMALXkjMSofqWu7fn4Co45snMqB VAL85e9huVknk9NfsYaflDs5hOC7AAnwxunm9riJlh6ZmaPtYKKJMkGjXF4HL2NJxjk4 6FZjuauFo07Z3950yjs2C7t7nhvaV84plkMgtipXZYLBvQsd6l5P7Qi7Ud5L6gmnPxoP GsWQ==
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=qUop5EbJP+Zm5iUtmdYUNZpeNOik0qFC6//JXWR4KOM=; b=kFHAWt4SGNJgH9evwcUfj2rrPUSQ/fMt+gLYlGZAoUiAJJGsvNlNUW3sXkuuuN88Y5 mh9exI8Ft1zZPLMOzCpauWlEfh9VYt0fcI/rDpk8PjlGO5oB+XfXbawyoBElScQAjONX WNSvTpJC9WJ9Ck8oETYbNH7UJH+xx5G8CdL7+HXYcnh50N6shbTR5uV/tDCcuVzmLQoM SYalzH77WmjaAaDLoclORDNlFfH3ZsXF1o2Emsj2wyKhMSjR4YpFVMUkpLURbULtpeup tieKAn4geJikgn2ifpbWGmqeiLf6M2wN8HBZdVTd04H7MMY2JqQ/FWTAe5+Rakbn5G80 cb3A==
X-Gm-Message-State: AOAM532LBTrxmdHb7uoD2SiKHr94wdYeJWjlEhXPpgaLfkB1RHfjbcgf YSLMfjBaHzulOEeq7bprV+503RDAl189tI2qsLo=
X-Google-Smtp-Source: ABdhPJwDNxDMd3QIDQW60sAlNNSc2CvZru0RfPoVzQ+u05Tei/LGaX9XLT2XqMymNt9ZjarwnWxSHpAmxwEG6vTsnhE=
X-Received: by 2002:a17:906:840d:: with SMTP id n13mr26468331ejx.49.1591724651563; Tue, 09 Jun 2020 10:44:11 -0700 (PDT)
MIME-Version: 1.0
References: <158987990316.29446.4343920282978207647@ietfa.amsl.com> <a15e2d1df86820f2483516662d3712d8a60161cd.camel@powerdns.com> <eaf5d580-ec3c-bf7e-2987-cc03ebcde80a@huitema.net> <1b323302a42ea7559b9d76b041d4ebef15ac20cc.camel@powerdns.com> <alpine.LRH.2.22.394.2006031140570.9753@bofh.nohats.ca> <3f2d4c33-3dd1-be36-9085-e27b9d98b032@robingeuze.nl> <CAHPuVdXVrf83Bjjge88QkaDjC5vTvafmaQ-XtQYBqF5KfA+WNQ@mail.gmail.com> <98ea50619250d5f27ed640251f754195eecccb62.camel@powerdns.com>
In-Reply-To: <98ea50619250d5f27ed640251f754195eecccb62.camel@powerdns.com>
From: Shumon Huque <shuque@gmail.com>
Date: Tue, 09 Jun 2020 13:44:00 -0400
Message-ID: <CAHPuVdUoZVecj5Jfd6NxyJ-cRhTJTS1N8vcC5pC3uWQECLOCnQ@mail.gmail.com>
To: Peter van Dijk <peter.van.dijk@powerdns.com>
Cc: dns-privacy@ietf.org
Content-Type: multipart/alternative; boundary="0000000000006fceb705a7aa4618"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dns-privacy/zJK14zeMtACMSZH9b5LWL77ucoY>
Subject: Re: [dns-privacy] re-evaluation of the draft, was Re: [Fwd: New Version Notification for draft-vandijk-dprive-ds-dot-signal-and-pin-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: Tue, 09 Jun 2020 17:44:15 -0000

On Tue, Jun 9, 2020 at 1:26 PM Peter van Dijk <peter.van.dijk@powerdns.com>
wrote:

> Hi Shumon,
>
> On Tue, 2020-06-09 at 12:37 -0400, Shumon Huque wrote:
>
> I think TLSA in the child zone could be made to work though, so I think
> it's
> still worth thinking about some more. Here's my suggestion:
>
> Place the TLSA record at the zone name, i.e. at the apex of the child
> zone, rather
> than at the NS server names: _853._tcp.example.com/IN/TLSA.
>
> That solves the name authentication problem because the nameserver names
> aren't authenticated in the referral, but the zone name is authenticated
> via the
> signed DS RRset.
>
>
> What SNI do you then use when connecting to a name server?
>

Well, the client could just use the zone name as the SNI, no? You can assign
certificates with the same name but different keys to each of the
nameservers.
Or if the administrator is willing to do shared certificates/keys, that
would
work too.

The initial bootstrapping problem can be addressed by using the TLS
> DNSSEC chain extension, which can deliver the zone's TLSA
> RRset on first contact, in-band in the TLS handshake. You mention the
> possibility of "stuffing the TLSA chain in TLS" - I wanted to make sure
> you knew the design work for this mechanism is already done:
>
>    https://tools.ietf.org/html/draft-dukhovni-tls-dnssec-chain-01
>
>
> I know that that is exactly what Robin referred to :)
>

Ok, I just wanted to make sure.


>
> Using the TLSA RR means that we can now support the full semantics
> of TLSA: EE cert, auth, local TA issued cert, or PKIX/WebPKI constraints.
>
>
> No, because you don't know the name server names with certainty, so you're
> still limited to pinning the key, the last cert in the chain, or using a
> private CA. WebPKI most certainly is out, because ns.attacker.org could
> also get a cert from the same public CA.
>

Here again, if the protocol expects only the zone name, we could
adapt. For example, I could deploy a DANE-TA CA, and use that to
issue individual certs for the zone name. So I don't think we are
actually limited to just pinning the EE cert's keys (even if that may
turn out to be the most popular deployment choice).

Shumon.