The 10/06/2018 17:27, 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.
>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 _______________________________________________ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
