Hi Kathleen, Thanks for the review. Some responses inline. I've started a PR to respond to these comments here:
https://github.com/ietf-wg-acme/acme/pull/345 I agree with Daniel that we should hold off on IETF LC until we've addressed the issues around proactive issuance / caching of CSRs. That may require a re-WGLC, but once that's closed, it should be safe to send to IETF LC. On Fri, Sep 22, 2017 at 4:14 PM, Kathleen Moriarty < [email protected]> wrote: > Hello, > > Thank you to the editors and WG for your efforts on > draft-ietf-acme-acme, it's a well written and easy to understand > draft. I do have a few comments, that need to be address by the > editors and SHEPHERD. > > Please review the idnits. There are a few warnings that should be > correctable and can be addressed, but more importantly, it calls out > several downrefs that are not in the shepherd writeup. These need to > be in the writeup and then also mentioned in the IETF last call > announcement (I'll make sure the latter happens). > > Here's my mostly editorial comments: > > Introduction: > It reads very well, but it would be helpful to those unfamiliar with > the work to explicitly state that ACME is about DV certificates. The > first sentence of the last paragraph seems like the best place to add > this in. > Current text: > This document describes an extensible framework for automating the > issuance and domain validation procedure, thereby allowing servers > and infrastructural software to obtain certificates without user > interaction. > Proposed: > This document describes an extensible framework for automating the > issuance and domain validation procedure for DV certificates, > thereby allowing servers > and infrastructural software to obtain certificates without user > interaction. > As others have pointed out, ACME is not just about DV. PR has some clarification on this point. > I do like how the introduction is framed as it’s clear the level of > security provided by the certificates issued via ACME. Thanks for > that. > > The introduction should also make it clear that ACME can be used for > other services using DV certificates, not just HTTP. This is > mentioned in the Terminology section, but I think a clear sentence > upfront would be helpful. > > Section 2: Nit/suggestion: Change the tense to read as a published RFC > in the last paragraph, last sentence (take it or leave it). > Current: > Such close integration of ACME with HTTPS > servers would allow the immediate and automated deployment of > certificates as they are issued, sparing the human administrator from > much of the time-consuming work described in the previous section. > Proposed: > Such close integration of ACME with HTTPS > servers allows the immediate and automated deployment of > certificates as they are issued, sparing the human administrator from > much of the time-consuming work described in the previous section. > Done. > IANA Section: > Everything looks good except that RFC5226 has been obsoleted, so the > new reference is RFC8126 and “specification required” > https://tools.ietf.org/html/rfc8126#section-4.6 still means the same > thing, so using that is fine. > Updated reference. > Security considerations: > I think it would be good to mention here that they are DV certs so the > reader understands from he introduction and this section the level of > cert issued through ACME and doesn’t assume a higher level of > assurance. > > s/ACME is a protocol for managing certificates/ACME is a protocol for > managing DV certificates/ > Given the discussion about DV, I don't think this change is appropriate. > 10.1 - I know this is obvious to the people in the WG, but a reference > to RFC7525 to properly configure TLS 1.2 should be included to protect > against the mentioned attacks. If you want to also reference TLS 1.3 > and specify no 0-RTT that would be good too. It’d be great to see > this get widely deployed, so there may be a number of newcomers > reading this to make their lives easier with cert > issuance/maintenance. > I don't see how TLS configuration plays into the security considerations for ACME. How you use the certificates you get from ACME is your business, and indeed, several of the envisioned applications have nothing to do with TLS (e.g., the email and STIR use cases). That said, I have added some language to suggest that ACME servers should follow the advice in RFC 7525. 0xRTT should be safe here, because there are anti-replay protections at the application layer. > 10.2 - what if the server that the account verifier has an account on > (client for ACME) is compromised and is used to request new > certificates or perform other actions? I think this is one of the > larger risks, so mentioning this is possible and hardening measures > should be taken to prevent compromise would be prudent. Hardening > measures or appropriate security controls should be broadly understood > terms (I think) so that you wouldn’t need to list out things like > turing off unnecessary services. > Added a brief note. > 10.5 - I would think you’d see requests for new phishing domains > rather than known ones through this process. What would you look for > there as that’s a complex problem - it would be hard to know all legit > names to know if one was a play off of the original. This happened > with equifax - they provided a site name with a typo and a ‘white hat’ > attacker had set up a site that looked just like theirs at that site. > But it was announced by equifax. Tough problem as automating a check > on the DNS registration may not detect something unusual, but maybe > recommending this check could help? RDP lessens what needs to be > shared from whois though, although I don’t think that’s widely > deployed. > This is a policy question, not one for the issuance protocol. --Richard > > -- > > Best regards, > Kathleen > > _______________________________________________ > Acme mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/acme >
_______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
