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

[Jacob Hoffman-Andrews <[e-mail]>]

On 08/31/2018 12:30 PM, Jacob Hoffman-Andrews wrote:
> /account/100/certificate/3438
> /account/201/certificate/3439
> /account/100/certificate/3440*

Here's an issue that came up during code review: When you POST-as-GET to 
a resource you don't own, should you get Not Found or Unauthorized? The 
quick answer is Not Found. If we return Unauthorized, that still allows 
potentially enumerating the existence of certificates URLs, which 
depending on URL schemes might reveal the grouping of certificates by 
account id.

However, if we choose Not Found, that implies we're trying to hide the 
existence of certain resources, which means checking for those resources 
has to be timing-safe, a very high bar. We wind up hiding one foot-gun 
(URL enumeration) under another foot-gun (timing attacks).

Alternately, we could consider URL enumeration out of scope, and say 
"POST-as-GET is only intended to protect the contents of resources, not 
their existence or relationship to each other."

That winds up leaving us pretty close to being back at draft-14: Since 
POST-as-GET protects resource bodies, and the currently-specified 
resources are already broken down into sensitive (account) and not 
(orders, authorizations, challenges, certificates), we could just as 
well leave the non-sensitive resources as regular GETs. We might make a 
change to define POST-as-GET as a broader mechanism, to be used by 
default by future extensions that define new resource types.

Alternately, we might say that even though orders, authorizations, 
challenges, and certificates are all non-sensitive, we should require 
POST-as-GET across the board for all ACME requests, because it will 
simplify security analysis.

What do you all think? Should enumeration of the existence of URLs be 
considered in-scope?