| All-- Below is a post I made to Mozilla's dev-security-policy forum. At Richard's request I'm sending it to you all for your consideration. Undoubtedly parts of the discussion are not relevant here but I'm sending the whole thing anyway in case it helps establish context. I'm happy to elaborate or answer questions as needed. Please include my direct email address, however, as I'm not able to join the ACME list itself (too many commitments already). Thanks.
Thanks, Patrick. This is helpful. A few answers/responses: 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? The report on the security audit was interesting to read. It's good to see someone even attempted it. In addition to the protocol itself it would be interesting to see an analysis of an ACME server (Boulder, I suppose). Maybe someone will do some pentesting at least? The 200 LOC is an interesting idea. I assume such an implementation would rely heavily on external libraries for certain functions (e.g. key generation, https handling, validating the TLS certificate chain provided by the server, etc.)? If so, does anyone anticipate that someone will develop a standalone, all-in-one (or mostly-in-one) client? Is a client expected to do full cert chain validation including revocation checks? 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. After reading the latest draft of the spec and the audit report, I figured I would offer up my take on the "state of the protocol", if you will. I know there will be sharp disagreements and that's fine; this is but one person's perspective. In terms of an overly broad, overly general statement, the protocol strikes me as being too new, too immature. There are gaps to be filled, complexities to be distilled, and (unknown) problems to be fixed. I doubt this comes as new information to anyone but I think there's value in recognizing that the protocol has not had the benefit of time for it to reach it's full potential. The big, unaddressed (or insufficiently addressed) issue as I see it is compatibility. This is likely to become a bigger problem should other CA's deploy ACME and as interdependencies grow over time. Plus, when vulnerabilities are found and resolved, compatibility problems become inevitable (the security audit results hint at this). The versioning strategy of having CA's provide different URL's for different versions of different clients might not scale well. One should not expect all cert applicants to have and use only the latest client software. This approach might work for now but it could easily become unmanageable. Picture, if you will, a CA that must support 20 different client versions and the headaches that can bring. My recommendation is for the protocol to accommodate version information (data and status codes) but for a separate document to discuss deployment details. A deployment doc could also be used to cover the pro's and con's of using one server to do both ACME and other Web sites and services. The chief concern is if a vulnerability in the web site can lead to remote code execution which can then impact handling on the ACME side of the fence. Just a thought. Thanks.
Before getting into specifics, I should say that you're likely to get a better answer to most of these question on the IETF ACME WG mailing list[1]. On 08/07/16 16:36, Peter Kurrasch wrote: > I see on the gitub site for the draft that updates are frequently > and continuously being made to the protocol spec (at least one a > week, it appears). Is there any formalized process to review the > updates? Is there any expectation for when a "stable" version might > be achieved (by which I mean that further updates are unlikely)? The IETF has a working group for ACME that's developing this protocol. The IETF process is hard to describe in a couple of words (you can read up on it on ietf.org if you're interested). Other related protocols such as TLS are developed in a similar fashion. > How are compatibility issues being addressed? Boulder (the only ACME server implementation right now, AFAIK) plans to tackle this by providing new endpoints (i.e. server URLs) whenever backwards-incompatible changes are introduced in a new ACME draft, while keeping the old endpoints available and backwards-compatible until the client ecosystem catches up. I imagine once ACME becomes an internet standard, future changes will be kept backwards-compatible (i.e. "extensions" of some sort), but that's just me guessing. > Has any consideration been given to possible saboteurs who might like > to introduce backdoors? The IETF process is public, which makes this harder (though not impossible) to pull off. A number of people have reviewed and audited the protocol (including a formal model[2]). > I personally don't see the wisdom in having the server > implementation details in what is ostensibly a protocol > specification. Which part of the specification mentions implementation details? > Will there be any sort of audit to establish compliance between a > particular sever implementation and this Internet-Draft? Someone could definitely build tools to check compliance, but who would enforce this, and what happens to a server/client that's not compliant? > Will the client software be able to determine the version of the > specification under which the server is operating? (I apologize if it > is in the spec; I didn't do a detailed reading of it.) On the client > side, is there a document describing the details of an ideal > implementation? Does the client inform the server to which version of > the protocol it is adhering--for example, in a user-agent string > (again, I didn't notice one). Is there any test to validate the > compliance of a client with a particular version of the > Internet-Draft? See the previous paragraph on compatibility: Server URLs can be considered backwards-compatible; there's currently no protocol version negotiation or something like that. > One thought for consideration is the idea of a saboteur who seeks to > compromise the client software. This is of particular concern if the > client software can also generate the key pair since there are the > obvious benefits to bad actors if certain sites are using a weaker > key. Just as Firefox is a target for malware, the developers of > client-side software should be cognizant of bad actors who might seek > to compromise their software. That's certainly something to keep in mind, but not something that can be solved by the protocol. It's also not specific to ACME clients, the same concern applies to any software that touches keys in the course of normal operation. FWIW, functional ACME client implementations can be written in < 200 LOC, which would be relatively easy to review, and a client would not necessarily need access to the private key of your certificate - a CSR would be sufficient. [1]: https://www.ietf.org/mailman/listinfo/acme [2]: https://mailarchive.ietf.org/arch/msg/acme/9HX2i0oGyIPuE-nZYAkTTYXhqnk | ||||
_______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
