[cabf_validation] Designated Authorization Domain Label (method F) write-up

Tue Apr 24 08:28:32 MST 2018

On Tue, Apr 24, 2018 at 9:25 AM, Corey Bonnell via Validation <
validation at cabforum.org> wrote:

> I wrote up a preliminary “ballot text” for Method F (using a subdomain to
> function as an Authorization Domain Name for a FQDN) as defined in the
> Validation Summit Findings document.
>
>
>
> Since this proposed change increases the number of ADNs, I believe that
> explicit opt-in is required so that the ecosystem is not negatively
> affected if this method is allowed. The mechanism chosen is a DNS TXT
> record with a specific syntax for the RDATA value. Using DNS TXT over
> another record type has three advantages:
>
>    1. There is precedent for this syntax, as DKIM and SPF records use a
>    very similar syntax.
>    2. TXT is a universally supported record type, unlike other
>    alternatives.
>    3. TXT has an advantage over CAA in that the presence of TXT records
>    at a specific Domain Name does not halt CAA tree-climbing and does not
>    invert the CAA restriction model. The current CAA tree-climbing logic
>    indicates that tree-climbing for records stops upon encountering a
>    non-empty CAA record set. This means that, if in the course of CAA
>    processing, a non-empty CAA record set is encountered that contains only
>    property tags which signal allowed domain validation methods but otherwise
>    does not contain any issue/issuewild records which restrict the set of CAs
>    that are allowed to issue, then any CA can issue for that domain. If the
>    domain owner wishes to both restrict domain validation methods AND restrict
>    the set of allowed CAs, they must repeat these records at every subdomain
>    that may be used as an ADN if any CAA record differs from the CAA records
>    at a parent Domain Name. In addition, the CAA tree-climbing process (which
>    starts at the most specific Domain Name) is the inverse of ADN processing
>    (where authorization is top-down), creating an impedance mismatch that is
>    both difficult to comprehend and is error-prone for domain owners. As such,
>    TXT records were selected as the preferred mechanism to opt-in for Method F.
>
>
>
> This proposed method allows domain owners to create a special TXT record
> at a FQDN to signal that a specific subdomain (called the “DADL”, or
> “Designated Authorization Domain Label”) is allowed to be an Authorization
> Domain Name of the FQDN.
>
>
>
> Assume a domain owner owns “example.com”. For operational reasons, they
> cannot use any of the accepted domain validation methods directly against “
> example.com”, but they can provision a web server at “_
> pki-validation.example.com” to perform domain validation. As such, they
> create a TXT record at “example.com” to designate “_pki-validation” as
> the DADL for “example.com”:
>
> example.com. IN TXT “v=DADL1; l=_pki-validation”
>
>
>
> There is an initial overhead in creating the TXT record at example.com,
> but moving forward the domain owner can use the _pki-validation subdomain
> for domain validation.
>
>
>
> There is also support for DADLs at aliases. Assume that “
> example.thecdn.com” is an alias for “example.com”. If the domain owner
> for “example.com” wishes to use “_pki-validation.example.thecdn.com” as
> the ADN, they can create the following TXT record at “example.thecdn.com”:
>
> example.thecdn.com. IN TXT “v=DADL1; l=_pki-validation”
>
>
>
> Note that the current algorithm I have below does not permit the DADL to
> itself have an alias. This was done to keep the number of ADNs reasonable,
> but we may determine that allowing aliases in this case is desirable.
>
>
>
> Also, method 7 (DNS change) allows for an arbitrary subdomain which starts
> with an underscore to function as the ADN for a given FQDN. This means that
> in combination with the DADL, a sub-sub-domain of the FQDN can be allowed
> as the ADN. This has undesirable security properties, so I imagine we’d
> want to restrict that. However, I don’t address this situation, as we
> discussed restricting method 7 at the Validation Summit. I can modify this
> ballot text when we determine what to do about method 7.
>
>
>
> Without further ado:
>
>
>
> Modify the following to BR 1.6.1 Definition:
>
>
>
> *Authorization Domain Name: *The Domain Name used to obtain authorization
> for certificate issuance for a given FQDN, which is determined using the
> following algorithm:
>
> Let PARENT(X) be the parent Domain Name of X. The parent Domain Name is
> determined by removing the leftmost label of X.
>
>             Let NOWILD(X) be PARENT(X) if X starts with “*.” (Unicode
> U+002A ASTERISK and U+002E FULL STOP). If X does not start with “*.”, then
> NOWILD(X) is X.
>
>             Let ALIAS(X) be the target of DNS alias chasing at X. If there
> is no alias for X, then ALIAS(X) is NIL.
>
>             Let DADL(X) be the result of performing the following
> algorithm:
>
>    1. Perform a DNS TXT lookup at X.
>    2. For each TXT record in the retrieved Resource Record Set from step
>    1, check that the record’s RDATA string matches the following ABNF grammar
>    (as per RFC 5234):
>
> rdata = “v=DADL1;” *WSP “l=” label [“;”]
>
> label = “_” (ALPHA / DIGIT) *( *"-" (ALPHA / DIGIT))
>
>    1. If there is a match found in step 2, then DADL(X) is the
>    concatenation of the “label” value, Unicode U+002E FULL STOP character
>    (“.”), and X. If there is no such match for any retrieved TXT records, then
>    DADL(X) is NIL.
>
>
>
>    1. Let X be the FQDN to be validated.
>    2. Let X’ be the result of NOWILD(X).
>    3. Add X’ to the set of candidate Domain Names.
>    4. Let A be the result of ALIAS(X’).
>       1. If A is not NIL, then:
>
>
> i.       Add A to the set of candidate Domain Names.
>
>
> ii.      If DADL(A) is not NIL, then add DADL(A) to the set of candidate
> Domain Names.
>
>    1. If A is NIL and DADL(X’) is not NIL, then add DADL(X’) to the set
>       of candidate Domain Names.
>    1. If X’ is not a Base Domain Name, then repeat steps 3-5 with
>    PARENT(X’) as X’.
>    2. Select a Domain Name from the set of candidate Domain Names.
>
>
Like Tim, I have a number of concerns.

1) I do not support this normative redefinition of "Authorization Domain
Name". I do not think algorithms like this belong in a Definitions section,
and more work should be done to better normatively specify that.
2) I'm hoping you can actually document a more compelling case to allow
arbitrary definition (and the complexity it entails) versus the existing
methods that exist - such as CNAME.
3) I'm not overly keen on the specialization of the TXT record, as already
mentioned. I'm sure simply floating this proposal to the DNSOP WG in the
IETF can highlight the possible issues this can bring. For example, the
syntax overlap can be a significant detriment through cross-protocol
attacks on different semantic interpretations of the record
4) I'm not sure I understand Tim's comment re: directionality - both this
and CAA walk bottom-up
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/validation/attachments/20180424/ddb2732c/attachment-0001.html>