Subject: [Acme] AD review of draft-ietf-acme-acme

From: Kathleen Moriarty <[email-masked]>
Date: Fri, 22 Sep 2017 16:14:51 -0400

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.

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.

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.

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/

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.

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.

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.

-- 

Best regards,
Kathleen

---

From: Mary Barnes <[email-masked]>
Date: Fri, 22 Sep 2017 15:51:28 -0500

Just to throw in my 1/2 cent.  We are using ACME for non-DV certificates in
the ATIS/SIP Forum SHAKEN framework as detailed in ATIS-1000080:
https://www.sipforum.org/download/joint-atissip-forum-standard-signature-based-handling-asserted-information-using-tokens-shaken-governance-model-certificate-management-atis-1000080/?wpdmdl=3360

Regards,
Mary.

On Fri, Sep 22, 2017 at 3:14 PM, Kathleen Moriarty <
[email-masked]> wrote:

> _______________________________________________
> Acme mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/acme
>

---

From: Clint Wilson <[email-masked]>
Date: Fri, 22 Sep 2017 21:33:39 +0000

An additional 1/2 cent from me; we intend to use ACME primarily, if not
solely, with non-DV certs.

On Fri, Sep 22, 2017, 2:51 PM Mary Barnes <[email-masked]>
wrote:

> Just to throw in my 1/2 cent.  We are using ACME for non-DV certificates
> in the ATIS/SIP Forum SHAKEN framework as detailed in ATIS-1000080:

---

From: Kathleen Moriarty <[email-masked]>
Date: Fri, 22 Sep 2017 18:03:40 -0400

Thanks for the input and the offline message, Mary.  An offline process is needed from what I can tell to use ACME for anything considered a higher assurance than a DV cert, is that right?  If so, I think it's important to make that clear with a simple sentence.

Thank you,
Kathleen 

Sent from my iPhone

> On Sep 22, 2017, at 5:33 PM, Clint Wilson <[email-masked]> wrote:
> 
> An additional 1/2 cent from me; we intend to use ACME primarily, if not solely, with non-DV certs.
> 
> 
>> On Fri, Sep 22, 2017, 2:51 PM Mary Barnes <[email-masked]> wrote:
>> Just to throw in my 1/2 cent.  We are using ACME for non-DV certificates in the ATIS/SIP Forum SHAKEN framework as detailed in ATIS-1000080:  https://www.sipforum.org/download/joint-atissip-forum-standard-signature-based-handling-asserted-information-using-tokens-shaken-governance-model-certificate-management-atis-1000080/?wpdmdl=3360
>> 
>> Regards,
>> Mary.
>> 
>>> On Fri, Sep 22, 2017 at 3:14 PM, Kathleen Moriarty <[email-masked]> wrote:
>>> Hello,
>>>