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

From: Jacob Hoffman-Andrews <[email-masked]>
Date: Thu, 30 Aug 2018 16:20:41 -0700

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.

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.

[1] https://github.com/letsencrypt/acme-spec/pull/48#issuecomment-70169712
[2] https://github.com/ietf-wg-acme/acme/pull/445/files

---

From: Jacob Hoffman-Andrews <[email-masked]>
Date: Thu, 30 Aug 2018 16:48:41 -0700

(Replying to Felipe's comment from the thread "Re: [Acme] Adam Roach's 
Discuss on draft-ietf-acme-acme-14: (with DISCUSS and COMMENT)")

On 08/30/2018 11:17 AM, Felipe Gasper wrote:
 > Would it work to keep certificate fetches as plain GET?
 >
 > In shared hosting environments it’s common for a privileged process 
to request certificates on behalf of user accounts. This avoids having 
1,000s of ACME server registrations from a single server. While 
certificates are generally made available within seconds, theoretically 
the delay between request and issuance could be much longer (e.g., for 
OV/EV), such that it might be prudent for that privileged process to 
give the order ID to the user and have the user poll for the 
certificate, e.g., via cron.

This use case makes sense, but I think it is not critical enough to 
carve out an exception from the "GETs become POSTs" plan. If the ACME 
implementation structures certificate fetches such that they are 
enumerable, you would wind up again with the same sort of correlation 
problem Adam brought up. You could make the certificate URLs 
unpredictable, but then you've introduced a notion of capability 
URLs[1], which breaks the notion of having a single authentication 
system for ACME.

It seems just as possible for the unprivileged process to do the polling 
for the certificate, and once it's ready, make it available on the 
filesystem for the unprivileged user.

[1] https://www.w3.org/TR/capability-urls/

---

From: Adam Roach <[email-masked]>
Date: Thu, 30 Aug 2018 18:55:32 -0500

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

---

From: Felipe Gasper <[email-masked]>
Date: Thu, 30 Aug 2018 20:45:50 -0400

> On Aug 30, 2018, at 7:48 PM, Jacob Hoffman-Andrews <[email-masked]> wrote:
> 
> (Replying to Felipe's comment from the thread "Re: [Acme] Adam Roach's Discuss on draft-ietf-acme-acme-14: (with DISCUSS and COMMENT)")
> 
> > In shared hosting environments it’s common for a privileged process to request certificates on behalf of user accounts. This avoids having 1,000s of ACME server registrations from a single server. While certificates are generally made available within seconds, theoretically the delay between request and issuance could be much longer (e.g., for OV/EV), such that it might be prudent for that privileged process to give the order ID to the user and have the user poll for the certificate, e.g., via cron.
> 
> This use case makes sense, but I think it is not critical enough to carve out an exception from the "GETs become POSTs" plan. If the ACME implementation structures certificate fetches such that they are enumerable, you would wind up again with the same sort of correlation problem Adam brought up. You could make the certificate URLs unpredictable, but then you've introduced a notion of capability URLs[1], which breaks the notion of having a single authentication system for ACME.

I suppose if I have:

GET /order/123/certificate    =>   cert for yin.com

GET /order/124/certificate    =>   cert for yang.com

… then one could surmise (however justifiably) that these two may be related, so I see the point.

> You could make the certificate URLs unpredictable, but then you've introduced a notion of capability URLs[1], which breaks the notion of having a single authentication system for ACME.

I can see that.

Thanks for your consideration!

-FG

---

From: Richard Barnes <[email-masked]>
Date: Fri, 31 Aug 2018 10:16:41 -0400

TBH, I'm not averse to allowing GETs for certificate resources.  It seems
analogous to allowing them for the directory resource, just on the opposite
side of the process.  That is, the directory and certificate resources are
the interfaces between ACME and the outside world, so it makes sense not to
force the outside world into the ACME authentication model.  In the same
vein, capability URLs could be sensible here as an optional protection,
since they're an authn model that's easy for the outside world to use.

In addition, the content of certificate resources is tightly constrained,
so we don't have the problem that we have with the JSON resources, that a
server might add some information that violates privacy expectations.

So I would propose that we say:

- GETs are allowed for directory, newNonce, and certificate resources
- Servers MUST still respond to POST-as-GET requests for certificates, to
simplify client logic
- If a server is concerned about the privacy of certificate resources, then
they SHOULD assign them capability URLs.

I'll be updating the PR to reflect some comments in Github a little later
today, and will incorporate the above unless people think it's awful.

--Richard

On Thu, Aug 30, 2018 at 8:46 PM Felipe Gasper <[email-masked]>
wrote:

> > > In shared hosting environments it’s common for a privileged process to
> request certificates on behalf of user accounts. This avoids having 1,000s
> of ACME server registrations from a single server. While certificates are
> generally made available within seconds, theoretically the delay between
> request and issuance could be much longer (e.g., for OV/EV), such that it
> might be prudent for that privileged process to give the order ID to the
> user and have the user poll for the certificate, e.g., via cron.
> >
> problem Adam brought up. You could make the certificate URLs unpredictable,
> but then you've introduced a notion of capability URLs[1], which breaks the
> notion of having a single authentication system for ACME.
>
> I suppose if I have:
>
> > You could make the certificate URLs unpredictable, but then you've
> introduced a notion of capability URLs[1], which breaks the notion of
> having a single authentication system for ACME.
>
> I can see that.
>
>
> _______________________________________________
> Acme mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/acme
>

---

From: "Salz, Rich" <[email-masked]>
Date: Fri, 31 Aug 2018 14:19:24 +0000

*   - If a server is concerned about the privacy of certificate resources, then they SHOULD assign them capability URLs.

Not a fan of capability URL’s; does get/post handle things well enough?

---

From: Felipe Gasper <[email-masked]>
Date: Fri, 31 Aug 2018 10:21:52 -0400

I wonder, then, if it’s worth making it discoverable whether the server allows a plain GET for a certificate … other than, of course, getting a 405 back when the client tries to request a certificate via GET.

-F

> On Aug 31, 2018, at 10:16 AM, Richard Barnes <[email-masked]> wrote:
> 
> TBH, I'm not averse to allowing GETs for certificate resources.  It seems analogous to allowing them for the directory resource, just on the opposite side of the process.  That is, the directory and certificate resources are the interfaces between ACME and the outside world, so it makes sense not to force the outside world into the ACME authentication model.  In the same vein, capability URLs could be sensible here as an optional protection, since they're an authn model that's easy for the outside world to use.
> 
> In addition, the content of certificate resources is tightly constrained, so we don't have the problem that we have with the JSON resources, that a server might add some information that violates privacy expectations.
> 
> - Servers MUST still respond to POST-as-GET requests for certificates, to simplify client logic
> - If a server is concerned about the privacy of certificate resources, then they SHOULD assign them capability URLs.
> 
> I'll be updating the PR to reflect some comments in Github a little later today, and will incorporate the above unless people think it's awful.
> 
> --Richard
> 
> On Thu, Aug 30, 2018 at 8:46 PM Felipe Gasper <[email-masked]> wrote:
> 
>

---

From: Richard Barnes <[email-masked]>
Date: Fri, 31 Aug 2018 10:23:12 -0400

To be clear, I'm proposing that the server MUST allow GET for a certificate
resource (as well as POST-as-GET).  It can protect those GETs with
capability URLs if it wants to.

On Fri, Aug 31, 2018 at 10:21 AM Felipe Gasper <[email-masked]>
wrote:

> I wonder, then, if it’s worth making it discoverable whether the server
> allows a plain GET for a certificate … other than, of course, getting a 405
> back when the client tries to request a certificate via GET.
>
> -F
>
> > TBH, I'm not averse to allowing GETs for certificate resources.  It
> seems analogous to allowing them for the directory resource, just on the
> opposite side of the process.  That is, the directory and certificate
> resources are the interfaces between ACME and the outside world, so it
> makes sense not to force the outside world into the ACME authentication
> model.  In the same vein, capability URLs could be sensible here as an
> optional protection, since they're an authn model that's easy for the
> outside world to use.
> >
> > In addition, the content of certificate resources is tightly
> constrained, so we don't have the problem that we have with the JSON
> resources, that a server might add some information that violates privacy
> expectations.
> >
> > - If a server is concerned about the privacy of certificate resources,
> then they SHOULD assign them capability URLs.
> >
> > I'll be updating the PR to reflect some comments in Github a little
> later today, and will incorporate the above unless people think it's awful.
> >
> > --Richard
> >
> certificates are generally made available within seconds, theoretically the
> delay between request and issuance could be much longer (e.g., for OV/EV),
> such that it might be prudent for that privileged process to give the order
> ID to the user and have the user poll for the certificate, e.g., via cron.
> > >

---

From: Richard Barnes <[email-masked]>
Date: Fri, 31 Aug 2018 10:25:07 -0400

The problem with using POST-as-GET for certificate resources, as Felipe I
think pointed out, is that the thing that downloads the certificate URL is
often not an ACME player, doesn't have an account, etc.  It's a web server
or something.  (cf. the STAR drafts.)  What I'm saying is that it's painful
to make them integrate with ACME and we don't get any benefit.

On Fri, Aug 31, 2018 at 10:20 AM Salz, Rich <[email-masked]> wrote:

>
>    - - If a server is concerned about the privacy of certificate
>    resources, then they SHOULD assign them capability URLs.
>
>
>

---

From: "Salz, Rich" <[email-masked]>
Date: Fri, 31 Aug 2018 14:51:10 +0000

*   The problem with using POST-as-GET for certificate resources, as Felipe I think pointed out, is that the thing that downloads the certificate URL is often not an ACME player, doesn't have an account, etc.  It's a web server or something.  (cf. the STAR drafts.)  What I'm saying is that it's painful to make them integrate with ACME and we don't get any benefit.

Oh right.  “Never mind.”

---

From: Nico Williams <[email-masked]>
Date: Fri, 31 Aug 2018 10:15:51 -0500

> … then one could surmise (however justifiably) that these two may be related, so I see the point.

If these numbers are certificate serial numbers, then by all means they
must be randomized.  Even if not, predictable, serial account-number-
like numbers should not be part of a URL without some other component to
make URL generation unpredictable.

> > introduced a notion of capability URLs[1], which breaks the notion
> > of having a single authentication system for ACME.
> 
> I can see that.

Eh?  Just because they are randomized / unpredictable does not mean that
they are capability URLs or confidentiality-sensitive, nor that they
must be one-time-use only.

Nico
--

---

From: Tim Hollebeek <[email-masked]>
Date: Fri, 31 Aug 2018 15:22:37 +0000

The capability URL stuff introduces a level of complexity that I'd rather not try to analyze at this point.  I'm afraid people will rush to implement it and get it wrong in hard to anticipate ways, or that there are consequences we haven't foreseen at this late hour.

POSTs seem to be the right long term solution.  Why is it necessary that the server MUST allow GETs, and cannot consider them to be a legacy feature that should eventually be deprecated?

-Tim

> -----Original Message-----
> From: Acme <[email-masked]> On Behalf Of Nico Williams
> Sent: Friday, August 31, 2018 5:16 PM
> To: Felipe Gasper <[email-masked]>
> Cc: ACME WG <[email-masked]>
> Subject: Re: [Acme] ACME breaking change: Most GETs become POSTs
> 
> If these numbers are certificate serial numbers, then by all means they must be
> randomized.  Even if not, predictable, serial account-number- like numbers
> should not be part of a URL without some other component to make URL
> generation unpredictable.
> 
> they are capability URLs or confidentiality-sensitive, nor that they must be one-
> time-use only.
> 
> Nico
> --
>

---

From: Richard Barnes <[email-masked]>
Date: Fri, 31 Aug 2018 11:54:02 -0400

I have updated the pull request here with a couple of major changes:

* Instead of using the "typ" header parameter to signal POST-as-GET, the
client signals a POST-as-GET request by sending an empty JWS payload.  It
seems like all of the actual-POST requests we have send a JSON object, so
this should be a reliable distinguisher.

* GET requests are now allowed for certificate resources, with a
recommendation for CAs to use capability URLs if they want access control.

* Servers MUST return a 405 if they get a GET for a resource other than
directory/newNonce/certificate.

The last change makes this a harder break for current clients/servers.  But
it's only breaking in the sense that they're not in compliance with the
RFC; you can operate a non-RFC-compliant service, no protocol police.  And
I think it results in a cleaner, more reliable definition here.

--Richard

---

From: "Salz, Rich" <[email-masked]>
Date: Fri, 31 Aug 2018 17:14:15 +0000

*   * Servers MUST return a 405 if they get a GET for a resource other than directory/newNonce/certificate.

They means client? Or there’s a word missing, and “they get a” is “they do not support”

---

From: Richard Barnes <[email-masked]>
Date: Fri, 31 Aug 2018 13:21:35 -0400

No, if a server receives a GET request for a resource other than those
specified, then it MUST return 405.  But please check out the PR and see if
it's clear there.

On Fri, Aug 31, 2018 at 1:14 PM Salz, Rich <[email-masked]> wrote:

>
>    - * Servers MUST return a 405 if they get a GET for a resource other
>    than directory/newNonce/certificate.
>
>
>

---

From: Daniel McCarney <[email-masked]>
Date: Fri, 31 Aug 2018 14:56:46 -0400

I think its an anti-pattern to standardize protocol features that haven't
been implemented by anyone so here's a PR[0] for the Pebble ACME server
that implements Richard's proposal[1] to establish viability. The
proposal seems
OK to me given the trade-offs/alternatives on the table.

I would encourage other ACME client/server developers to try their hand at
implementing the changes from [1] as well. I've tested my PR with
hand-rolled requests but not as part of an automated issuance process with
a "real" ACME client. Speak now or forever hold your bugs.

[0] - https://github.com/letsencrypt/pebble/pull/162
[1] - https://github.com/ietf-wg-acme/acme/pull/445/files

---

From: Jacob Hoffman-Andrews <[email-masked]>
Date: Fri, 31 Aug 2018 12:30:51 -0700

On 08/31/2018 07:25 AM, Richard Barnes wrote:
> The problem with using POST-as-GET for certificate resources, as 
> Felipe I think pointed out, is that the thing that downloads the 
> certificate URL is often not an ACME player, doesn't have an account, 
> etc.  It's a web server or something. (cf. the STAR drafts.)  What I'm 
> saying is that it's painful to make them integrate with ACME and we 
> don't get any benefit.
AFAIK, no current ACME client hands off certificate URLs to 
less-privileged processes.

Keeping GETs for certificates undermines the goal of making the 
POST-as-GET change. Certificate resources may be constructed in 
enumerable ways, like:

/account/100/certificate/3438
/account/201/certificate/3439
/account/100/certificate/3440*

While many CAs may not consider correlation of certificates by account 
to be sensitive, our goal with this change is to eliminate a footgun for 
CAs who do consider it sensitive, by simply ensuring all requests are 
authenticated by default. Consistent authentication also has the 
potential to simplify by client and server libraries.

I think it would be a mistake to carve out this exception in the main 
ACME spec for use cases that are still speculative. Instead, if there is 
a use case that truly requires unauthenticated certificate retrieval, it 
should be defined as an extension or an optional feature.

In short, I think certificates should be POST-as-GET just like the other 
resources.

*Note: I'm aware that certificate serial numbers must be randomized, but 
there is no requirement that the certificate serial number be present in 
the URL.

---

From: Daniel McCarney <[email-masked]>
Date: Fri, 31 Aug 2018 15:30:53 -0400

>
> here's a PR[0] for the Pebble ACME server that implements Richard's
> proposal[1] to establish viability. The proposal seems OK to me given the
> trade-offs/alternatives on the table.

One of the changes Richard made in his second iteration of PR #445 was to
differentiate a POST from a POST-as-GET by sending an empty body "a
zero-length octet string" in the POST JWS. Talking about the experience of
implementing this more with Jacob Hoffman-Andrews I think I've come around
to preferring an alternative design. #445 as described requires server and
client developers pay careful attention to the differences between `null`
and `""` in serialization/deserialization and might be bumping into
differences between languages/JSON parsers. Both myself and Jacob failed to
get it right on a first-go[0] and if people this close to the specification
are going to trip on this I think we can be assured others will too.

A proposed alternative: We use `{}` as the body for POST-as-GET (as
suggested by Jacob[1]) and further specify that challenges can only be
initiated with a POST and do not support POST-as-GET.

Using `{}` as the body matches the long standing method of authenticating
access to account information and avoids any null troubles. Removing
polling of challenges is required to free up POSTing `{}` as the challenge
initiation message. All of the challenge information is already accessible
by POST-as-GET polling the associated authorization and it seems sensible
to remove that redundancy as it can cause bugs when a client developer
polls a challenge for an authorization not realizing the associated
authorization has changed to status valid from a different challenge.

Thoughts?

[0] https://github.com/letsencrypt/pebble/pull/162#discussion_r214446189
[1] https://github.com/ietf-wg-acme/acme/pull/445#issuecomment-417505743

On Fri, Aug 31, 2018 at 2:56 PM, Daniel McCarney <[email-masked]>
wrote:

> that implements Richard's proposal[1] to establish viability. The proposal seems

---

From: Daniel McCarney <[email-masked]>
Date: Fri, 31 Aug 2018 15:33:54 -0400

> In short, I think certificates should be POST-as-GET just like the other

+1. If we're replacing the GETs to Orders, Authorizations and Challenges
there's no sense in excluding Certificates. I prefer the uniformity over
exceptions for use-cases that don't have strong real-world
use/implementations.

On Fri, Aug 31, 2018 at 3:30 PM, Jacob Hoffman-Andrews <[email-masked]> wrote:

> POST-as-GET change. Certificate resources may be constructed in enumerable
> ways, like:
>
> While many CAs may not consider correlation of certificates by account to
> be sensitive, our goal with this change is to eliminate a footgun for CAs
> who do consider it sensitive, by simply ensuring all requests are
> authenticated by default. Consistent authentication also has the potential
> to simplify by client and server libraries.
>
> I think it would be a mistake to carve out this exception in the main ACME
> spec for use cases that are still speculative. Instead, if there is a use
> case that truly requires unauthenticated certificate retrieval, it should
> be defined as an extension or an optional feature.
>

---

From: Nico Williams <[email-masked]>
Date: Fri, 31 Aug 2018 14:34:12 -0500

On Thu, Aug 30, 2018 at 04:20:41PM -0700, Jacob Hoffman-Andrews wrote:
> 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.

This is true, but GET isn't the issue.  If you have iterable URI
constructions then POST will let you iterate them just as well as GET.

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

How does using POST address this?

Neither does GET imply unauthenticated, nor does POST imply
authenticated.

GET vs POST can make a difference in the context of HTML (where you can
get a user-agent to GET a resource without the user taking action), but
I don't think that's relevant here.

> taking this path we should aim to come to consensus and land the final spec
> quickly to reduce uncertainty for ACME client implementers.

This is wrong.  GET vs POST makes no difference as to iteration of
resources.

Please use HTTP correctly.

If a resource is read-only or GETs of it would be idempotent anyways,
then use GET.

Do include normative text about the shape of the URIs to prevent
iteration via monotonic increment of numeric components or query
parameters.

Do specify what requires authentication and what does not.

Do not misuse HTTP verbs.

Nico
--

---

From: Daniel McCarney <[email-masked]>
Date: Fri, 31 Aug 2018 15:37:01 -0400

> How does using POST address this?

Please read the draft. We're talking about POSTs authenticated with JWS not
vanilla HTTP POSTs.

On Fri, Aug 31, 2018 at 3:34 PM, Nico Williams <[email-masked]>
wrote:

> when
> and
> spec

---

From: Nico Williams <[email-masked]>
Date: Fri, 31 Aug 2018 14:43:34 -0500

> Please read the draft. We're talking about POSTs authenticated with JWS not

That really should have been an HTTP authentication method :(

---

From: Jacob Hoffman-Andrews <[email-masked]>
Date: Fri, 31 Aug 2018 13:14:58 -0700

> /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?

---

From: Adam Roach <[email-masked]>
Date: Fri, 31 Aug 2018 15:51:18 -0500

On 8/31/18 3:14 PM, Jacob Hoffman-Andrews wrote:
> well leave the non-sensitive resources as regular GETs.

No.

The baseline problem here is that the original analysis that determined 
that orders, authorizations, challenges, and certificates were "not 
sensitive" was incorrect. These are all potentially sensitive from a 
privacy perspective. Perhaps not in isolation, but the problem here is 
correlation, not isolation.

/a

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 31 Aug 2018 13:57:06 -0700

> That really should have been an HTTP authentication method :(

Not really, no. First, HTTP is just being used as a transport here. Second,
authentication is by digital signature, and that's not really
well-supported in HTTP. Third, it's way too late now to be having this
discussion.

-Ekr

---

From: Jacob Hoffman-Andrews <[email-masked]>
Date: Fri, 31 Aug 2018 13:58:14 -0700

> correlation, not isolation.

What do you think about the question of preventing correlation of the 
existence of URLs? Do you think that's in-scope, or should we only 
prevent correlation of the contents?

Here's another example of a URL scheme where revealing existence would 
reveal some correlation data:

/account/100/certificate/example.com
/account/201/certificate/example.net
/account/100/certificate/secret.example.com

Personally, I think it will be intractable to hide the 
existence/non-existence of URLs, and we should just mention it as a risk 
in the security considerations section. That leads me to the conclusion 
that it's fine to return Unauthorized for resources that exist, by the 
client does not own.

---

From: Richard Barnes <[email-masked]>
Date: Fri, 31 Aug 2018 16:58:36 -0400

> What do you all think? Should enumeration of the existence of URLs be

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

---

From: Adam Roach <[email-masked]>
Date: Fri, 31 Aug 2018 16:08:00 -0500

On 8/31/18 3:58 PM, Jacob Hoffman-Andrews wrote:
>> The baseline problem here is that the original analysis that 
>> determined that orders, authorizations, challenges, and certificates 
>> were "not sensitive" was incorrect. These are all potentially 
>> sensitive from a privacy perspective. Perhaps not in isolation, but 
>> the problem here is correlation, not isolation.
>

The latter.

> existence/non-existence of URLs, and we should just mention it as a 
> risk in the security considerations section. That leads me to the 
> conclusion that it's fine to return Unauthorized for resources that 
> exist, by the client does not own. 

I think that's correct.

/a

---

From: Nico Williams <[email-masked]>
Date: Fri, 31 Aug 2018 16:19:43 -0500

> well-supported in HTTP. Third, it's way too late now to be having this

Fair enough.

---

From: Richard Barnes <[email-masked]>
Date: Fri, 31 Aug 2018 17:21:38 -0400

I was able upgrade the lego client in a pretty short patch (5 files
changed, 26 insertions(+), 16 deletions(-)) [0].  It interoperates with
Daniel's branch of pebble.

--Richard

[1] https://github.com/bifurcation/lego/pull/1

---

From: Richard Barnes <[email-masked]>
Date: Fri, 31 Aug 2018 17:26:44 -0400

On Fri, Aug 31, 2018 at 3:30 PM Daniel McCarney <[email-masked]> wrote:

>> proposal[1] to establish viability. The proposal seems OK to me given
>> the trade-offs/alternatives on the table.
>
>

The confusion over `null` and `""` is actually part of the motivation for
using a zero-length body -- it's not JSON.   That's what makes it a good
signal.  If you're doing POST-as-POST, you have a JSON body and you have to
do JSON stuff.  If you're doing POST-as-GET, you're not and you don't.  It
guarantees clean separation between the two cases, minimizing risk of
confusion.

I think the cleaner answer here is to fix the "account fetch" case to use
POST-as-GET.

--Richard

>> I would encourage other ACME client/server developers to try their hand
>> at implementing the changes from [1] as well. I've tested my PR with
>>>>    - * Servers MUST return a 405 if they get a GET for a resource
>>>>    other than directory/newNonce/certificate.
>>>>
>>>>
>>>>

---

From: Richard Barnes <[email-masked]>
Date: Fri, 31 Aug 2018 17:41:04 -0400

> should be defined as an extension or an optional feature.

I understand the desire for uniformity; I'm just concerned we're going
overboard here.

I could live with this being optional, but I would prefer to go ahead and
add it (because STAR needs it) and keep the negotiation minimal.  I would
propose that we just say the server MAY accept GETs for certificate URLs,
returning 405 if not.

That way a client with a GET-based use case would have to either find out
out of band that the server was compatible, or else fail when it tries.
But that seems like an acceptable outcome to me.  If we need an "I always
do cert+GET" signal, we can toss it in the "meta" dictionary later.

--Richard

---

From: Felix Fontein <[email-masked]>
Date: Fri, 31 Aug 2018 23:57:41 +0200

Hi Richard,

> changed, 26 insertions(+), 16 deletions(-)) [0].  It interoperates
> with Daniel's branch of pebble.

you were faster :) I've adjusted Ansible's acme_certificate module to
also work with Daniel's branch in
https://github.com/ansible/ansible/pull/44988

Most of the changes are general refactoring to make use of a single URL
fetch method which has access to the ACME account data; the main part
related to POST-as-GET is only a few lines.

Cheers,
Felix

> > I think its an anti-pattern to standardize protocol features that
> > haven't been implemented by anyone so here's a PR[0] for the Pebble
> > ACME server that implements Richard's proposal[1] to establish
> > viability. The proposal seems OK to me given the
> > I would encourage other ACME client/server developers to try their
> > hand at implementing the changes from [1] as well. I've tested my
> > PR with hand-rolled requests but not as part of an automated
> > issuance process with a "real" ACME client. Speak now or forever
> > hold your bugs.
> >
> >> No, if a server receives a GET request for a resource other than
> >> those specified, then it MUST return 405.  But please check out
> >> the PR and see if it's clear there.
> >>

---

From: Richard Barnes <[email-masked]>
Date: Fri, 31 Aug 2018 18:08:50 -0400

Hey all,

This thread forked into a couple of different issues, so I wanted to post a
little end-of-day summary of the issues and where we stand.  I've updated
the PR [1] to reflect most of today's discussion.

===

ISSUE 1. Should we do POST-as-GET at all, vs. keeping GET and doing the
privacy analysis?

It seems like there's pretty strong agreement that we should get rid of
GET, as the architecturally cleanest option.

===

ISSUE 2: How should we signal that POST-as-GET request is different from
other POST requests?

The current PR signals this by sending a JWS with an empty (zero-octet)
payload, instead of a JSON object.  Jacob and Daniel suggested that we
should instead use the payload being an empty JSON object as the signal.
An earlier draft PR used a field in the protected header.

===

ISSUE 3: Should servers be required to allow GET requests for certificate
URLs?

I had proposed this earlier today; Jacob and Daniel pushed back.  I have
implemented a compromise in the latest PR, where servers MAY accept GET
requests.

===

ISSUE 4: How should we address the risk that an attacker can discover URLs
by probing for Unauthorized vs. Not Found?

There seemed to be agreement on the list that this should be addressed with
some guidance to servers on how to assign URLs.  I have just added some
text to the PR for this.

===

It seems to me we're pretty much closed on the first issue, and the other
three are still open.  Please send comments, so we can resolve this issue
and get the document back in motion!

Thanks,
--Richard

[1] https://github.com/ietf-wg-acme/acme/pull/445