Subject: [Acme] Allow get for certificates?

From: "Salz, Rich" <[email-masked]>
Date: Sat, 6 Oct 2018 15:31:02 +0000

In order to address an issue raised during IESG review, unauthenticated GET for ACME server resources was changed to a simple POST that had a signed message body, providing authentication. Some raised the issue that they still wanted GET for certificates, as they’re public information and that sometimes a different process (without the account credentials) might be involved in the deployment workflow.  STAR was mentioned as an example.

There is now concern about calling out STAR, as it is still a WG draft and the full extent of its requirements are not known.

If you have anything else to add to this discussion, please do so now.

diff --git a/draft-ietf-acme-acme.md b/draft-ietf-acme-acme.md
index 26eeeef..f1ca93f 100644
--- a/draft-ietf-acme-acme.md
+++ b/draft-ietf-acme-acme.md
@@ -463,17 +463,6 @@ resources (see {{resources}}), in addition to POST-as-GET requests
for these resources.  This enables clients to bootstrap into the
ACME authentication system.
-The server MAY allow GET requests for certificate resources in
-order to allow certificates to be fetched by a lower-privileged
-process, e.g., the web server that will use the referenced
-certificate chain.  (See {{?I-D.ietf-acme-star}} for more advanced
-cases.)  A server that allows GET requests for certificate resources
-can still provide a degree of access control by assigning them
-capability URLs {{?W3C.WD-capability-urls-20140218}}.
-As above, if the server does not allow GET requests for a given
-resource, it MUST return an error with status code 405 "Method Not
-Allowed" and type "malformed".
-
## Request URL Integrity
 It is common in deployment for the entity terminating TLS for HTTPS to be different

---

From: Eric Rescorla <[email-masked]>
Date: Sat, 6 Oct 2018 09:52:35 -0700

Speaking as Area Director: there is no process problem with this reference.
Of course, it's a WG decision whether it's advisable.

-Ekr

On Sat, Oct 6, 2018 at 8:31 AM Salz, Rich <[email-masked]> wrote:

> In order to address an issue raised during IESG review, unauthenticated
> GET for ACME server resources was changed to a simple POST that had a
> signed message body, providing authentication. Some raised the issue that
> they still wanted GET for certificates, as they’re public information and
> that sometimes a different process (without the account credentials) might
> be involved in the deployment workflow.  STAR was mentioned as an example.
>
>
>
> There is now concern about calling out STAR, as it is still a WG draft and
> the full extent of its requirements are not known.
>
>
>
> _______________________________________________
> Acme mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/acme
>

---

From: Richard Barnes <[email-masked]>
Date: Sat, 6 Oct 2018 17:27:29 -0400

I'm not hard set against this change, I just don't see much benefit.

Allowing GETs for certificate URLs is so low-risk that we weren't going to
access-control it at all until a couple weeks ago.  Now it's so high-risk
that we need to REQUIRE authentication?  That's "REQUIRED" in the RFC 2119
sense, since higher up in the section, it says that servers MUST return 405
if they get a GET, except as allowed in that section.

There are reasonable use cases for GETs.  STAR is one, but you could
imagine non-auto-renewed cases as well.  There's no security reason to cut
off those GETs, so I don't understand what value we're conserving here.
The PR says that having GETs complicates the security analysis, but this is
not some inner part of the protocol, it's the output.

The only argument that seems at all cogent here is that we don't have any
up-front signaling for whether a server supports GET or not, just the error
code.  So clients have to guess.  Maybe that's enough to motivate removing
it for now; a later doc could come along and say "allow GETs and signal it
with this field in the meta object".  But if we do that, we should be clear
that we're removing GET to keep the protocol flow clean, not for any
security reason.

--Richard

On Sat, Oct 6, 2018 at 12:53 PM Eric Rescorla <[email-masked]> wrote:

> Speaking as Area Director: there is no process problem with this
> reference. Of course, it's a WG decision whether it's advisable.
>
> -Ekr
>
>
>> There is now concern about calling out STAR, as it is still a WG draft
>> and the full extent of its requirements are not known.
>>
>>
>>

---

From: Thomas Fossati <[email-masked]>
Date: Sun, 7 Oct 2018 10:53:05 +0100

>From the point of view of STAR this is not a big deal.  We have
acme-star where to define both the plain-GET exception - which is a core
requirement for the delegation workflow - and how the server advertises
support for it.

My worry is that by accepting this change, other legit plain-GET use
cases are automatically made either more complicated or potentially
insecure (someone might decide that sharing the account key across a
bunch of edge caches or some other HA configuration is a worth
trade-off.)

That said...

> The only argument that seems at all cogent here is that we don't have
> any up-front signaling for whether a server supports GET or not, just
> the error code.  So clients have to guess.  Maybe that's enough to
> motivate removing it for now; a later doc could come along and say
> "allow GETs and signal it with this field in the meta object".

... it should be pretty easy to add the needed meta object extension
directly into the acme-acme document if this is the only missing piece?

> But if we do that, we should be clear that we're removing GET to keep
> the protocol flow clean, not for any security reason.

Emphatic +1

---

From: Richard Barnes <[email-masked]>
Date: Sun, 7 Oct 2018 15:48:54 -0400

I went ahead and posted a PR adding the "meta" field:

https://github.com/ietf-wg-acme/acme/pull/462

---

From: Yaron Sheffer <[email-masked]>
Date: Mon, 8 Oct 2018 09:49:27 +0300

IMO Richard's proposal is too coarse, in the sense that servers may want 
to publish some certificates with GET and others with POST-as-GET. So 
either this should not be a server-wide flag, or if it is, it should be 
augmented by a per-Order flag where the client can request what it needs.

Before this PR, the expectation is that certificates are only published 
with POST-as-GET by default. But extensions (such as STAR) can mandate 
that specific classes of certs be published with GET. If we don't want 
explicit per-Order signaling, we'd better leave the current text as-is.

Thanks,

     Yaron

On 07/10/18 22:48, Richard Barnes wrote:
> On Sun, Oct 7, 2018 at 5:04 AM Thomas Fossati 
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>     .... it should be pretty easy to add the needed meta object extension

---

From: "Fossati, Thomas (Nokia - GB/Cambridge, UK)" <[email-masked]>
Date: Mon, 8 Oct 2018 11:19:44 +0100

The 10/08/2018 09:49, Yaron Sheffer wrote:
> IMO Richard's proposal is too coarse, in the sense that servers may want to
> publish some certificates with GET and others with POST-as-GET. So either
> this should not be a server-wide flag, or if it is, it should be augmented
> by a per-Order flag where the client can request what it needs.

IIUC, your suggestion is to slightly change the semantics of
certificateGET to something like: "If this field is present and set to
"true", then the server, if requested by the client, allows GET requests
to certificate URLs (see {{post-as-get}}).", and add a new flag to the
Order to allow clients to request plain-GETs (which would be otherwise
405'd)?

If so, +1.

> Before this PR, the expectation is that certificates are only published with
> POST-as-GET by default. But extensions (such as STAR) can mandate that
> specific classes of certs be published with GET. If we don't want explicit
> per-Order signaling, we'd better leave the current text as-is.

I think PR#462 is one step in the right direction.  Going back to no
signalling, making this some sort of clandestine feature, is not great.

---

From: Jacob Hoffman-Andrews <[email-masked]>
Date: Mon, 8 Oct 2018 12:24:46 -0700

The POST-as-GET mess started because Adam Roach pointed out that the 
"orders" URL (listing all of an accounts orders), in some non-WebPKI 
contexts, could expose information that shouldn't be exposed.

There are two possible fixes for this:

The narrow fix -- Remove "orders." No one implements it, and this is the 
least disruptive option to a mature spec.

The broad fix -- Recognize that the problem with "orders" is merely a 
symptom of the fact that we designed a protocol that needlessly couples 
HTTP semantics (GET vs POST) with security properties (authenticated vs 
authenticated). Make structural changes to the protocol so we can simply 
authenticate everything and not have to decide, for each request, 
whether it should be authenticated or not.

I'm not excited to implement the broad fix: It's a significant 
disruption to an already-stable ecosystem. However, I'm willing to push 
through that disruption and do the work, if we wind up with a 
significantly better protocol - one that is consistent about how it 
authenticates everything. I'd also be happy to implement the narrow fix 
- it's zero work.

However, I can't accept a halfway fix. It's all of the work, with none 
of the benefit. For the same reason that certificates are safe to GET, 
so are authzs, challenges, and individual order URLs. Why would we go 
through the significant hassle of changing those, but not certificates?

On 10/06/2018 02:27 PM, Richard Barnes wrote:
> Allowing GETs for certificate URLs is so low-risk that we weren't 
> going to access-control it at all until a couple weeks ago.  Now it's 
> so high-risk that we need to REQUIRE authentication?  That's 
> "REQUIRED" in the RFC 2119 sense, since higher up in the section, it 
> says that servers MUST return 405 if they get a GET, except as allowed 
> in that section.
>
> imagine non-auto-renewed cases as well.  There's no security reason to 
> cut off those GETs, so I don't understand what value we're conserving 
> here.  The PR says that having GETs complicates the security analysis, 
> but this is not some inner part of the protocol, it's the output.
>
> "allow GETs and signal it with this field in the meta object".  But if 
> we do that, we should be clear that we're removing GET to keep the 
> protocol flow clean, not for any security reason.
>
> --Richard
>
>
>
> On Sat, Oct 6, 2018 at 12:53 PM Eric Rescorla <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     On Sat, Oct 6, 2018 at 8:31 AM Salz, Rich <[email-masked]
>     <mailto:[email-masked]>> wrote:
>
>         In order to address an issue raised during IESG review,
>         unauthenticated GET for ACME server resources was changed to a
>         simple POST that had a signed message body, providing
>         authentication. Some raised the issue that they still wanted
>         GET for certificates, as they’re public information and that
>         sometimes a different process (without the account
>         credentials) might be involved in the deployment workflow.
>         STAR was mentioned as an example.
>
>         There is now concern about calling out STAR, as it is still a
>         WG draft and the full extent of its requirements are not known.
>
>         [email-masked] <mailto:[email-masked]>
>     [email-masked] <mailto:[email-masked]>

---

From: Daniel McCarney <[email-masked]>
Date: Tue, 9 Oct 2018 10:28:12 -0400

> least disruptive option to a mature spec.

I support this narrow fix.

On Mon, Oct 8, 2018 at 3:25 PM Jacob Hoffman-Andrews <[email-masked]> wrote:

> authenticate everything and not have to decide, for each request, whether
> it should be authenticated or not.
>
>
> I'm not excited to implement the broad fix: It's a significant disruption
> to an already-stable ecosystem. However, I'm willing to push through that
> disruption and do the work, if we wind up with a significantly better
> protocol - one that is consistent about how it authenticates everything.
> I'd also be happy to implement the narrow fix - it's zero work.
>
> However, I can't accept a halfway fix. It's all of the work, with none of
> the benefit. For the same reason that certificates are safe to GET, so are
> authzs, challenges, and individual order URLs. Why would we go through the
> significant hassle of changing those, but not certificates?
>
> Acme mailing [email-masked]://www.ietf.org/mailman/listinfo/acme
>
>