Subject: Re: [Acme] Fw: About the ACME Protocol

From: Peter Kurrasch <[email-masked]>
Date: Fri, 05 Aug 2016 18:47:39 -0500

I'd like to offer a general comment up front:

From the standpoint of a maximally secure server and protocol, my attitude is to make the server smart, the client dumb, and the protocol minimal and unfriendly. When I read section 6.1 and following, I see requirements that are contrary to this perspective--for example, the link relations.‎ While I can imagine some of the ways it might be appealing to have those relationships, all I see are security vulnerabilities waiting to happen.

Obviously I haven't been a part of the discussions that led to these decisions being made and I don't intend to rehash stuff unnecessarily. That said, if there is interest in discussing some of this further I'd be happy to elaborate.

And now, some specific comments:

I do think section 5.3 is too heavy on server implementation considerations and is better left out of a protocol specification. I'm also not sure how I feel about a CA moving ACME stuff around a content delivery network. If done without sufficient planning it could open up a whole other set of problems. A web app firewall makes sense, however, and should perhaps even be a requirement of a good ACME deployment.

In section 6.2, I don't think it makes sense to say the server must ignore something the client sends in. Why have the client send superfluous data in the first place?

‎In section 6.2.2 it would be cleaner to say what a server is expected to do when requests come in for a deactivated account.

‎In section 6.3, if a server must report an error, which error?

The above ‎points for sections 6.2 and 6.3 also apply in section 6.4.1.

Whenever the next security analysis is performed, I hope that section 9.3 will be updated to discuss how rate limiting itself may used ‎as a DoS attack vector. If I want to prevent someone from being able to renew their cert, I could just send in junk periodically to make sure the rate limitation kicks in and prevents the real cert owner from performing the renewal.

Sorry it took so long to respond but hopefully this is still considered to be helpful. Thanks.

From: Salz, Rich

Sent: Thursday, July 21, 2016 3:24 AM‎

I stripped most of your message out, trying to leave only the questions that I think still need replies. But please feel free to continue this conversation.

> Regarding the on-going development of the spec: I was thinking more about the individual commits on github and less about the IETF process. I presume that most commits will not get much scrutiny but a periodic (holistic?) review of the doc is expected to find and resolve conflicts, etc. Is that a fair statement?

Not necessarily. Especially this late in the game, I think many -- probably most, in fact -- readers look at individual PR's, as they are already familiar with the overall document.

> In the -03 version of the draft, section 6.1 is where I felt the spec was getting too much into server implementation details. I think there were some other spots where "server must" statements felt a little over-specified.

It would be good (from the WG viewpoint) to list specifics.

> The versioning strategy of having CA's provide different URL's for different versions of different clients might not scale well.

On the other hand, it might. Versioning protocols is always hard. We'll have to see what needs to be done if we revise the protocol. We did just decide to add version information into the protocol (https://github.com/ietf-wg-acme/acme/issues/128).

/r$, co-chair