Re: [Acme] ACME breaking change: Most GETs become POSTs
Richard Barnes <rlb@ipv.sx> Thu, 06 September 2018 15:02 UTC
Return-Path: <rlb@ipv.sx>
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 98DBA130F01 for <acme@ietfa.amsl.com>; Thu, 6 Sep 2018 08:02:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.908
X-Spam-Level:
X-Spam-Status: No, score=-1.908 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ipv-sx.20150623.gappssmtp.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 1jTdYOO3X0CV for <acme@ietfa.amsl.com>; Thu, 6 Sep 2018 08:02:25 -0700 (PDT)
Received: from mail-oi0-x241.google.com (mail-oi0-x241.google.com [IPv6:2607:f8b0:4003:c06::241]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3E682130EA3 for <acme@ietf.org>; Thu, 6 Sep 2018 08:02:25 -0700 (PDT)
Received: by mail-oi0-x241.google.com with SMTP id p84-v6so21121709oic.4 for <acme@ietf.org>; Thu, 06 Sep 2018 08:02:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=uNu+bCyEcmR4I5mI+oyvAMTQ4fnRtf8o6Soz3vzbStA=; b=tGuGJja+DYfAfGMy1+xWSMjTWRF26hOQJ7D87EYYJuaZNLJdAAMWNYlN5sA2e58Z50 KFqu++C5s3EZnBRmZz9AhQSfWbJZbNnKIMefD9m5wj/GyvlrVZTVe/82lVs9BJosEiDc xkWAmi6V45rOtdL8njRSR/OIWvNAvNhz1pskUE0+SYGOdng1Yzuq58++qTFhuDypjryi ylwrDypcA42sc0bTWS5lQNydjHd5lo3V5BYHZMAOG41Y19fSTTHApO4Y/hf/LlX6k32G SRj8xWtiU58ra1AuAHF5ASSoeIc3YdvQYmTpRH2fJW8wyemEKO6eP/RiQ72SpHcdJvz5 Oz0A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=uNu+bCyEcmR4I5mI+oyvAMTQ4fnRtf8o6Soz3vzbStA=; b=YY0S5tFJUXLHHrrVlFaG4kS5PrTudT/Eyg3lLIojPiPsBuNGwfwGBSRrLN3WglQMEn 48sZq86KFgYWqLloVMpZw0INANCEqhBgyvk/lz1cIqu5ocrJaTVefW3mjyeW/AIJ27tr g7VrfxxNmR5ioO4NhypwKz6idPCeW0TR34jaHAvTT39bYnvHsU9l0oRgEqhW2wbsCoSd o/6qbWRuXB2Q4xsFb+za48abc1c2hsNVHRm936bJ55WIlBqP/uBwYiCaRRphA5S9QMk5 eHFbGh3LAJtuvsQeZq7/70kuEDWxz+mu3oI/KA3HkGLlAvTI1+ilKDX8Iv8/4OsJsU3a nCiA==
X-Gm-Message-State: APzg51C89+jOd72QbQ2FyCIpmqrH0wa0/97H1K9OxQMMCgRPYgVw51ut 6MSnSNe/EGYea4LWLGjpPFbSsgRJiqcn/fgcCo/ee9+SfoE=
X-Google-Smtp-Source: ANB0Vdaw93rqhG0XoVFOM6Fqr1Gx0DjeCEBhU/bzxxKiMnqE/zdNMmB/2Yppb4cLkh/FcrY8zO423FYHSxh8DpnwCcE=
X-Received: by 2002:aca:e214:: with SMTP id z20-v6mr3459956oig.95.1536246139588; Thu, 06 Sep 2018 08:02:19 -0700 (PDT)
MIME-Version: 1.0
References: <c33184f3-4e64-b7ea-babb-d29e2307f1f3@eff.org> <CAL02cgQ1BAzYH4f1nUD3fO0dKTc4mVrJ_NnoKq+Zb0BjT9J35Q@mail.gmail.com>
In-Reply-To: <CAL02cgQ1BAzYH4f1nUD3fO0dKTc4mVrJ_NnoKq+Zb0BjT9J35Q@mail.gmail.com>
From: Richard Barnes <rlb@ipv.sx>
Date: Thu, 06 Sep 2018 11:02:07 -0400
Message-ID: <CAL02cgTDMqQ0jPojqUBAVBW=TRFGU0_ntfcLGUsTbPtvfitDKQ@mail.gmail.com>
To: IETF ACME <acme@ietf.org>
Cc: "<acme-chairs@ietf.org>" <acme-chairs@ietf.org>, Eric Rescorla <ekr@rtfm.com>, Adam Roach <adam@nostrum.com>
Content-Type: multipart/alternative; boundary="0000000000007022a70575352d7a"
Archived-At: <https://mailarchive.ietf.org/arch/msg/acme/uU-j2dHAUdJ9QBXMYCSdZbV1-KY>
Subject: Re: [Acme] ACME breaking change: Most GETs become POSTs
X-BeenThere: acme@ietf.org
X-Mailman-Version: 2.1.29
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, 06 Sep 2018 15:02:32 -0000
After the weekend's discussions, I've updated the PR to reflect what I understand to be emerging agreement on these topics: ISSUE 1. Should we do POST-as-GET at all, vs. keeping GET and doing the privacy analysis? PROPOSED RESOLUTION: Yes. ISSUE 2: How should we signal that POST-as-GET request is different from other POST requests? PROPOSED RESOLUTION: A JWS with a zero-octet payload ("") ISSUE 3: Should servers be required to allow GET requests for certificate URLs? PROPOSED RESOLUTION: No, but they MAY ISSUE 4: How should we address the risk that an attacker can discover URLs by probing for Unauthorized vs. Not Found? PROPOSED RESOLUTION: Security considerations that recommend non-correlatable URL plans https://github.com/ietf-wg-acme/acme/pull/445 Adam: Is this looking like an approach that would satisfy your DISCUSS? Chairs / EKR: How would you like to proceed on closing this out? What are the next process steps? On Fri, Aug 31, 2018 at 6:08 PM Richard Barnes <rlb@ipv.sx> wrote: > Hey all, > > This thread forked into a couple of different issues, so I wanted to post > a little end-of-day summary of the issues and where we stand. I've updated > the PR [1] to reflect most of today's discussion. > > === > > ISSUE 1. Should we do POST-as-GET at all, vs. keeping GET and doing the > privacy analysis? > > It seems like there's pretty strong agreement that we should get rid of > GET, as the architecturally cleanest option. > > === > > ISSUE 2: How should we signal that POST-as-GET request is different from > other POST requests? > > The current PR signals this by sending a JWS with an empty (zero-octet) > payload, instead of a JSON object. Jacob and Daniel suggested that we > should instead use the payload being an empty JSON object as the signal. > An earlier draft PR used a field in the protected header. > > === > > ISSUE 3: Should servers be required to allow GET requests for certificate > URLs? > > I had proposed this earlier today; Jacob and Daniel pushed back. I have > implemented a compromise in the latest PR, where servers MAY accept GET > requests. > > === > > ISSUE 4: How should we address the risk that an attacker can discover URLs > by probing for Unauthorized vs. Not Found? > > There seemed to be agreement on the list that this should be addressed > with some guidance to servers on how to assign URLs. I have just added > some text to the PR for this. > > === > > It seems to me we're pretty much closed on the first issue, and the other > three are still open. Please send comments, so we can resolve this issue > and get the document back in motion! > > Thanks, > --Richard > > [1] https://github.com/ietf-wg-acme/acme/pull/445 > > On Thu, Aug 30, 2018 at 7:20 PM Jacob Hoffman-Andrews <jsha@eff.org> > wrote: > >> 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 >> >> _______________________________________________ >> Acme mailing list >> Acme@ietf.org >> https://www.ietf.org/mailman/listinfo/acme >> >
- [Acme] ACME breaking change: Most GETs become POS… Jacob Hoffman-Andrews
- Re: [Acme] ACME breaking change: Most GETs become… Jacob Hoffman-Andrews
- Re: [Acme] ACME breaking change: Most GETs become… Adam Roach
- Re: [Acme] ACME breaking change: Most GETs become… Felipe Gasper
- Re: [Acme] ACME breaking change: Most GETs become… Richard Barnes
- Re: [Acme] ACME breaking change: Most GETs become… Salz, Rich
- Re: [Acme] ACME breaking change: Most GETs become… Felipe Gasper
- Re: [Acme] ACME breaking change: Most GETs become… Richard Barnes
- Re: [Acme] ACME breaking change: Most GETs become… Richard Barnes
- Re: [Acme] ACME breaking change: Most GETs become… Salz, Rich
- Re: [Acme] ACME breaking change: Most GETs become… Nico Williams
- Re: [Acme] ACME breaking change: Most GETs become… Tim Hollebeek
- Re: [Acme] ACME breaking change: Most GETs become… Richard Barnes
- Re: [Acme] ACME breaking change: Most GETs become… Salz, Rich
- Re: [Acme] ACME breaking change: Most GETs become… Richard Barnes
- Re: [Acme] ACME breaking change: Most GETs become… Daniel McCarney
- Re: [Acme] ACME breaking change: Most GETs become… Jacob Hoffman-Andrews
- Re: [Acme] ACME breaking change: Most GETs become… Daniel McCarney
- Re: [Acme] ACME breaking change: Most GETs become… Daniel McCarney
- Re: [Acme] ACME breaking change: Most GETs become… Nico Williams
- Re: [Acme] ACME breaking change: Most GETs become… Daniel McCarney
- Re: [Acme] ACME breaking change: Most GETs become… Nico Williams
- Re: [Acme] ACME breaking change: Most GETs become… Richard Barnes
- Re: [Acme] ACME breaking change: Most GETs become… Jacob Hoffman-Andrews
- Re: [Acme] ACME breaking change: Most GETs become… Richard Barnes
- Re: [Acme] ACME breaking change: Most GETs become… Adam Roach
- Re: [Acme] ACME breaking change: Most GETs become… Eric Rescorla
- Re: [Acme] ACME breaking change: Most GETs become… Jacob Hoffman-Andrews
- Re: [Acme] ACME breaking change: Most GETs become… Adam Roach
- Re: [Acme] ACME breaking change: Most GETs become… Nico Williams
- Re: [Acme] ACME breaking change: Most GETs become… Richard Barnes
- Re: [Acme] ACME breaking change: Most GETs become… Richard Barnes
- Re: [Acme] ACME breaking change: Most GETs become… Richard Barnes
- Re: [Acme] ACME breaking change: Most GETs become… Felix Fontein
- Re: [Acme] ACME breaking change: Most GETs become… Yaron Sheffer
- Re: [Acme] ACME breaking change: Most GETs become… Jacob Hoffman-Andrews
- Re: [Acme] ACME breaking change: Most GETs become… Richard Barnes
- Re: [Acme] ACME breaking change: Most GETs become… Adam Roach
- Re: [Acme] ACME breaking change: Most GETs become… Salz, Rich
- Re: [Acme] ACME breaking change: Most GETs become… Eric Rescorla
- Re: [Acme] ACME breaking change: Most GETs become… Erica Portnoy
- Re: [Acme] ACME breaking change: Most GETs become… Alan Doherty
- Re: [Acme] ACME breaking change: Most GETs become… Erica Portnoy
- Re: [Acme] ACME breaking change: Most GETs become… Adam Roach
- Re: [Acme] ACME breaking change: Most GETs become… Alan Doherty