Re: [TLS] Interim notes and draft-ietf-tls-dnssec-chain-extension next steps
Nico Williams <nico@cryptonector.com> Wed, 10 October 2018 18:54 UTC
Return-Path: <nico@cryptonector.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F29D126F72 for <tls@ietfa.amsl.com>; Wed, 10 Oct 2018 11:54:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cryptonector.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 l7d7iUUsSm-k for <tls@ietfa.amsl.com>; Wed, 10 Oct 2018 11:54:20 -0700 (PDT)
Received: from pdx1-sub0-mail-a65.g.dreamhost.com (pop.dreamhost.com [64.90.62.162]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F3C8E124BE5 for <tls@ietf.org>; Wed, 10 Oct 2018 11:54:19 -0700 (PDT)
Received: from pdx1-sub0-mail-a65.g.dreamhost.com (localhost [127.0.0.1]) by pdx1-sub0-mail-a65.g.dreamhost.com (Postfix) with ESMTP id 7FC6A7FB7D; Wed, 10 Oct 2018 11:54:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=nn+GQiF3sE9FcP /OdGiqQ02Og9g=; b=M1mOo/xDyTJIcPcrYcqAz3+FRnhGHnaoH8tfFgQKnLTCpz GxKIS25PNPnQQWmaLVBQF0DpEOFrgOy5bsHO5Uh+OPNJbTToIe/nncNYUkXp/QfQ WoDpSqueNoAiQCb+ZDoBw/h/OvkQwt6ulNaGV0bfflUUTHtm1PC4QF914x1a4=
Received: from localhost (unknown [24.28.108.183]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by pdx1-sub0-mail-a65.g.dreamhost.com (Postfix) with ESMTPSA id DF89F7FB6E; Wed, 10 Oct 2018 11:54:17 -0700 (PDT)
Date: Wed, 10 Oct 2018 13:54:15 -0500
X-DH-BACKEND: pdx1-sub0-mail-a65
From: Nico Williams <nico@cryptonector.com>
To: Christopher Wood <christopherwood07@gmail.com>
Cc: "<tls@ietf.org>" <tls@ietf.org>
Message-ID: <20181010185414.GA22913@localhost>
References: <CAO8oSXnv5Gpdw-0c9jXtx1rQqpgwmfrZyiFgHF=Kd5qWZSMPCA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <CAO8oSXnv5Gpdw-0c9jXtx1rQqpgwmfrZyiFgHF=Kd5qWZSMPCA@mail.gmail.com>
User-Agent: Mutt/1.5.24 (2015-08-30)
X-VR-OUT-STATUS: OK
X-VR-OUT-SCORE: -100
X-VR-OUT-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgedtkedrudeigdduvdelucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuggftfghnshhusghstghrihgsvgdpffftgfetoffjqffuvfenuceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujfgurhepfffhvffukfhfgggtuggjfgesthdtredttdervdenucfhrhhomheppfhitghoucghihhllhhirghmshcuoehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmqeenucfkphepvdegrddvkedruddtkedrudekfeenucfrrghrrghmpehmohguvgepshhmthhppdhhvghloheplhhotggrlhhhohhsthdpihhnvghtpedvgedrvdekrddutdekrddukeefpdhrvghtuhhrnhdqphgrthhhpefpihgtohcuhghilhhlihgrmhhsuceonhhitghosegtrhihphhtohhnvggtthhorhdrtghomheqpdhmrghilhhfrhhomhepnhhitghosegtrhihphhtohhnvggtthhorhdrtghomhdpnhhrtghpthhtohepnhhitghosegtrhihphhtohhnvggtthhorhdrtghomhenucevlhhushhtvghrufhiiigvpedt
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/Q0WCLuxOvSfEwWxlIgB-jQuk-dc>
Subject: Re: [TLS] Interim notes and draft-ietf-tls-dnssec-chain-extension next steps
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 10 Oct 2018 18:54:22 -0000
On Mon, Oct 08, 2018 at 05:09:40PM -0700, Christopher Wood wrote: > Notes from the TLS interim meeting held in September are now online > [1]. To recap, the meeting attempted to focus on three primary > questions: > > 1. What is the fundamental security issue? What is the purpose of this > extension? Broad utility vs. narrow utility. As specified the extension is only of use to clients that can mandate it and hard-fail when it is not supported. We are asking for Motherhood and Apple Pie. Who could disagree?! And yet many do. There is a reason for that. >From the concall and off-list exchanges I believe that the disagreement with Motherhood and Apple Pie stems from a belief that we can't get them at an acceptable price. People have been traumatized by the HPKP experience and want nothing like it -- and *this* sure is something I believe we *all* agree on at this time. Therefore I propose that we put the cart before the horse. I propose that we start by showing that the proposed Motherhood and Apple Pie feature is indeed cheap and risk-free, and not HPKP redux. If we can examine that statement, that the proposal is cheap and risk-free, and if we can come to agreement on that, then agreement that we should aim for broad utility will surely follow. Otherwise, and if no one else has an alternative cheap-and-risk-free Motherhood and Apple Pie proposal, then we can safely reject broad utility. HPKP is a *footgun*. Any attempt to add new footguns like HPKP must be rejected. > 2. Under what circumstances should DNS records received in the > extension be cached and reused for future use? The payload contents are DNS responses. They may be cached, or not, as usual. The choice of transport does not affect this. > 3. Is pinning required? If so, what is pinned, and at what layer(s) > should it be implemented? If clients keep no state at all (about the DANE extension) between TLS handshakes, then the extension can be stripped off (or the client redirected to a server that won't provide it). This is the source of the observation about broad vs. narrow utility. Now, we cannot, indeed MUST NOT, pin anything that would make this like HPKP. Otherwise we'd have a footgun for sure! That means: - MUST NOT pin *any facts* about how the server is to be authenticated! Meaning: - MUST NOT pin public key material (private keys get lost, rotated) - MUST NOT pin EE certs (same reason) - MUST NOT pin TLSA RRset RDATAs (same reason) - MUST NOT pin intermediate certs (operator might need to switch CAs) - MUST NOT pin trust anchors (same answer) - MUST NOT pin TLSA RRset existence (zone might stop being signed) - MUST NOT pin whether the server's RRsets are signed (same) - MUST NOT pin any other authentication facts not listed above That's a pretty extreme list of must-not-pin items. ALSO: whatever state is kept -whatever is pinned-, the pin must be trivial for server operators to clear. There is only one thing that's left to could get pinned: whether the server supports the extension, with an expiration time on the pin. We need to demonstrate that pinning server support for the extension does not a footgun make. That's on us. The test for whether we have a footgun is: can the server operator clear the client pins trivially in the event of a screwup? If the server operator can clear the pins trivially, then we have no footgun. Well, we have 1 way to set the pin, and 3 ways to clear it. There must be methods for clearing the pin that are no more difficult to execute than setting the pin. To set the pin: - the client MUST have requested the extension - the server MUST respond with the extension - the server MUST have TLSA RRs and a valid DNSSEC chain - the client MUST have authenticated the server per-DANE using the attached chain - the server MUST have advertised a non-zero pin time To clear the pin: - method #1: Same as setting the pin, server advertises a zero pin time. - method #2: Unpublish TLSA RRs or unsign the zone, therefore the server MUST send an authenticated denial of existence (DoE) back to the client. The client then MUST clear the pin after authenticating the DoE regardless of whether it successfully authenticates the server. (Recall that the fact of a zone's not being signed can itself be proved in DNSSEC, thus, no longer signing the zone leads to authenticated denial of existence.) - method #3: Same as method #2, but the client can independently check DNS if the server somehow does not support the extension. This only works for clients that can reach the DNS, but that would be e.g., most browsers, most of the time. That is, this works for clients for which this extension functions as an optimization. Clients that cannot reach the DNS directly were likely ones like DPRIV that want to hard-fail on server non-support for the extension anyways. Because there is a method for clearing the pin involving only local configuration (#1) no different from setting the pin, and because there is a method for clearing the pin involving only DNS change control (#2 and #3), including one (#3) where the server need not even support the extension that it needed to set the pin in the first place... ...there is clearly no footgun: the server operator can clear the pin at will with less -and in no case more- effort than it took to get the pin set in the first place. Now, to be fair there was also discussion of a denial of service attack. In the DoS attack an attacker who thoroughly compromises the server can install the extension, set the pin, then uninstall the extension and watch the server operator suffer. This also applies to HPKP, and it never happened, but the HPKP footgun was fired, so the DoS threat in not realistic just based on experience. But also, the DoS requires such a thorough compromise of the server as to make the DoS concern the operator's least concern. But suppose the DoS threat weighs heavily on everyone's mind! Clearly, if server support for the extension is universal, then the DoS threat vanishes. Therefore we offer a mitigation for the DoS case: slow ramped client- side scaling of advertised pin times. That is, initially the maximum advertised pin time could be just hours, and it could stay that way for N years, then quickly ramp up to a maximum in the range of a few years. That is, we can make pinning something that comes into force only enough time into the future that anyone suffering from a DoS before then need only wait a short amount of time, and anyone suffering from a DoS after then need only enable a by-then-universally-supported extension. Surely client-side pin scaling based on time since the extension's publication as RFC is enough to dismiss the DoS concern entirely. Thus we have neither footgun nor DoS concerns. Yes, we can haz Motherhood and Apple Pie. Q.E.D. Nico --
- [TLS] Interim notes and draft-ietf-tls-dnssec-cha… Christopher Wood
- Re: [TLS] Interim notes and draft-ietf-tls-dnssec… Tom Ritter
- Re: [TLS] Interim notes and draft-ietf-tls-dnssec… Viktor Dukhovni
- Re: [TLS] Interim notes and draft-ietf-tls-dnssec… Nico Williams
- Re: [TLS] Interim notes and draft-ietf-tls-dnssec… Daniel Kahn Gillmor
- Re: [TLS] Interim notes and draft-ietf-tls-dnssec… Viktor Dukhovni
- Re: [TLS] Interim notes and draft-ietf-tls-dnssec… John Levine
- Re: [TLS] Interim notes and draft-ietf-tls-dnssec… Benjamin Kaduk
- Re: [TLS] Interim notes and draft-ietf-tls-dnssec… Viktor Dukhovni
- Re: [TLS] Interim notes and draft-ietf-tls-dnssec… Paul Wouters
- Re: [TLS] Interim notes and draft-ietf-tls-dnssec… Viktor Dukhovni
- Re: [TLS] Interim notes and draft-ietf-tls-dnssec… Eric Rescorla
- Re: [TLS] Interim notes and draft-ietf-tls-dnssec… Benjamin Kaduk
- Re: [TLS] Interim notes and draft-ietf-tls-dnssec… Sean Turner
- Re: [TLS] Interim notes and draft-ietf-tls-dnssec… Viktor Dukhovni
- Re: [TLS] Interim notes and draft-ietf-tls-dnssec… Eric Rescorla
- Re: [TLS] Interim notes and draft-ietf-tls-dnssec… Benjamin Kaduk