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

From: Kathleen Moriarty <[email-masked]>
Date: Mon, 2 Oct 2017 17:03:57 -0400

Hello,

Is there any chance we'll get through this review so I can start last
call this week?  In order to have it on the last telechat before
Singapore, we'd need to have an update ready for me to start last
call.  Thanks to those who gave feedback on my DV cert questions.

Thanks,
Kathleen

On Fri, Sep 22, 2017 at 6:03 PM, Kathleen Moriarty
<[email-masked]> wrote:
> 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,
>>>
>>> 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
>>>
>>> _______________________________________________
>>> Acme mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/acme
>>
>>
>> _______________________________________________
>> Acme mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/acme

-- 

Best regards,
Kathleen

---

From: Mary Barnes <[email-masked]>
Date: Mon, 2 Oct 2017 17:40:32 -0500

It's not so much an offline process as it is an out-of-band process from
ACME  for the ACME client to get the Service Provider code token that it
uses for the challenge.  But, perhaps what you're asking for is a statement
in the intro that talks about DV certificates being most common?     The
primary difference between how we use ACME is the identifier validation,
where for SHAKEN it's the Service Provider Code token.

Regards,
Mary.

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

>> 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,
>>>

---

From: Daniel McCarney <[email-masked]>
Date: Tue, 3 Oct 2017 10:15:17 -0400

> call this week?

I think it is premature to start last-call.

There are *no* full implementations of the current draft (as far as I am
aware) and experience from attempting a complete implementation has
highlighted a problem[0] that will require protocol adjustment.

[0] - https://mailarchive.ietf.org/arch/msg/acme/DIjJEB06J5cFyuOlGPVcY2I51vg

On Mon, Oct 2, 2017 at 5:03 PM, Kathleen Moriarty <
[email-masked]> wrote:

> using-tokens-shaken-governance-model-certificate-management-atis-1000080/?
> wpdmdl=3360
> >>
> >> Regards,
> >> Mary.
> >>

---

From: Richard Barnes <[email-masked]>
Date: Thu, 19 Oct 2017 12:45:34 -0400

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.

>    and infrastructural software to obtain certificates without user

As others have pointed out, ACME is not just about DV.  PR has some
clarification on this point.

>    much of the time-consuming work described in the previous section.

Done.

> thing, so using that is fine.

Updated reference.

> managing DV certificates/

Given the discussion about DV, I don't think this change is appropriate.

> reading this to make their lives easier with cert

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.

> turing off unnecessary services.

Added a brief note.

> shared from whois though, although I don’t think that’s widely

This is a policy question, not one for the issuance protocol.

--Richard

---

From: Kathleen Moriarty <[email-masked]>
Date: Mon, 30 Oct 2017 17:00:22 -0400

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-masked]> wrote:
> Hi Kathleen,
>
> Thanks for the review.  Some responses inline.  I've started a PR to respond
> to these comments here:
>
> 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

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 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).
>
> 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

-- 

Best regards,
Kathleen

---

From: Richard Barnes <[email-masked]>
Date: Mon, 30 Oct 2017 18:27:25 -0400

On Mon, Oct 30, 2017 at 5:00 PM, Kathleen Moriarty <
[email-masked]> wrote:

> addressed

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"?

> for
> are

Draft PR here:

https://github.com/ietf-wg-acme/acme/pull/348

--Richard

---

From: Kathleen Moriarty <[email-masked]>
Date: Mon, 30 Oct 2017 21:37:24 -0400

Hi Richard,

On Mon, Oct 30, 2017 at 6:27 PM, Richard Barnes <[email-masked]> wrote:
>
>
> On Mon, Oct 30, 2017 at 5:00 PM, Kathleen Moriarty

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.

Thanks,
Kathleen

-- 

Best regards,
Kathleen

---

From: Richard Barnes <[email-masked]>
Date: Tue, 31 Oct 2017 15:51:51 -0400

> 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:

+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

> >> > ACME.  How you use the certificates you get from ACME is your
> business,
> >> > and

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 31 Oct 2017 13:39:30 -0700

> But I'm fine clarifying that certain things (like EV validation) have not

You mean "automated", right?

>> >> > indeed, several of the envisioned applications have nothing to do
>> with
>> >> > TLS

---

From: Richard Barnes <[email-masked]>
Date: Tue, 31 Oct 2017 19:09:55 -0400

On Tue, Oct 31, 2017 at 4:39 PM, Eric Rescorla <[email-masked]> wrote:

>> 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

Yep.  PR is correct.