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

[Adam Roach <[e-mail]>]

On 8/30/18 6:20 PM, Jacob Hoffman-Andrews 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.


To be clear -- and I'm just repeating an observation that Richard made 
-- servers can continue to accept GET for the resources in question 
(order lists, orders, and certificates) for the foreseeable future, 
while also accepting POST for them [1]. Doing so would allow clients to 
switch from using GET to using POST for these resources at a leisurely 
pace, and then servers could turn off GET functionality (i.e., start 
returning 405's) once usage drops to an acceptable level.


> 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. 


I think this is the right call also, regardless of how breaking a change 
it might be. What I'd really like to avoid is a perpetual tax on 
developing ACME extensions in the form of having to perform extensive 
privacy analysis on every new endpoint, every new field, and every new 
identifier type that can be retrieved without authentication; and, as 
far as I can tell, that's the only other option here.

For avoidance of doubt, I'm speaking as an individual in the preceding 
paragraph. As an AD with a DISCUSS on this document, I want to make it 
clear that any solution to the privacy issue will satisfy my DISCUSS. 
But as an individual, I would be sad if the decision taken was one that 
hamstrings future protocol development.

/a

____
[1] This would presumably be coupled with an implementation-specific 
analysis of whether GET-able information can be correlated, and making 
adjustments if so.