At 00:48 08/09/2018 Saturday, Erica Portnoy wrote: >Hello all, > >Just read through the discussion, hope I've misunderstood something here! Here >goes:
I think you must have as all this discussion relates to traffic from acme-client to acme-server thus both https and obviously 1 known api/name you seem to be discussing traffic to an acme-customer's webserver >Domains that could be correlated in this way can probably already be >correlated. > >If someone's in a position to watch traffic going *from* a server trying to >authenticate, they can certainly watch traffic going *to* that server, and >note the various domain names being hosted on that server (since no encrypted >sni :( ). And they could almost certainly get that same information from a >reverse DNS, as well. > >You can't use precisely that method for phone numbers and contact email >addresses, to be sure. > >But we might be overestimating the amount of privacy protection we're giving >here; we don't want to be in a position of trying to protect something that's >public information. > >Best, >Erica > > >On 09/06/2018 09:03 AM, Eric Rescorla wrote: >>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 >><<mailto:[email protected]>[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 <mailto:[email protected]><[email protected]> >>Date: Thursday, September 6, 2018 at 11:02 AM >>To: "<mailto:[email protected]>[email protected]" >><<mailto:[email protected]>[email protected]> >>Cc: "<mailto:[email protected]><acme-chairs@ietf. org>" >><<mailto:[email protected]>[email protected]>, Eric Rescorla >><<mailto:[email protected]>[email protected]>, Adam Roach >><<mailto:[email protected]>[email protected]> >>Subject: Re: [Acme] ACME breaking change: Most GETs become POSTs >>Resent-From: <<mailto:[email protected]>[email protected]> >>Resent-To: Rich Salz <<mailto:[email protected]>[email protected]>, Yoav Nir >><<mailto:[email protected]>[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://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=>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 >><mailto:[email protected]><[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://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=>https://github.com/ietf-wg-acme/acme/pull/445 >> >> >> >>On Thu, Aug 30, 2018 at 7:20 PM Jacob Hoffman-Andrews >><<mailto:[email protected]>[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://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=>https://github.com/letsencrypt/acme-spec/pull/48#issuecomment-70169712 >>[2] https://github.com/ietf-wg-acme/acme/pull/445/files >> >>_______________________________________________ >>Acme mailing list >><mailto:[email protected]>[email protected] >>https://www.ietf.org/mailman/listinfo/acme >> >> >>_______________________________________________ >>Acme mailing list >><mailto:[email protected]>[email protected] >>https://www.ietf.org/mailman/listinfo/acme >> >> >> >> >> >>_______________________________________________ >>Acme mailing list >><mailto:[email protected]>[email protected] >>https://www.ietf.org/mailman/listinfo/acme > >_______________________________________________ >Acme mailing list >[email protected] >https://www.ietf.org/mailman/listinfo/acme _______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
