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

Wed Apr 25 08:47:36 MST 2018

Hi Ryan,

Thank you for your feedback. Please see the responses to your concerns below:

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.

Inspired by the proposed Method C and D in the Validation Summit Findings document, I redefined Authorization Domain Name as it was a singular location that I could update to describe how I envisioned “Method F” to work. I agree the Definitions section is a strange place to put this algorithm, and would not be opposed to define it in another location (perhaps in Section 3.2.2.4 or the Appendix). However, for the purposes of discussion, I think the Definitions is an acceptable temporary location, as the “method” can be tweaked in one location without having to deal with churn in multiple locations of the document.

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.

I’m unsure if you’re referring to why I’m proposing “Method F” as a whole, or if you are taking issue with the DADL record’s ability to specify an arbitrary label, as opposed to mandating a specific label (such as “_pki-validation”).

If the former, on the last Validation WG call I proposed defining a single subdomain label to perform domain validation against as we were discussing Method D (see the Validation Summit Findings document Methods C and D for the rationale for why such a method is useful). Essentially, it would be similar to method 7’s allowance to use a domain label that starts with an underscore. Thinking about it further, I realized that allowing this mechanism would have a negative impact on the ecosystem as a whole (since websites that allow users to create subdomains would become vulnerable), so an opt-in mechanism is required.

If the latter, then I allow for an arbitrary DADL because this mechanism requires explicit opt-in by the domain owner, so it seems overly restrictive to both require opt-in and restrict the domain label used. However, I wouldn’t be opposed to removing the ability to specify a subdomain name and instead force the use of “_pki-validation” if that’s deemed to be preferable.

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

I agree that using TXT records is a hack, but unfortunately I do not see any other more preferable alternative with the current state of how CAA operates (see response #4 below). If we can make it work, I’d prefer to use CAA as opposed to TXT records.

As for cross-protocol attacks, I believe that the rigid syntax required by the DADL record is an effective mitigation.

4) I'm not sure I understand Tim's comment re: directionality - both this and CAA walk bottom-up

Perhaps I wasn’t clear in my previous email, but I was attempting to convey that the presence of any CAA record at a given domain halts tree-climbing. This makes CAA cumbersome to use to signal domain validation information, as domain owners need to repeat issue and issuewild property tags on every domain where they wish to specify allowed domain validation methods. This is not DRY (“don’t repeat yourself”) at all and cumbersome for domain owners.

Shooting off the cuff here a bit, but perhaps to increase DRYness, a new CAA property tag is created which instructs CAA processors to store the encountered CAA Resource Record Set and then continue the tree-climbing process. Once the DNS root is reached or a non-empty Resource Record Set is encountered that doesn’t contain the “no halt” property tag, the concatenation of all Resource Record Sets is processed as a singular CAA Resource Resource Set. This would allow domain owners to define DV information (along with the “no halt” property tag) in CAA records (which may differ from that found at the Base Domain Name /parent nodes) but allow for a singular location to define allowed issuers (presumably at the Base Domain Name). Support for it by CAs could be optional, but domain owners can mandate support by setting the “critical” flag on the “no halt” record.

Thanks,
Corey

From: Ryan Sleevi <sleevi at google.com>
Date: Tuesday, April 24, 2018 at 11:29 AM
To: Corey Bonnell <CBonnell at trustwave.com>, CA/Browser Forum Validation WG List <validation at cabforum.org>
Subject: Re: [cabf_validation] Designated Authorization Domain Label (method F) write-up

On Tue, Apr 24, 2018 at 9:25 AM, Corey Bonnell via Validation <validation at cabforum.org<mailto: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<http://scanmail.trustwave.com/?c=4062&d=zs3f2lMsJyWWiLw_Fa5xsinBqbrWyGEiMmJiVZXHCg&s=5&u=http%3a%2f%2fexample%2ecom>”. For operational reasons, they cannot use any of the accepted domain validation methods directly against “example.com<http://scanmail.trustwave.com/?c=4062&d=zs3f2lMsJyWWiLw_Fa5xsinBqbrWyGEiMmJiVZXHCg&s=5&u=http%3a%2f%2fexample%2ecom>”, but they can provision a web server at “_pki-validation.example.com<http://scanmail.trustwave.com/?c=4062&d=zs3f2lMsJyWWiLw_Fa5xsinBqbrWyGEiMjQwUZXAWg&s=5&u=http%3a%2f%2fpki-validation%2eexample%2ecom>” to perform domain validation. As such, they create a TXT record at “example.com<http://scanmail.trustwave.com/?c=4062&d=zs3f2lMsJyWWiLw_Fa5xsinBqbrWyGEiMmJiVZXHCg&s=5&u=http%3a%2f%2fexample%2ecom>” to designate “_pki-validation” as the DADL for “example.com<http://scanmail.trustwave.com/?c=4062&d=zs3f2lMsJyWWiLw_Fa5xsinBqbrWyGEiMmJiVZXHCg&s=5&u=http%3a%2f%2fexample%2ecom>”:
example.com<http://scanmail.trustwave.com/?c=4062&d=zs3f2lMsJyWWiLw_Fa5xsinBqbrWyGEiMmJiVZXHCg&s=5&u=http%3a%2f%2fexample%2ecom>. IN TXT “v=DADL1; l=_pki-validation”

There is an initial overhead in creating the TXT record at example.com<http://scanmail.trustwave.com/?c=4062&d=zs3f2lMsJyWWiLw_Fa5xsinBqbrWyGEiMmJiVZXHCg&s=5&u=http%3a%2f%2fexample%2ecom>, 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<http://scanmail.trustwave.com/?c=4062&d=zs3f2lMsJyWWiLw_Fa5xsinBqbrWyGEiMmZvX8DICA&s=5&u=http%3a%2f%2fexample%2ethecdn%2ecom>” is an alias for “example.com<http://scanmail.trustwave.com/?c=4062&d=zs3f2lMsJyWWiLw_Fa5xsinBqbrWyGEiMmJiVZXHCg&s=5&u=http%3a%2f%2fexample%2ecom>”. If the domain owner for “example.com<http://scanmail.trustwave.com/?c=4062&d=zs3f2lMsJyWWiLw_Fa5xsinBqbrWyGEiMmJiVZXHCg&s=5&u=http%3a%2f%2fexample%2ecom>” wishes to use “_pki-validation.example.thecdn.com<http://scanmail.trustwave.com/?c=4062&d=zs3f2lMsJyWWiLw_Fa5xsinBqbrWyGEiMjZmAsSVXg&s=5&u=http%3a%2f%2fpki-validation%2eexample%2ethecdn%2ecom>” as the ADN, they can create the following TXT record at “example.thecdn.com<http://scanmail.trustwave.com/?c=4062&d=zs3f2lMsJyWWiLw_Fa5xsinBqbrWyGEiMmZvX8DICA&s=5&u=http%3a%2f%2fexample%2ethecdn%2ecom>”:
example.thecdn.com<http://scanmail.trustwave.com/?c=4062&d=zs3f2lMsJyWWiLw_Fa5xsinBqbrWyGEiMmZvX8DICA&s=5&u=http%3a%2f%2fexample%2ethecdn%2ecom>. 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))
3.       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’).
a.       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.
b.       If A is NIL and DADL(X’) is not NIL, then add DADL(X’) to the set of candidate Domain Names.
5.       If X’ is not a Base Domain Name, then repeat steps 3-5 with PARENT(X’) as X’.
6.       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/20180425/8e1efaaa/attachment-0001.html>