[Acme] ACME breaking change: Most GETs become POSTs

Jacob Hoffman-Andrews <jsha@eff.org> Thu, 30 August 2018 23:20 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 C590A130DEF for <acme@ietfa.amsl.com>; Thu, 30 Aug 2018 16:20:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.01
X-Spam-Level:
X-Spam-Status: No, score=-7.01 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_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, 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 wV_Z0kn8_4ZV for <acme@ietfa.amsl.com>; Thu, 30 Aug 2018 16:20:42 -0700 (PDT)
Received: from mail2.eff.org (mail2.eff.org [173.239.79.204]) (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 5C3AB12F1AB for <acme@ietf.org>; Thu, 30 Aug 2018 16:20:42 -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:MIME-Version:Date: Message-ID:Subject:From:To:Sender:Reply-To:Cc:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: In-Reply-To:References:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=yrBm8RAgqpMD40VmNLd3vUmkzbKCwxYOVIsCJHsQVp4=; b=Hh/2ocWQV1yTGPS8+t5bQ4l381 azRfYOhORqI4CUHYeQTxTWsKqy9d198Ccxp9fcRjn0VNgHXy4u4o8hI9DvPOoVe7/oZK1ckc5XVSE 9RDwvgc+MAzn1CqyoM2WROIGuH1aYqDPXvUXNZ3gIHwbcJIwWqZ2/gEk9wSnsa+chUyA=;
Received: ; Thu, 30 Aug 2018 16:20:42 -0700
To: ACME WG <acme@ietf.org>
From: Jacob Hoffman-Andrews <jsha@eff.org>
Message-ID: <c33184f3-4e64-b7ea-babb-d29e2307f1f3@eff.org>
Date: Thu, 30 Aug 2018 16:20:41 -0700
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/acme/sotffSQ0OWV-qQJodLwWYWcEVKI>
Subject: [Acme] ACME breaking change: Most GETs become POSTs
X-BeenThere: acme@ietf.org
X-Mailman-Version: 2.1.27
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: Thu, 30 Aug 2018 23:20:44 -0000

ACME currently has unauthenticated GETs for some resources. This was 
originally discussed in January 2015[1]. We decided to put all sensitive 
data in the account resource and consider all GET resources public, with 
a slant towards transparency.

Adam Roach recently pointed out in his Area Director review that even 
when the contents of GET URLs aren’t sensitive, their correlation may 
be. For instance, some CAs might consider the grouping of certificates 
by account to be sensitive.

Richard Barnes proposes[2] to change all GETs to POSTs (except directory 
and new-nonce). This will be a breaking change. Clients that were 
compatible with previous drafts, informally called ACMEv1 and ACMEv2, 
will not be compatible with a draft that mandates POSTs everywhere. It 
will be a painful change, since the ecosystem just started switching to 
ACMEv2, which looked to be near-final.

I think this is the right path forwards. ACME will be a simpler, better 
protocol long-term if all requests are authenticated. However, if we’re 
taking this path we should aim to come to consensus and land the final 
spec quickly to reduce uncertainty for ACME client implementers.

[1] https://github.com/letsencrypt/acme-spec/pull/48#issuecomment-70169712
[2] https://github.com/ietf-wg-acme/acme/pull/445/files