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

[Richard Barnes <[e-mail]>]

On Fri, Aug 31, 2018 at 4:15 PM Jacob Hoffman-Andrews <[e-mail]> 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 <[e-mail]> 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?
>