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
_______________________________________________
Acme mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/acme
