Re: [TLS] some thoughts on dnssec-chain-extension, pinning, and broader semantics

Nico Williams <nico@cryptonector.com> Tue, 06 November 2018 22:44 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 3159012870E for <tls@ietfa.amsl.com>; Tue, 6 Nov 2018 14:44:07 -0800 (PST)
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, RCVD_IN_DNSWL_NONE=-0.0001] 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 mF5cSQb0Ug3P for <tls@ietfa.amsl.com>; Tue, 6 Nov 2018 14:44:05 -0800 (PST)
Received: from catfish.maple.relay.mailchannels.net (catfish.maple.relay.mailchannels.net [23.83.214.32]) (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 5623D126F72 for <tls@ietf.org>; Tue, 6 Nov 2018 14:44:05 -0800 (PST)
X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com
Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id 18ABB5C3B5A; Tue, 6 Nov 2018 22:44:02 +0000 (UTC)
Received: from pdx1-sub0-mail-a52.g.dreamhost.com (unknown [100.96.19.74]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id B48535C3A69; Tue, 6 Nov 2018 22:44:01 +0000 (UTC)
X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com
Received: from pdx1-sub0-mail-a52.g.dreamhost.com (pop.dreamhost.com [64.90.62.162]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:2500 (trex/5.16.2); Tue, 06 Nov 2018 22:44:02 +0000
X-MC-Relay: Neutral
X-MailChannels-SenderId: dreamhost|x-authsender|nico@cryptonector.com
X-MailChannels-Auth-Id: dreamhost
X-Name-Rock: 1bfccddf4a06355d_1541544241924_3181286454
X-MC-Loop-Signature: 1541544241924:4162192332
X-MC-Ingress-Time: 1541544241923
Received: from pdx1-sub0-mail-a52.g.dreamhost.com (localhost [127.0.0.1]) by pdx1-sub0-mail-a52.g.dreamhost.com (Postfix) with ESMTP id 7E57A7FF07; Tue, 6 Nov 2018 14:44:01 -0800 (PST)
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=YL5pg1FYYHuAb1 n5hwJoVpzE92Q=; b=qum/XzKIA5QPoGpppKcHS/Mpc74lriwuWnPe+7BlcCb+6G zqR6FTzqY+Uh273e4DqjnxkNekXQonAZ5vwiTGQlLRY2j0o/SZp672Ez27AO0Wcx UFhb34pWy6zaBzwJFJFgugV2F/8QC5sgsBflPiDFKjhdMHYUOJsggZM6cQ/jQ=
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-a52.g.dreamhost.com (Postfix) with ESMTPSA id 49F8E7FEF1; Tue, 6 Nov 2018 14:43:56 -0800 (PST)
Date: Tue, 06 Nov 2018 16:43:54 -0600
X-DH-BACKEND: pdx1-sub0-mail-a52
From: Nico Williams <nico@cryptonector.com>
To: Benjamin Kaduk <kaduk@mit.edu>
Cc: tls@ietf.org
Message-ID: <20181106224353.GC9067@localhost>
References: <20181105130157.GF54966@kduck.kaduk.org>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <20181105130157.GF54966@kduck.kaduk.org>
User-Agent: Mutt/1.5.24 (2015-08-30)
X-VR-OUT-STATUS: OK
X-VR-OUT-SCORE: -100
X-VR-OUT-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgedtkedrjeekgddtvdcutefuodetggdotefrodftvfcurfhrohhfihhlvgemucggtfgfnhhsuhgsshgtrhhisggvpdfftffgtefojffquffvnecuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjughrpeffhffvuffkfhggtggujggfsehttdertddtredvnecuhfhrohhmpefpihgtohcuhghilhhlihgrmhhsuceonhhitghosegtrhihphhtohhnvggtthhorhdrtghomheqnecukfhppedvgedrvdekrddutdekrddukeefnecurfgrrhgrmhepmhhouggvpehsmhhtphdphhgvlhhopehlohgtrghlhhhoshhtpdhinhgvthepvdegrddvkedruddtkedrudekfedprhgvthhurhhnqdhprghthheppfhitghoucghihhllhhirghmshcuoehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmqedpmhgrihhlfhhrohhmpehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmpdhnrhgtphhtthhopehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmnecuvehluhhsthgvrhfuihiivgeptd
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/E2lgQ7nLPpA1nI1q-YaOm466zcs>
Subject: Re: [TLS] some thoughts on dnssec-chain-extension, pinning, and broader semantics
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: Tue, 06 Nov 2018 22:44:08 -0000

We've had a couple of conference calls to discuss the I-D.

One call ended up causing the consensus on the I-D to collapse.

The second call ended too soon, but it was not unproductive.  Indeed, I
think at that call and in the subsequent off-list threads we identified
the concerns with pinning:

 - footgun concerns
 - hostile abuse concerns

Now, I believe we have demonstrated that there is no footgun: whenever
you can set the pin, you can also clear the pin.  At worst one might
first upgrade a server to gain support for the extension, set a pin,
then downgrade for some reason and thus footgun -- but the fix is to
upgrade again, or not set the pin immediately upon upgrade.  We also
have a mitigation for upgrade-set-pin-downgrade case (exponential
scaling of the pin timer with age of the RFC).

The second concern is, IMO, a non-concern, but granting for argument's
sake that it might be anyways, our answer to it is that sufficiently far
into the future the victim's server will support the extension, thus it
will be able to clear a hostile pin, therefore the exponential pin timer
scaling idea will give servers time to gain support for the extension
before anyone could ever make hostile use of the pin.

I believe we have put away those two concerns.  If we have not, please
say so and explain such that we might (or that we might see the errors
of our ways).

Are there any other reasons not to accept the proposed pinning scheme?

If no one can state any such reasons, why shouldn't we just accept the
proposal?

Nico
--