On Tue, Oct 31, 2017 at 4:39 PM, Eric Rescorla <[email protected]> wrote:
> > > On Tue, Oct 31, 2017 at 12:51 PM, Richard Barnes <[email protected]> wrote: > >> >> >> On Mon, Oct 30, 2017 at 9:37 PM, Kathleen Moriarty < >> [email protected]> wrote: >> >>> Hi Richard, >>> >>> On Mon, Oct 30, 2017 at 6:27 PM, Richard Barnes <[email protected]> wrote: >>> > >>> > >>> > On Mon, Oct 30, 2017 at 5:00 PM, Kathleen Moriarty >>> > <[email protected]> wrote: >>> >> >>> >> 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 don't think you're missing anything. What do you mean by >>> "certificate >>> > types and out-of-band processes"? How is that different from "other >>> PKI >>> > contexts"? >>> >>> I think by PKI-context, you mean the application of use, is that >>> right? I am separating out the type of certificate (DV, EV, etc.) as >>> you have done in the second paragraph of the introduction. When >>> reading the rest of the document, there isn't text that says what type >>> of certificate ACME produces without any additional processes >>> (out-of-band authentication/validation). If you think about >>> administrators who operate servers (whatever the protocol) or even >>> those who may wish to incorporate ACME into a new application, they >>> will may have to figure out what level ACME provides as a default and >>> also know that there can be additional processes added to obtain >>> certificates types at a higher assurance level using ACME. Since the >>> text already does a nice job of explaining the certificate types, this >>> should be an easy follow up that I think will be very helpful to >>> people outside of the IETF or who look at this in the future. >>> >>> Maybe something like the following: >>> >>> Strictly following the automation enabled by ACME, DV certificates >>> are issued. >>> Additional processes can be provided by the CA to increase the level >>> of >>> validation on an end entity to issue certificates at a higher >>> assurance level, >>> for instance an EV certificate. <Then maybe provide a reference to >>> the STIR >>> example Mary mentioned in this thread.> >>> >>> Does that help? Thinking about this in former roles and having been >>> to some conferences lately, I think being explicit about this will >>> help those trying to evaluate and deploy ACME. They may look for >>> providers who meet the assurance levels they need knowing there are >>> options and understanding the baseline provided by this spec. >>> >> >> >> It's wrong to frame this as being about assurance levels -- you seem to >> be presuming that manual processes can give higher assurance than automated >> ones, a fact which I think has been repeatedly proven false in the web >> PKI. >> >> But I'm fine clarifying that certain things (like EV validation) have not >> yet been audited: >> > > You mean "automated", right? > Yep. PR is correct. > > > >> >> +ACME can also be used to automate some aspects of certificate management >> even >> +where non-automated processes are still needed. For example, the >> external >> +account binding feature (see {{external-account-binding}}) can be used to >> +associate authorizations with an account that were not validated through >> the >> +ACME authorization process. This allows ACME to address issuance >> scenarios that >> +cannot yet be fully automated, such as the issuance of Extended >> Validation >> +certificates. >> >> Updated PR: https://github.com/ietf-wg-acme/acme/pull/348 >> >> --Richard >> >> >> >> >>> >>> Thanks, >>> Kathleen >>> >>> >>> > >>> > >>> >> >>> >> > >>> >> > >>> >> >> >>> >> >> 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? >>> > >>> > >>> > Draft PR here: >>> > >>> > https://github.com/ietf-wg-acme/acme/pull/348 >>> > >>> > --Richard >>> > >>> > >>> >> >>> >> >>> >> 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 >>> > >>> > >>> >>> >>> >>> -- >>> >>> 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
