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 <[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
>
> 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
>> [2] https://github.com/ietf-wg-acme/acme/pull/445/files
>>
>> _______________________________________________
>> Acme mailing list
>> [email protected]
>> https://www.ietf.org/mailman/listinfo/acme
>>
>
_______________________________________________
Acme mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/acme
