IETF Logo Mail Archive

[Acme] HPKP in ACME

Jacob Hoffman-Andrews <jsha@eff.org> Mon, 13 February 2017 19:33 UTC

Return-Path: <jsha@eff.org>
X-Original-To: acme@ietfa.amsl.com
Delivered-To: acme@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74E8512986D for <acme@ietfa.amsl.com>; Mon, 13 Feb 2017 11:33:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.002
X-Spam-Level:
X-Spam-Status: No, score=-7.002 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_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-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=eff.org
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 FHILZqleVswY for <acme@ietfa.amsl.com>; Mon, 13 Feb 2017 11:33:46 -0800 (PST)
Received: from mail2.eff.org (mail2.eff.org [173.239.79.204]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7DD4B129871 for <acme@ietf.org>; Mon, 13 Feb 2017 11:33:46 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=eff.org; s=mail2; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Date:Message-ID:Subject:From:To; bh=2OhB4ErceRLOFzN2aPvCdrujIaP9L9rRIvG2qst95kI=; b=UnFaOYQdmEhpC3Il3lfXHlu3gjz3q2yPWrkEO4hh0t11sqLwFYuLvqw0AhaZnh3r6z6HhuO2tpK7MSfGiay4LOgvaBRC23nr/hkEApHwvvzV+HxEptf2O67FT/DiTaCVfNJ7Aa4ogP/4fCqhaaELK/Hl5rVlQUKMRqdkhBFvmO4=;
Received: ; Mon, 13 Feb 2017 11:33:48 -0800
To: "acme@ietf.org" <acme@ietf.org>, Martin Thomson <martin.thomson@gmail.com>
From: Jacob Hoffman-Andrews <jsha@eff.org>
Message-ID: <81377754-e24d-269d-0f48-ba37e55f8942@eff.org>
Date: Mon, 13 Feb 2017 11:33:46 -0800
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Received-SPF: skipped for local relay
Archived-At: <https://mailarchive.ietf.org/arch/msg/acme/4-rov-zhMko_7P6DaTvnyWj-WFw>
Subject: [Acme] HPKP in ACME
X-BeenThere: acme@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Automated Certificate Management Environment <acme.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/acme>, <mailto:acme-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/acme/>
List-Post: <mailto:acme@ietf.org>
List-Help: <mailto:acme-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/acme>, <mailto:acme-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 13 Feb 2017 19:33:49 -0000

Martin brought up a section I've been considering removing:

> Clients SHOULD support HTTP public key pinning [RFC7469], and servers
SHOULD emit pinning headers.

Here's my reasoning:

- Public key pinning isn't implemented in most HTTPS libraries outside
of browsers, so this is a considerable burden on implementers.
- Public key pinning carries a fairly high risk of footgunning. The
consequence of a failed pin for a CA that serves many ACME clients would
be that some of those clients would fail to renew their certs, causing
cascading breakage.
- There is relatively little confidential information conveyed in ACME,
and there are other defenses built into ACME (like including the account
key as part of the challenge data), so HPKP is not strongly necessary.

Any objections?

PR to remove: https://github.com/ietf-wg-acme/acme/pull/244

v2.23.0 | Report a Bug | By Email