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 <[email protected]> Date: Thursday, September 6, 2018 at 11:02 AM To: "[email protected]" <[email protected]> Cc: "<acme-chairs@ietf. org>" <[email protected]>, Eric Rescorla <[email protected]>, Adam Roach <[email protected]> Subject: Re: [Acme] ACME breaking change: Most GETs become POSTs Resent-From: <[email protected]> Resent-To: Rich Salz <[email protected]>, Yoav Nir <[email protected]> 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 <[email protected]> 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 <[email protected]<mailto:[email protected]>> 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 [email protected]<mailto:[email protected]> 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 [email protected] https://www.ietf.org/mailman/listinfo/acme
