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

[Benjamin Kaduk <[e-mail]>]

On Thu, Jun 06, 2019 at 07:52:33AM +0100, Hugo Landau wrote:
> 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.

This sounds good.

>     CAs MUST select and process account URIs under the assumption that
>     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".

> 
> > ----------------------------------------------------------------------
> > 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 / "-")

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.

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

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

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

Thanks!

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

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

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

Indeed.

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

Works for me.

Thanks for the updates!

-Ben