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

Wed Apr 25 07:05:06 MST 2018

Hi Tim,

I did look through the 10 methods while developing this language. Given the following assumptions:

  1) The ability to create and/or manipulate the contents of DNS records at a given FQDN is sufficient to perform domain validation for it and all children nodes in DNS (using method 7), so if an attacker wishes to leverage a DADL for DV, they may as well just use method 7 and directly create a TXT record containing the Random Value/Request Token.

  2) Since Applicants can create static CNAME records to delegate domain validation (for example, a static CNAME record for “_acme-challenge.example.com” to “account-123.dv.myca.com”), there is no need for freshness of the DADL record.

  3) Given #1 and #2, a DADL record is identical to a CNAME record, except that:

   a) It is specific for domain validation only

   b) It delegates to a subdomain of the given Domain Name only (not to another branch of DNS or to a parent node)

   c) Unlike CNAME, it allows for other Resource Records to exist at the given Domain Name.

  4) All methods that allow validation at an ADN as of BR version 1.5.6 still allow use of an ADN (we discussed restricting certain methods, such as Method 6, to allow validation at the FQDN only. I’m ignoring that for now, since a separate analysis is required).

I determined the redefinition will impact the 10 Blessed Methods accordingly:

1) :)

2) This is weird, as the text states “Each email, fax, SMS, or postal mail MAY confirm control of multiple Authorization Domain Names”. But the validation/confirmation of control is done for the FQDN, not any ADNs. My initial thought was that we could do something similar to method #3 (which states something to the effect of anything under the Base Domain Name is validated), but that ignores the possibility that a DNS SOA record for a child zone under the Base Domain Name can be used for domain validation using this method (and obviously would validate only FQDNs in that child zone, not all FQDNs under the Base Domain Name). In other words, further analysis/wordsmithing required :)

3) N/A (ADN not used)

4) Given assumption #3, and that mail clients chase aliases when resolving the domain name, there are no surprising security properties of the redefinition of ADN.

5) :))

6) Given assumption #3, and that the DNS resolution logic used by HTTP(S) clients generally chase aliases when resolving the server hostname to an IP address, there is nothing surprising here.

7) As mentioned in my previous email, modifying the ADN definition does allow for validation at a sub-sub-domain of the FQDN. This is undesirable, but I don’t address that for now as we likely need to rework method 7 to allow only an explicit set of subdomains (ie, “_acme-challenge”).

8) N/A

9) Given assumption #3, and that the DNS resolution logic used to make TLS connections generally chase aliases, there is nothing surprising here.

10) See #9.

I’ll respond to Ryan’s comments in a separate email.

Thanks,
Corey

From: Tim Hollebeek <tim.hollebeek at digicert.com>
Date: Tuesday, April 24, 2018 at 10:44 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

Also, have you looked through all the places where ADN is used and verified this definition change doesn’t have unfortunate undesired consequences?

-Tim

From: Validation [mailto:validation-bounces at cabforum.org] On Behalf Of Corey Bonnell via Validation
Sent: Tuesday, April 24, 2018 9:25 AM
To: validation at cabforum.org
Subject: [cabf_validation] Designated Authorization Domain Label (method F) write-up

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.<http://scanmail.trustwave.com/?c=4062&d=r8Lf2tsBK6gPsVNBW9LnqAJotHOPdIVFjOayKP9kpw&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=r8Lf2tsBK6gPsVNBW9LnqAJotHOPdIVFjOayKP9kpw&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” 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.<http://scanmail.trustwave.com/?c=4062&d=r8Lf2tsBK6gPsVNBW9LnqAJotHOPdIVFjOK_IqprpQ&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))

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

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

Corey Bonnell
Senior Software Engineer
t: +1 412.395.2233

Trustwave | SMART SECURITY ON DEMAND
www.trustwave.com<http://www.trustwave.com/>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/validation/attachments/20180425/53354ef9/attachment-0001.html>