I've proposed a first cut at implementing the changes I described in my original post as an ACME PR https://github.com/ietf-wg-acme/acme/pull/342
On Fri, Sep 22, 2017 at 7:19 PM, Roland Bracewell Shoemaker < [email protected]> wrote: > Broad points: > > I understand that this group has been moving towards standardization for > a while but I really think that attempting to fix these issues with > creative readings of the existing language and minimal editorial changes > is asking for trouble and return trips to the WG in the future when > these band-aids turn out to not be fully thought out or themselves > introduce new problems. > > These issues have come up during, as far as I'm aware, the only full-fat > implementation of the current version of this specification and that > implementation itself is maybe only 40-50% done. Assuming that these > will be the only issues that are discovered seems to be, again, asking > for trouble. > > Comments on the proposed fixes: > > 1. Causing issuance really seems like it should be required to be an > authorized action, allowing this to happen by a GET allows anyone who is > able to determine the order URL to cause issuance to happen. > Implementing this behavior, even if not explicitly defined in the > specification, will almost definitely lead to users relying on it > (Hyrum's Law) which again will be a problem if another user is able to > simply send of a handful of GETs and cause another users certificate to > be issued. > > 2. Unless another implementer comes along this would mean that the only > existing implementation of the current specification before > standardization would not be implementing a major section of this > document. At this point why not just go back to the -03/-04 draft > new-authz flow. As Daniel has already pointed out this also completely > breaks one of the major reasons to use the new-order flow: policy based > authorization creation. How would a CA indicate that a user _may not_ > need an authorization for www.example.com when issuing for example.com > or that they require a specific set of authorizations when issuing for > *.example.com? > > Like I said at the start these band-aid editorial fixes seem to just > create another set of problems that cannot themselves be solved with > further minor editorial changes. > > On 09/21/2017 11:40 AM, Richard Barnes wrote: > > I talked a bit with Daniel about this off-list. Here's a summary of > > where we got to: > > > > 1. In the current "new-order" flow, the server doesn't *really* have to > > be proactive -- instead of updating an order object when an authz > > changes state, it can wait to update/issue until the client polls for > > the order object, indicating that it's actually interested in having a > > certificate. That doesn't alleviate the pain of storing the CSR, but it > > at least avoids the expense of finding affected orders and issuing in > > cases where the client abandons the order. If we think this approach is > > OK, I would propose that we revise the document to make clear that it is > > OK. What do folks think? Daniel noted that there might be some issues > > with GET idempotency here, but I don't think this actually makes GET > > non-idempotent. > > > > 2. Some CAs might want to support only the "new-authz" flow, i.e., never > > allow a "new-order" request if the relevant authorizations haven't > > already been done. It seems like this could be addressed in a pretty > > straightforward manner just by defining a new error code (say > > "preauthRequired") that the server can return in this case. > > > > Personally, it seems to me that if we make the clarification (1) and add > > the error code (2) described here, that would address the pain points > > Daniel raises, without a whole lot of new mechanism. I'm not really > > seeing much additional value to be had from an explicit "ok issue now" > > request (vs. the GET poll). > > > > --Richard > > > > > > > > On Wed, Sep 20, 2017 at 1:22 PM, Richard Barnes <[email protected] > > <mailto:[email protected]>> wrote: > > > > Hey Daniel, > > > > Thanks for the input. I can see why you might be feeling some pain > > here, but I'm not sure the proposed solution is quite right. > > > > Note that ACME already has the "new-authorization" flow, which does > > pretty much exactly what you're proposing. The only difference is > > that instead of authorizations being created all at once in response > > to a "new-cert" request, they're created individually by the > > client. But it's ultimately the same number of RTTs (authz fetch ~ > > new-authz) -- or rather, one fewer in the new-authz case because > > there's no new-cert request. To what degree would your problem be > > solved simply by having the affected integrators move over to that > flow? > > > > I can sympathize that the new-order flow might not be suitable for > > all use cases. Maybe it would be useful to write down some thoughts > > on which use cases are best addressed by which flows. > > > > --Richard > > > > > > > > On Tue, Sep 19, 2017 at 12:26 PM, Daniel McCarney > > <[email protected] <mailto:[email protected]>> wrote: > > > > Hi folks, > > > > Just over a year ago in a thread titled "Proactive vs > > On-Finalization > > Certificate Issuance"[0] we reached the consensus on the > > question of whether to > > issue a certificate "on-finalization" or "proactively" with the > > conclusion to > > standardize on proactive issuance. > > > > Implementation experience shows that proactive issuance is slow > > in practice. An > > order can be associated with many authorizations and an > > authorization can be > > associated with many orders. This interacts poorly with > > optimizations Let's > > Encrypt has developed from in-the-field experience with ACME and > > it is difficult > > to rate-limit effectively. I propose that we return to the > > on-finalization style > > approach and that we provide the CSR during finalization.. > > > > ## Issues with proactive issuance > > > > ### Authorization Reuse > > > > Proactive issuance requires that when an authorization is > > switched to a valid > > state by the result of a challenge update that we find the > > associated orders and > > iterate each order's authorizations to see if all of the > > authorizations are > > valid and issuance can occur. > > > > Let's Encrypt reuses existing authorizations[1][2] whenever > > possible, as > > encouraged by ACME. This has been of huge value in reducing > > resource consumption > > (both in terms of database storage and challenge/API requests). > > Many clients > > create pending authorizations they do not finalize and similarly > > re-create > > pending authorizations for identifiers that the account already > > has valid > > authorizations for. Unchecked this leads to significant database > > growth and > > resource consumption, even with aggressive rate-limits[3]. > > > > The combination of authorization reuse and proactive issuance > > means a given > > authorization can be associated with many orders. This > > necessitates an expensive > > many-to-many query at each authorization update to see if any > > associated > > orders are now complete. > > > > One possible workaround is a rate-limit that would constrain the > > number of > > orders an authorization can be associated with. However > > establishing the value > > of the limit to both reduce server-side load & also effectively > > support Let's > > Encrypt's large-volume integrators and their issuance patterns > > is challenging. > > > > ### CSR-first new-order flow > > > > To support proactive issuance the CA also needs to have the CSR > > for the order > > at-hand when checking each authorization in case issuance can > > proceed. The > > `new-order` request that creates the order therefore carries the > > full CSR that > > was previously delivered by the "certificate finalize" message. > > > > We see users create many more authorizations than they are able > > to finalize > > successfully. With the legacy "new-cert" flow our authorization > > reuse > > dramatically helped reduce the DB space used up by > > authorizations that will > > never lead to issuance because no CSR is stored until all > > identifiers are > > validated. > > > > With the new-order flow we have to accept and store a full CSR > > before handing > > back authorizations to the client. Reuse of authorizations does > > not prevent the > > DB bloat that will occur from users submitting new order > > requests and not > > fulfilling them. The CSR contains a full public key and is one > > of the single > > largest contributors to DB disk space usage. Addressing this > > will require > > another strict rate limit on outstanding new-orders and is again > > difficult to > > “dial-in” in to both prevent excessive resource consumption and > > also maintain > > the ability for big integrators to process large-scale issuance > > using our API. > > > > # Proposed Change > > > > I believe we should change the `new-order` endpoint to not > > accept a full CSR but > > to instead accept a list of identifiers that the ACME client > > wishes to > > authenticate & issue for. Authorizations can be created and > > returned for those > > domains as happens today. > > > > The order resource should be changed to have a “finalizeURL” > > field which > > provides the client a URL to POST a CSR to indicate that the CA > > should issue the > > certificate. Proactive issuance should be removed outright. > > > > This will address both the problem of scanning existing > > many-to-many orders > > & their authorizations as well as the db bloat that will occur > from > > front-loading the delivery of the CSR. > > > > It may be tempting to leave proactive issuance as an optional > > feature but this > > will require maintaining the CSR in the new-order and I also > > believe that having > > two very distinct methods of issuance will complicate the client > > ecosystem and > > returns us to the question of how to determine which will occur > > that spawned the > > original "Proactive vs On-finalization Certificate Issuance" > > thread[0]. > > > > [0] > > https://mailarchive.ietf.org/arch/msg/acme/0lVmGl8e- > rmSH0x7ycDW5dj6GAY > > <https://mailarchive.ietf.org/arch/msg/acme/0lVmGl8e- > rmSH0x7ycDW5dj6GAY> > > [1] > > https://community.letsencrypt.org/t/upcoming-api-changes/17947 > > <https://community.letsencrypt.org/t/upcoming-api-changes/17947> > > [2] > > https://community.letsencrypt.org/t/automatic-recycling-of- > pending-authorizations/41321 > > <https://community.letsencrypt.org/t/automatic- > recycling-of-pending-authorizations/41321> > > [3] https://letsencrypt.org/docs/rate-limits/ > > <https://letsencrypt.org/docs/rate-limits/> > > > > > > _______________________________________________ > > Acme mailing list > > [email protected] <mailto:[email protected]> > > https://www.ietf.org/mailman/listinfo/acme > > <https://www.ietf.org/mailman/listinfo/acme> > > > > > > > > > > > > _______________________________________________ > > Acme mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/acme > > > > _______________________________________________ > Acme mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/acme >
_______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
