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?
_______________________________________________ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
