On Fri, Aug 31, 2018 at 4:15 PM Jacob Hoffman-Andrews <[email protected]> wrote:
> 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? > The correct answer here is Unauthorized. The resource exists, and it's the job of the authentication / authorization system to prevent unauthorized parties from accessing it. I disagree with your assessment that this puts us back at draft-14. It just moves us to the edge of the demarc: The guidance from the HTTP folks says we're not allowed to specify URL plans for server operators, in order to give them deployment flexibility. The flip-side of that is that it is up to operators to use a safe URL plan. So we're doing our part in the protocol; operators need to do their part. I can add some guidance to the security considerations. --Richard On Fri, Aug 31, 2018 at 4:15 PM Jacob Hoffman-Andrews <[email protected]> wrote: > 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 [email protected] https://www.ietf.org/mailman/listinfo/acme
