Re: [Acme] Signature misuse vulnerability in draft-barnes-acme-04

Jacob Hoffman-Andrews <jsha@eff.org> Wed, 12 August 2015 05:50 UTC

Return-Path: <jsha@eff.org>
X-Original-To: acme@ietfa.amsl.com
Delivered-To: acme@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 267531B2B77 for <acme@ietfa.amsl.com>; Tue, 11 Aug 2015 22:50:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.012
X-Spam-Level:
X-Spam-Status: No, score=-7.012 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, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 3LCEuNsQ-jCx for <acme@ietfa.amsl.com>; Tue, 11 Aug 2015 22:50:28 -0700 (PDT)
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 CF5DE1B2B76 for <acme@ietf.org>; Tue, 11 Aug 2015 22:50:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=eff.org; s=mail2; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:To:MIME-Version:From:Date:Message-ID; bh=v+mwzbMrr/V+Tbd3R1B0/XnlRl1/LTWB3gXzCurQY0s=; b=YsyCo5b5iootPwnhFCrqQZNc8rZyHQJPWlWhLRQEvbeqfZB0Amcw+tqXbuI6EsO2dwPw7uwxa9Ebd8Od9QMrkcQOOe6BSAS+7aEspuCQutf5AmFtiTJZ06k/cqC60rfxKh4eGDeLNeX9c/+VQ6CbeTkO8+WNTq+B+/Bma0T+UTI=;
Received: ; Tue, 11 Aug 2015 22:50:28 -0700
Message-ID: <55CADEA3.3030902@eff.org>
Date: Tue, 11 Aug 2015 22:50:27 -0700
From: Jacob Hoffman-Andrews <jsha@eff.org>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.8.0
MIME-Version: 1.0
To: Andrew Ayer <agwa@andrewayer.name>, acme@ietf.org
References: <20150811085205.bbcd37b3b0bb0482f6522b1a@andrewayer.name>
In-Reply-To: <20150811085205.bbcd37b3b0bb0482f6522b1a@andrewayer.name>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
Archived-At: <http://mailarchive.ietf.org/arch/msg/acme/GNXmfsDiOehB6GrQeBBOjnGLU-Y>
Subject: Re: [Acme] Signature misuse vulnerability in draft-barnes-acme-04
X-BeenThere: acme@ietf.org
X-Mailman-Version: 2.1.15
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: Wed, 12 Aug 2015 05:50:31 -0000

This is an excellent find, thanks for spotting it and writing it up.

On 08/11/2015 08:52 AM, Andrew Ayer wrote:
> To fix this, I propose simply publishing the authorized account public key (or a hash of it) in the
> TXT record (for DNS challenges), in the TLS certificate (for DVSNI), or in the file (for Simple HTTP).
This seems like a good approach, though I think it's not compatible with
the new domain validation requirements being worked on at the CA/B
Forum: https://cabforum.org/pipermail/validation/2015-July/000080.html,
which require a random token. We could propose an addition to those
requirements, once we have concrete spec language in place.

The nice thing about publishing account keys is that they can remain
constant over time, which would in theory allow for significant changes
to the protocol. For instance, DVSNI, SimpleHTTP, and DNS challenges
could be specified as re-validateable on demand, and in practice a CA
could revalidate the relevant challenges immediately before issuance,
not just at authorization time.

That, in turn, would resolve some thorny problems people have raised
(https://github.com/letsencrypt/boulder/issues/572) about transferring
authorizations between account keys, and removing authorizations from
account keys. For instance, if we specify that
/.well-known/certificate/acme-account-keys.json on any given host should
contain a list of JWKs authorized to issue certificates, then
authorizing a new hosting provider to issue certificates would be as
simple as adding their account key to that file. The hosting provider
could even check for themselves that it's present before beginning an
interaction with the ACME server. Similarly, someone who leaves a
hosting provider would be able to remove that provider's key from the
relevant file to deauthorize them from issuing future certificates.

A similar system could apply with key hashes for DVSNI and DNS.