Subject: Re: [Acme] Benjamin Kaduk's Discuss on draft-ietf-acme-caa-07: (with DISCUSS and COMMENT)

From: Hugo Landau <[email-masked]>
Date: Thu, 6 Jun 2019 07:52:33 +0100

Sorry, I somehow missed this one.

> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
> 
> I think we need to have some privacy considerations text about how this
> mechanism exposes ACME account URLs, which are otherwise intended to be
> unguessable, in the public DNS view.  While ACME is generally intended
> to remain secure in the face of such information disclosure, it does
> have potential to enable some forms of correlation attacks, and could
> lead to DoS attempts specific to a given account or accounts.
I agree. How's this?

    Revelation of Account URIs
    --------------------------

    Because CAA records are publically accessible, use of the
    "accounturi" parameter enables third parties to observe the
    authorized account URIs for a domain. This may allow third parties
    to identify a correlation between domains if those domains use the
    same account URIs.

    CAs MUST select and process account URIs under the assumption that
    untrusted third parties may learn of them.

> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> I support Barry's Discusses (noting in particular that the "ca-" prefix is
> not reserved for local use by RFC 8555).
> 
> Did we consider supplying ABNF descriptions of the parameter values?  In
> particular, this would unambiguously specify whether optional whitespace
> is admitted in the comma-separated list used by "validationmethods".
I don't believe this was considered, but it seems like an improvement.
How's this?

    The value of the "validationmethods" parameter MUST comply with the
    following ABNF {{RFC5234}}:

        value = [*(label ",") label]
        label = 1*(ALPHA / DIGIT / "-")

> The shepherd writeup notes that there used to be hyphens in
> "account-uri" and "accepted-challenges".  It seems that rfc6844bis has
> expanded the grammar to allow such hyphens; do we want to revisit their
> removal from this document?  Noting that rfc6844bis is also slated for
> approval on this week's telechat, it may be worth updating the
> references as well, regardless of the decision on hyphens.
I agree we should change this to rfc6844bis, done.

I'm neutral on reintroducing hyphens. I don't think it's worth doing,
since there is now an implementation out there:

<https://community.letsencrypt.org/t/acme-caa-validationmethods-support/63125>

> Section 3
> 
>    The presence of this parameter constrains the property to which it is
>    attached.  Where a CAA property has an "accounturi" parameter, a CA
>    MUST only consider that property to authorize issuance in the context
>    of a given certificate issuance request if the CA recognises the URI
>    specified as identifying the account making that request.
> 
> nit: perhaps "URI specified in the value portion of the accounturi
> parameter" for maximum clarity?

Changed to:
    The presence of this parameter constrains the property to which it
    is attached. Where a CAA property has an "accounturi" parameter, a
    CA MUST only consider that property to authorize issuance in the
    context of a given certificate issuance request if the CA recognises
    the URI specified in the value portion of that parameter as
    identifying the account making that request.

> 
> Section 4
> 
>    The presence of this parameter constrains the property to which it is
>    attached.  A CA MUST only consider a property with the
>    "validationmethods" parameter to authorize issuance where the name of
>    the challenge method being used is one of the names listed in the
>    comma-separated list.
> 
> nit: I'm not sure that we've really defined "challenge method" in the
> sense it's used here.  (We do define it in the sense of "names listed in
> the comma-separated list", but it seems like this usage is trying to
> refer to the actual actions taken by the CA to authorize the issuance
> request.
s/challenge/validation/ -- consistency.
s/name/label/ -- consistency with the ACME Validation Methods IANA
registry.

Revised this a little to make things more watertight.
The text of this section is now:

    A CAA parameter "validationmethods" is also defined for the "issue"
    and "issuewild" properties. The value of this parameter, if
    specified, MUST be a comma-separated string of validation method
    labels.

    A validation method label identifies a validation method. A
    validation method is a particular way in which a CA can validate
    control over a domain.

    The presence of this parameter constrains the property to which it
    is attached. A CA MUST only consider a property with the
    "validationmethods" parameter to authorize issuance where the
    validation method being used is identified by one of the validation
    method labels listed in the comma-separated list.

    Each validation method label MUST be either the label of a method
    defined in the ACME Validation Methods IANA registry, or a
    CA-specific non-ACME validation method label as defined below.

    Where a CA supports both the "validationmethods" parameter and one
    or more non-ACME validation methods, it MUST assign labels to those
    methods. If appropriate non-ACME labels are not present in the ACME
    Validation Methods IANA registry, the CA MUST use labels beginning
    with the string "ca-", which are defined to have CA-specific
    meaning.

    The value of the "validationmethods" parameter MUST comply with the
    following ABNF {{RFC5234}}:

        value = [*(label ",") label]
        label = 1*(ALPHA / DIGIT / "-")

> 
> Section 5.2
> 
> I think this section may be predicated on an understanding of CAA
> "issue"/"issuewild" parameters that does not match my own.  (Note that
> this includes the possibility that my understanding is incorrect.)
> Specifically, my reading of draft-ietf-lamps-rfc6844bis-06 Section 4.2
> indicates that a given paramter is only defined for usage in a CAA
> "issue" record at the explicit specification of the Issuer, and that the
> Issuer alone determines their semantics.  So when this text says that
> parameters are not an effective control absent out-of-band establishment
> of support, that's either a non sequitur or a tautology -- nobody has
> any business adding parameters to an Issuer's CAA entry unless that
> Issuer has told them to do so, full stop.
> Granted, we are complicating things by providing a preestablished
> specification for a set of parameters that an Issuer may choose to
> incorporate by reference, but I don't see that as changing the fact that
> the parameters are still specific to the given Issuer (and their CAA
> entry).
> Similarly, "MUST NOT assume" and "SHOULD also document" are repeating
> requirements from rfc6844bis, when starting from my frame of reference
> (and thus would not need to use the normative capitalization).
I agree with your interpretation, and this interpretation is in fact
explicitly stated in the IANA considerations section — but I don't think
how this is worded currently is a problem.

I mean, it's the security considerations section — it's not just there
to add more normative requirements, but to point out ways you could
shoot yourself in the foot. We need to spell it out for people.

> Section 5.7
> 
> This seems perhaps more appropriate in the core CAA specification than
> in this document.  Conveniently, rfc6844bis is open and in IESG
> evaluation...
I've changed to rfc6844bis, but I don't think it's worth removing this.
It was added on request, and applying more security properties to CAA is
a good opportunity to remind people of this subtlety.

---

From: Tim Hollebeek <[email-masked]>
Date: Tue, 11 Jun 2019 04:30:34 +0000

>     untrusted third parties may learn of them.

That's not really an actionable requirement, is it?

-Tim

---

From: Benjamin Kaduk <[email-masked]>
Date: Thu, 13 Jun 2019 19:11:06 -0500

>     Revelation of Account URIs

This sounds good.

>     untrusted third parties may learn of them.

As Tim notes, this isn't really an actionable MUST, so we probably should
just go with "are encouraged to".

>         label = 1*(ALPHA / DIGIT / "-")

That looks okay to my eye, but let's see if we can get an ART AD to look at
it, as well -- I'm only an amateur at ABNF.

> <https://community.letsencrypt.org/t/acme-caa-validationmethods-support/63125>

Sure.  There's not really a compelling reason to reintroduce them, strange
mispronounciations of "accounturi" aside :)

>     identifying the account making that request.

Thanks!

> how this is worded currently is a problem.

This is a non-blocking comment, so it's entirely your call.  If you wanted
a concrete suggestion from me, I'd probably consider a minimal change like
adding a new sentence at the start and tweaking the transition: "CAA
records are inherently an indicator of an agreement between a domain owner
and one or more CAs, so inserting CAA records into the DNS without
cooperation from a CA is not expected to have any effect.  Accordingly, the
CAA parameters specified in this section rely on [...]".  But I just wrote
that on the fly and will not be surpirsed if it is unsatisfactory :)

> shoot yourself in the foot. We need to spell it out for people.

Indeed.

> a good opportunity to remind people of this subtlety.

Works for me.

Thanks for the updates!

-Ben

---

From: Hugo Landau <[email-masked]>
Date: Sat, 15 Jun 2019 15:56:11 +0100

> just go with "are encouraged to".
Done.

> it, as well -- I'm only an amateur at ABNF.
Sounds good, putting this in for now.

> adding a new sentence at the start and tweaking the transition:

> "CAA
I don't want the document to assume some sort of legal/contractual
relationship, so I decided to go with this:

  Because the parameters of "issue" or "issuewild" CAA properties
  constitute a CA-specific namespace, the CA identified by an "issue" or
  "issuewild" property decides what parameters to recognise and their
  semantics. Accordingly, the CAA parameters defined in this
  specification rely on their being recognised by the CA named by an
  "issue" or "issuewild" CAA property, and are not an effective means of
  control over issuance unless a CA's support for the parameters is
  established beforehand.