[Acme] Invalidation of authz after an account compromise

Jacob Hoffman-Andrews <jsha@eff.org> Mon, 30 January 2017 21:03 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 278FB12960F for <acme@ietfa.amsl.com>; Mon, 30 Jan 2017 13:03:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.2
X-Spam-Level:
X-Spam-Status: No, score=-10.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_HI=-5, RP_MATCHES_RCVD=-3.199, 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 d858TSN_G0Or for <acme@ietfa.amsl.com>; Mon, 30 Jan 2017 13:03:30 -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 0D1551295FE for <acme@ietf.org>; Mon, 30 Jan 2017 13:03:30 -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=dj+2JgTuvdP11W4XpXT951PvDSMbV6+5xD5Vii0A9RE=; b=0Q2dEXS0S24tShkvaLUpqz1vLRbrnKQ45Jz16fP/0ehv5PDa0l4y6iihwvKJ8V/M7snCVBrQQQ25BPhAEKthAhCVHMB4h9/bQoca4D92BNu9dyKDyn8BWqvlJbH1XyfGiZ/uWj+2F8hGmr6iAAdEAMjCEmCJMg57wLutSmchtN0=;
Received: ; Mon, 30 Jan 2017 13:03:30 -0800
To: "acme@ietf.org" <acme@ietf.org>
From: Jacob Hoffman-Andrews <jsha@eff.org>
Message-ID: <0964d671-972a-1101-93ed-d9f64ece8e2a@eff.org>
Date: Mon, 30 Jan 2017 13:03:28 -0800
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/acme/ye_F6gX-CVl1WQlGcncul04NQEM>
Subject: [Acme] Invalidation of authz after an account compromise
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, 30 Jan 2017 21:03:32 -0000

We've discussed in the past how a domain owner should recover from a
host compromise. I believe we came to a rough consensus that solving a
DV challenge should be sufficient authorization to invalidate extant
authorization on other accounts, and that we can consider each newly
validated authz to invalidate previous authzs for the same identifier.
I've written this up as a PR:

https://github.com/ietf-wg-acme/acme/pull/240

diff --git a/draft-ietf-acme-acme.md b/draft-ietf-acme-acme.md
index d2b1ca1..9ab10f2 100644
--- a/draft-ietf-acme-acme.md
+++ b/draft-ietf-acme-acme.md
@@ -1643,6 +1643,9 @@ for the identifier.  If the final state is
"valid", the server MUST add an
 "expires" field to the authorization.  When finalizing an authorization,
 the server MAY remove challenges other than the one that was completed. The
 server SHOULD NOT remove challenges with status "invalid".
+If the final state is "valid", the server SHOULD invalidate any other
+currently-valid authorizations for the same identifier. See
+{{security-considerations}} for reasoning.
 
 Usually, the validation process will take some time, so the client will
need to
 poll the authorization resource to see when it is finalized.  For
challenges
@@ -2688,6 +2691,23 @@ within their trusted network and use these
resolvers both for both CAA record
 lookups and all record lookups in furtherance of a challenge scheme (A,
AAAA,
 TXT, etc.).
 
+## Recovery From Host Compromise
+
+If a host is compromised, once the owner regains exclusive control of
the host,
+they will want to take steps to revoke any certificates the attacker
may have
+issued, and to ensure that the attacker cannot issue new certificates
for the
+affected hostnames.
+
+If the attacker gained access to the private key for an ACME account,
but has
+not yet changed the ACME account keypair, the proper owner can use the key
+rotation functionality to regain exclusive control of their ACME account.
+
+If the attacker did change the ACME account keypair, or if the attacker
created
+their own ACME account and authorized the hostname, the proper owner, after
+regaining control of the host, can authorize that hostname on their own
account
+(which should invalidate previous authorizations for that hostname),
and can use
+that authorization to revoke any certificates the attacker may have issued.
+
 # Acknowledgements
 
 In addition to the editors listed on the front page, this document has
benefited