Re: [Acme] ACME breaking change: Most GETs become POSTs

This is a pretty substantive change and I think this does need to have a
short IETF-LC. Why don't you produce a new draft and let me know when you
believe the WG has consensus
-Ekr


On Thu, Sep 6, 2018 at 8:50 AM, Salz, Rich <
rsalz=40akamai.com@dmarc.ietf.org> wrote:

> We have already had some discussion on this.  I do not want to reset the
> WGLC.  Please take a look at the PR, it addresses issue that were brought
> up during IESG review.
>
>
>
> If you have objections or concerns, please reply by the end of next week,
> 14 sep.
>
>
>
> *From: *Richard Barnes <rlb@ipv.sx>
> *Date: *Thursday, September 6, 2018 at 11:02 AM
> *To: *"acme@ietf.org" <acme@ietf.org>
> *Cc: *"<acme-chairs@ietf. org>" <acme-chairs@ietf.org>, Eric Rescorla <
> ekr@rtfm.com>, Adam Roach <adam@nostrum.com>
> *Subject: *Re: [Acme] ACME breaking change: Most GETs become POSTs
> *Resent-From: *<alias-bounces@ietf.org>
> *Resent-To: *Rich Salz <rsalz@akamai.com>, Yoav Nir <ynir.ietf@gmail.com>
> *Resent-Date: *Thursday, September 6, 2018 at 11:02 AM
>
>
>
> 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
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_ietf-2Dwg-2Dacme_acme_pull_445&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=4LM0GbR0h9Fvx86FtsKI-w&m=0WrTFNH1Dw6ptcTgU6p4wrd1zn3ZVatHDOrx8DbEWUM&s=ARyNYl3lxrI8cMqtfkMceBinUqRQmbZiPk8NXJWj3O0&e=>
>
>
>
> 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
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_ietf-2Dwg-2Dacme_acme_pull_445&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=4LM0GbR0h9Fvx86FtsKI-w&m=0WrTFNH1Dw6ptcTgU6p4wrd1zn3ZVatHDOrx8DbEWUM&s=ARyNYl3lxrI8cMqtfkMceBinUqRQmbZiPk8NXJWj3O0&e=>
>
>
>
> 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
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_letsencrypt_acme-2Dspec_pull_48-23issuecomment-2D70169712&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=4LM0GbR0h9Fvx86FtsKI-w&m=0WrTFNH1Dw6ptcTgU6p4wrd1zn3ZVatHDOrx8DbEWUM&s=-4g1lhzE_4QDBMJ-WyE17zBBm61tdp2A-ImhSpqHet4&e=>
> [2] https://github.com/ietf-wg-acme/acme/pull/445/files
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_ietf-2Dwg-2Dacme_acme_pull_445_files&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=4LM0GbR0h9Fvx86FtsKI-w&m=0WrTFNH1Dw6ptcTgU6p4wrd1zn3ZVatHDOrx8DbEWUM&s=LoHY-1DpWoqgeBKRrhoq2l8n4_M01eB2qOjY9yUEaRA&e=>
>
> _______________________________________________
> Acme mailing list
> Acme@ietf.org
> https://www.ietf.org/mailman/listinfo/acme
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_acme&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=4LM0GbR0h9Fvx86FtsKI-w&m=0WrTFNH1Dw6ptcTgU6p4wrd1zn3ZVatHDOrx8DbEWUM&s=-4LvMdxd6Cmfi4d1ClEC2VFM8ndqUtWVEkoSNvTrg2M&e=>
>
>
> _______________________________________________
> Acme mailing list
> Acme@ietf.org
> https://www.ietf.org/mailman/listinfo/acme
>
>