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

[Hugo Landau <[e-mail]>]

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.