Hi Richard, Thanks for posting the diff, I reviewed the changes and they look good, but I have a couple of questions. FYI - I had started looking at the PR, but something came up, sorry for the delay and this was a good reminder.
On Thu, Oct 19, 2017 at 12:45 PM, Richard Barnes <[email protected]> wrote: > 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 see the text on uses in other PKI contexts in the introduction, but don't see anything on the certificate types and out-of-band processes (as is the case for the STIR use case Mary mentioned). Maybe I'm missing it, can you tell me where to look? > > >> >> 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. Can you add a pointer in your text about the provided anti-replay protections in the application layer? Thanks, Kathleen > > >> >> 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 > > -- Best regards, Kathleen _______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
