[Spasm] CAA erratum 4515

[Jacob Hoffman-Andrews <[e-mail]>]

Good news! The CA/Browser forum made CAA checking mandatory, effective 8
September 2017
<https://cabforum.org/pipermail/public/2017-February/009722.html>. As
part of the process, we had a very interesting conversation (see bottom
for specific email links) about the processing algorithm specified in
RFC 6844 <https://tools.ietf.org/html/rfc6844#section-4>section 4
<https://tools.ietf.org/html/rfc6844#section-4> and how to handle
CNAMEs. Specifically, if there exists a set of records like so:

www.staffie.dog.        CNAME staffie.terrier.dog.

staffie.terrier.dog.    A 192.0.2.1

terrier.dog.            CAA 0 issue "happy-hacker-fake-ca.net"


Should issuance for www.staffie.dog require a CAA query for terrier.dog?
Or should it only require CAA queries for www.staffie.dog and
staffie.terrier.dog? It looks like we're not the first to be confused by
this. In October 2015, Tom Clegg filed erratum 4515
<https://www.rfc-editor.org/errata_search.php?rfc=6844&eid=4515>,
changing the behavior. My position is that his approach is better, and
we should formally adopt it.

I'd like to define some terms so we can speak clearly:

 - Recursion: What a recursive resolver does: finding and querying
authoritative resolvers, and chasing CNAMEs.

 - Tree climbing: Looking up records for parent domains sequentially,
e.g. "www.staffie.dog", "staffie.dog", "dog".

The current RFC says that CA software should recurse, then tree climb on
any CNAME results, then tree climb on the original name, and repeat.

*The argument from naturalness*

I think the most natural way to think of CNAMEs is analogous to
symlinks. If you `dig A www.staffie.dog` from a recursive resolver, you
get back an IP address and don't need to care about the chain of
intervening CNAMEs. The CAA RFC asks CA software to "peek inside" the
CNAME chain for further processing, which is a significant difference
from how other resource record types are handled.

*The argument from ease of implementation

*Right now, recursive resolvers take care of all CNAME chasing,
including loop detection. To implement CAA as it is defined today, CA
software needs to implement some moderately complex code to tree climb
not only the original name, but also CNAME results. This means the CA
software needs to implement its own loop detection as well. I think
we're likely to see inconsistent and buggy results. On the other hand,
erratum 4515 allows CA software to make three simple, predictable
requests to its recursive resolver:

CAA www.staffie.dog.
CAA staffie.dog.
CAA dog.
**
*The argument from you don't need that*

As I understand it, the argument for the current algorithm is that it
makes it easier for CDNs to deploy CAA records. For instance, if
terrier.dog is a CDN serving the terrier community, and they only
request certificates from Happy Hacker Fake CA, they can easily express
that policy by putting a CAA record on terrier.dog. I would argue that
it's just as easy for terrier.dog to configure their authoritative
resolver to return a CAA record for *.terrier.dog.

*The argument from CDNs don't want to do that*

Cloudflare helpfully chimed in on the original thread saying that they
wouldn't actually want to deploy a blanket CAA record for all their
customers, even though Cloudflare uses a well-defined set of CAs. That's
because doing so would prevent customers from getting their own
certificates from other CAs for non-HTTPS uses, or for subdomains like
party.www.staffie.dog. Even though the customers could override this by
setting their own CAA resource records, this is a hassle that Cloudflare
doesn't want to impose. Other CDNs are likely to feel similarly.

*Hole punching and the includeSubDomains problem*

Part of the debate is informed by deployment difficulties with HPKP
includeSubDomains. For instance, in a previous job I deployed HTTPS at
Twitter. We configured HPKP preloading with includeSubDomains on
twitter.com, including all of the CAs that any of our CDNs used.

Sometimes, for example, the marketing department, would hire a
contractor to build a quickie website like superbowl2017.twitter.com.
The contractor would have their own relationship with a hosting provider
or CDN, who might use a CA not on the list. It would have been nice to
be able to define hole punching, so superbowl2017.twitter.com could have
its own definition of which CA keys are allowed. That's not possible
with HPKP, but it is possible with CAA, intentionally.

However, it's the tree climbing that gets us the hole punching property,
not the alternating tree climb / recursion currently specified in RFC
6844. So adopting erratum 4515 would not break the hole punching property.


*Previous conversation*

  * [cabfpub] Ballot 187 - Make CAA Checking Mandatory 
    <https://cabforum.org/pipermail/public/2017-February/009803.html>  /philliph
    at comodo.com/
  * [cabfpub] Ballot 187 - Make CAA Checking Mandatory 
    <https://cabforum.org/pipermail/public/2017-February/009804.html>  /Peter
    Bowen/
  * [cabfpub] Ballot 187 - Make CAA Checking Mandatory 
    <https://cabforum.org/pipermail/public/2017-February/009810.html>  /philliph
    at comodo.com/
  * [cabfpub] Ballot 187 - Make CAA Checking Mandatory 
    <https://cabforum.org/pipermail/public/2017-February/009811.html>  /Peter
    Bowen/
  * [cabfpub] Ballot 187 - Make CAA Checking Mandatory 
    <https://cabforum.org/pipermail/public/2017-February/009814.html>  /Peter
    Bowen/
  * [cabfpub] Ballot 187 - Make CAA Checking Mandatory 
    <https://cabforum.org/pipermail/public/2017-February/009815.html>  /Ryan
    Sleevi/
  * [cabfpub] Ballot 187 - Make CAA Checking Mandatory 
    <https://cabforum.org/pipermail/public/2017-February/009816.html>  /Peter
    Bowen/
  * [cabfpub] Ballot 187 - Make CAA Checking Mandatory 
    <https://cabforum.org/pipermail/public/2017-February/009817.html>  /Ryan
    Sleevi/
  * [cabfpub] Ballot 187 - Make CAA Checking Mandatory 
    <https://cabforum.org/pipermail/public/2017-February/009819.html>  /philliph
    at comodo.com/
  * [cabfpub] Ballot 187 - Make CAA Checking Mandatory 
    <https://cabforum.org/pipermail/public/2017-February/009836.html>  /Jacob
    Hoffman-Andrews/
  * [cabfpub] Ballot 187 - Make CAA Checking Mandatory 
    <https://cabforum.org/pipermail/public/2017-February/009837.html>  /Ryan
    Sleevi/
  * [cabfpub] Ballot 187 - Make CAA Checking Mandatory 
    <https://cabforum.org/pipermail/public/2017-February/009838.html>  /Jacob
    Hoffman-Andrews/
  * [cabfpub] Ballot 187 - Make CAA Checking Mandatory 
    <https://cabforum.org/pipermail/public/2017-February/009839.html>  /Phillip
    Hallam-Baker/

/(whole thread:
/https://cabforum.org/pipermail/public/2017-February/thread.html)