> The narrow fix -- Remove "orders." No one implements it, and this is the
> least disruptive option to a mature spec.
I support this narrow fix.
On Mon, Oct 8, 2018 at 3:25 PM Jacob Hoffman-Andrews <j...@eff.org> wrote:
> 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> 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> 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
>>> https://www.ietf.org/mailman/listinfo/acme
>>>
>> _______________________________________________
>> Acme mailing list
>> Acme@ietf.org
>> https://www.ietf.org/mailman/listinfo/acme
>>
>
>
> _______________________________________________
> Acme mailing listAcme@ietf.orghttps://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
