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 < [email protected]> 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 <[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]> > 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] > 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 > >
_______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
