Subject: Re: [Acme] draft-ietf-acme-star

From: Thomas Fossati <[email-masked]>
Date: Mon, 9 Sep 2019 08:15:35 +0000

Hi Richard,

Thank you for the detailed review. As you note yourself, this is quite
late in the document life-cycle (the draft completed IETF LC over a
month ago), which is unfortunate, given that every one of your comments
is an actual protocol change. As far as we understand, none of them can
be seen as a "showstopper" mistake in the protocol, and therefore we
propose to move forward with the current draft version. Please let us
know if we missed anything.

Cheers, Thomas (on behalf of the authors)

> On 28/08/2019 at 15:52, Richard Barnes <[email-masked]> wrote:
>
> I had a chance to take a look at this draft as a result of being a
> designated expert on the registries.  I approved the registrations,
> but independently, I have several major concerns about the draft.  In
> no particular order
>
> - The use of the "STAR" acronym is not helpful.  This is not an
> acronym that will be familiar to a reader, and less so an implementer
> who has not fully read and absorbed this spec.  Instead, you should
> say what you mean, e.g., for the "meta" fields:
>
> star-enabled -> auto-renewal-allowed star-min-cert-validity ->
> min-cert-validity star-max-renewal -> max-auto-renewals
>
> - Likewise, "recurrent" is not a common word in English.  If you want
> to use a single word, "recurring" is more common, but referring to
> "auto-renewal" would be even better.
>
> - It would be even cleaner to group all these "recurrent" fields into
> a sub-object, so that you wouldn't have to worry about them being
> present if "recurrent" wasn't set.  In other words, just signal the
> "recurrent" boolean by the presence of the object, and specify the
> parameters in the object.
>
> { "auto-renew": { "start": ..., "end": ..., "lifetime": ..., } }
>
> - The idea of "predating" is toxic.  Pre-dating a certificate means
> making the notBefore date earlier than when you actually issued it,
> which is a huge problem for a real CA to do.  That's not what you mean
> here..  You just want there to be some overlap between certificates.
> Say that instead ("recurrent-certificate-predate" -> "overlap") and
> adjust Section 3.5 accordingly.
>
> - The Not-Before and Not-After headers should be removed.  On the one
> hand, it's not clear to me that it's any easier to parse these headers
> than it is to parse the certificate.  On the other hand, there are
> existing HTTP headers that express almost exactly the same semantics,
> e.g., Expires.
>
> - It's not clear that there's any reason to negotiate certificate-GET
> on a per-order basis.  Just have the CA allow it or not unilaterally
> and delete the "recurrent-certificate-get" field.
>
> - The "star-certificate" attribute is unnecessary.  Instead, you
> should just say that when auto-renewal is enabled, the "certificate"
> attribute points to the current certificate, and use "previous" link
> relations to expose earlier certs.

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

---

From: Richard Barnes <[email-masked]>
Date: Mon, 9 Sep 2019 18:43:35 -0400

On Mon, Sep 9, 2019 at 4:15 AM Thomas Fossati <[email-masked]>
wrote:

> is an actual protocol change.

Do you have any implementations that this would break?  Or is this just
avoiding spec changes?

Most of the below should be pretty easy to address, so unless there's some
massively deployed code base that's going to be broken, I would propose
that they should be addressed before publication.

Note that there are some potential deployment blockers here, most
importantly the implication that the CA should pre-date certificates.

--Richard

> As far as we understand, none of them can
> IMPORTANT NOTICE: The contents of this email and any attachments are
> confidential and may also be privileged. If you are not the intended
> recipient, please notify the sender immediately and do not disclose the
> contents to any other person, use it for any purpose, or store or copy the
> information in any medium. Thank you.
>

---

From: "Salz, Rich" <[email-masked]>
Date: Mon, 9 Sep 2019 22:57:46 +0000

I don’t care about the STAR acronym not bring known by those who don’t know :) but I think Richard’s comments – most of which are, really, wordsmithing nits of message-field names – deserve more consideration.  After all, the STAR documents didn’t get much attention from the ACME members.

From: Richard Barnes <[email-masked]>
Date: Monday, September 9, 2019 at 6:44 PM
To: Thomas Fossati <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [Acme] draft-ietf-acme-star

On Mon, Sep 9, 2019 at 4:15 AM Thomas Fossati <[email-masked]<mailto:[email-masked]>> wrote:
Hi Richard,

Do you have any implementations that this would break?  Or is this just avoiding spec changes?

Most of the below should be pretty easy to address, so unless there's some massively deployed code base that's going to be broken, I would propose that they should be addressed before publication.

Note that there are some potential deployment blockers here, most importantly the implication that the CA should pre-date certificates.

--Richard

> { "auto-renew": { "start": ..., "end": ...., "lifetime": ..., } }
>

---

From: Thomas Fossati <[email-masked]>
Date: Wed, 11 Sep 2019 16:08:53 +0000

Hi Rich, Richard,

(Merging both your emails into one reply.)

On 09/09/2019, 23:57, "Salz, Rich" <[email-masked]> wrote:
> I don't care about the STAR acronym not bring known by those who don't
> know :) but I think Richard's comments – most of which are, really,
> wordsmithing nits of message-field names – deserve more consideration.
> After all, the STAR documents didn't get much attention from the ACME
> members.

Sure, high quality feedback is always welcome.  Our worry was that
making such changes after the doc has been through IETF LC and a couple
of AD reviews means that very few people will get to double-check that
the protocol is still correct/consistent.  But, let's be bold as it's
probably worth taking the risk :-)

Now addressing Richard's comments:

> star-enabled -> auto-renewal-allowed
> star-min-cert-validity -> min-cert-validity
> star-max-renewal -> max-auto-renewals

OK, will do.

> "auto-renewal" would be even better.

OK, will do.

> { "auto-renew": { "start": ..., "end": ..., "lifetime": ..., } }

OK, will do.

> adjust Section 3.5 accordingly.

There are two aspects to consider:

1 The recommendation we added in section 4.1 to address the clock skew
  impact on HTTPS (cfr. the cited Google paper), which was discussed at
  length during the STAR side-meeting in Singapore.  This bit is
  controlled by the ACME client (via recurrent-certificate-predate) who
  might optionally ask the ACME CA to pre-date all the certs by a
  certain amount if it knows it's client population is clock-skewed
  (this is probably the "toxic" bit you are referring to?)

2 The pre-dating that the ACME server MUST do on cert rotation to
  prevent the client to fetch a not-yet-valid credential (i.e., the
  overlap you mention).

IIUC, you are suggesting to drop the former, i.e., removing the ability
for a client to request recurrent-certificate-predate, correct?  Or are
you suggesting to only remove the RECOMMENDED from section 4.1?

> existing HTTP headers that express almost exactly the same semantics,

Expires is not completely unrelated (in fact, your observation had me
thinking that we should probably discuss the operational impact of HTTP
caches on STAR cert resources) but I'm not sure it really has compatible
semantics -- it's a signal for the caching / validation layer of the
HTTP protocol rather than an intrinsic property of the resource.  OTOH,
looking at already registered HTTP headers we couldn't find anything
suitable.  So I think the only choices we are left with are to either
remove the headers altogether or keep them as they currently are.

> and delete the "recurrent-certificate-get" field.

The client decides whether it wants to use the GET interface (e.g., if
STAR is part of a delegation workflow) or not (i.e., STAR is used for
plain auto renewal.)  It's not up to the server to decide which workflow
the client is interested in.

> relations to expose earlier certs.

The idea behind the "star-certificate" attribute was to mark the fact
that the underlying resource is of a different kind.  More specifically,
it's not immutable as opposed to that in a non-STAR Order.  ACME Section
7.4.2 has:

   "A certificate resource represents a single, immutable certificate."

(BTW, I guess a "previous" link can - and should - be used
irrespectively of how the Order attribute is called.)

Cheers, thanks both for the input!

---

From: Ryan Sleevi <[email-masked]>
Date: Wed, 11 Sep 2019 12:52:30 -0400

> you suggesting to only remove the RECOMMENDED from section 4.1?

I'm not Richard, but with respect to publicly trusted certificates, issuing
a certificate with a notBefore set prior to that certificate was issued is
seen as, minimally, problematic, and at times has resulted in a complete
removal of trust in that CA, particularly if/when such actions have lead to
bypasses of technical controls enforced based upon the notBefore.

The clock skew problem is, admittedly, real, and the general solution as
practiced by industry-recognized CAs and Subscribers is to generate the
request and issue the certificate in advance of its actual deployment,
rather than to issue the certificate and then back-date it to facilitate
deployment.

To that end, the language about "amount of pre-dating added to each STAR
certificate" (in 3.1.1) is, as Richard highlighted, about the overlap that
exists.
The language in Section 4.1, however, should be clarified to be clear that
the CA/ACME server MUST NOT set the notBefore to before the request, but
instead about ensuring that the STAR client requests the 'next certificate'
in advance of the actual deployment. This may substantially alter the
protocol, it's unclear, but it's extremely unwise, if not outright fatal to
interoperability, to issue a certificate with a notBefore set prior to the
request, and it seems that is what is meant by Section 4.1.

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 11 Sep 2019 17:39:55 +0000

We can ask that the IESG/IETF do a simultaneous re-review period of something like two weeks.

Thanks.

---

From: Thomas Fossati <[email-masked]>
Date: Thu, 12 Sep 2019 11:37:41 +0000

On 11/09/2019, 18:40, "Salz, Rich" <[email-masked]> wrote:
> > the protocol is still correct/consistent.  But, let's be bold as
> > it's probably worth taking the risk :-)
>

Sounds good, thank you.

---

From: Roman Danyliw <[email-masked]>
Date: Thu, 12 Sep 2019 13:56:54 +0000

Hi!

> -----Original Message-----
> From: Acme [mailto:[email-masked]] On Behalf Of Thomas Fossati
> Sent: Thursday, September 12, 2019 7:38 AM
> To: Salz, Rich <[email-masked]>; Richard Barnes <[email-masked]>
> Cc: IETF ACME <[email-masked]>; Thomas Fossati
> <[email-masked]>

I concur with the spirit of the thinking here.  However, "IETF re-review" and IESG review are distinct activities that should not run in parallel.  If we want to conduct another IETF LC, no problem -- also consider another WGLC if appropriate.  However, all of these reviews should conclude before bringing it to the IESG for review.  By the time it gets to the IESG, the WG should have consensus and the broader community should have had their chance to review and resolve issues as well.

Roman

---

From: Thomas Fossati <[email-masked]>
Date: Fri, 13 Sep 2019 12:41:33 +0000

Thanks Richard for raising this and Ryan for taking the time to explain.

On 11/09/2019, 17:52, "Ryan Sleevi" <[email-masked]> wrote:
> I'm not Richard, but with respect to publicly trusted certificates,
> issuing a certificate with a notBefore set prior to that certificate
> was issued is seen as, minimally, problematic, and at times has
> resulted in a complete removal of trust in that CA, particularly
> if/when such actions have lead to bypasses of technical controls
> enforced based upon the notBefore.
>
>
> The clock skew problem is, admittedly, real, and the general solution
> as practiced by industry-recognized CAs and Subscribers is to generate
> the request and issue the certificate in advance of its actual
> deployment, rather than to issue the certificate and then back-date it
> to facilitate deployment.
>
>
> To that end, the language about "amount of pre-dating added to each
> STAR certificate" (in 3.1.1) is, as Richard highlighted, about the
> overlap that exists.  The language in Section 4.1, however, should be
> clarified to be clear that the CA/ACME server MUST NOT set the
> notBefore to before the request, but instead about ensuring that the
> STAR client requests the 'next certificate' in advance of the actual
> deployment.  This may substantially alter the protocol, it's unclear,
> but it's extremely unwise, if not outright fatal to interoperability,
> to issue a certificate with a notBefore set prior to the request, and
> it seems that is what is meant by Section 4.1.

OK, this adds a new constraint ("no back-dating") that we hadn't
factored in the initial design, and I agree this is a blocker.

I think the question is whether and how can we accommodate this
constraint with the ability to work around clock-skew -- IOW, keeping
recurrent-certificate-predate (*) while not messing up CA's cert
issuance best practices.

It seems to me that this might still be possible modulo
recurrent-certificate-adjust (rcp) being upper bounded by
recurrent-cert-validity (rcv), i.e., slightly changing the calculations
in 3.5 like this:

     notBefore = nrd[i] - predating
     notAfter  = min(nrd[i] + rcv, red)

     predating = max(predating_S, predating_C)
     predating_S = f * rcv (.5 <= f < 1)
     predating_C = max(rcp, rcv)

This should still leave a fair amount of knobs to ACME clients (rcp and
rcv) to play with their clock-skewed customers.

Would that work for you?

The (brutal) alternative is to get rid of recurrent-certificate-predate,
but removing the ability to address (at least partially) the clock skew
problem looks like a missed opportunity.

Anyway, whatever road we take, it looks like there's a bit of editorial
work to do in sections 3.1.1, 3.3, 3.5 and 4.1.

Cheers, t

(*) We'll rename it to "recurrent-certificate-adjust".

---

From: Thomas Fossati <[email-masked]>
Date: Fri, 13 Sep 2019 17:28:25 +0000

>      predating_C = max(rcp, rcv)
                     ^^^
typo:                min