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:
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 <e...@rtfm.com
<mailto:e...@rtfm.com>> 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
On Sat, Oct 6, 2018 at 8:31 AM Salz, Rich <rs...@akamai.com
<mailto:rs...@akamai.com>> 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.
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
_______________________________________________
Acme mailing list
Acme@ietf.org <mailto:Acme@ietf.org>
https://www.ietf.org/mailman/listinfo/acme
_______________________________________________
Acme mailing list
Acme@ietf.org <mailto:Acme@ietf.org>
https://www.ietf.org/mailman/listinfo/acme
_______________________________________________
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme
_______________________________________________
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme
