[cabfpub] Updates on CAA deployment

[Jacob Hoffman-Andrews]

Hi all,

I wanted to share my recent post from Let's Encrypt's forums regarding our
experiences implementing CAA. In particular I'd like to draw attention to
RFC6844's potential for loops, which I brought up during previous
discussion of the problems with legacy RFC6844. This is preventing us from
renewing certificates for a number of our subscribers. We use a short
certificate lifetime (90 days) and encourage renewal when 30 days are left
on a certificate, so if this problem remains through the full vote and IPR
process (44 days), many subscriber certificates will expire without a
replacement.

-------

https://community.letsencrypt.org/t/legacy-caa-implementation/42335

On Thursday we enabled an implementation of the legacy form of the CAA (
RFC6844 <https://tools.ietf.org/html/rfc6844>) spec. Previously, Let’s
Encrypt implemented an amended and simplified form of RFC6844 as described
in erratum 5065 <https://www.rfc-editor.org/errata/eid5065>. We’ve been
working on getting the erratum officially adopted at the CA/Browser Forum,
and there is general consensus at both IETF and the CA/Browser Forum that
the amended version is ideal. Unfortunately, the details haven’t yet been
formally voted in, so we have implemented the older version temporarily
while we wait for the vote to go through
<https://cabforum.org/pipermail/public/2017-September/012066.html>.

The difference is the handling of CNAMEs. Under erratum 5065, to check CAA
for www.example.com, the CA looks up CAA for www.example.com, then
example.com, then com (this is called tree-climbing). If any CNAMEs are
encountered along the way, the CA’s recursive resolver automatically
resolves them according to RFC1034, and the CA gets the CAA record at the
end of the CNAME chain, if there is one.

Under legacy CAA, the CA is required to additionally climb the DNS tree on
each CNAME record it receives along the way, and check CAA for each of
those. For instance, if www.example.com is a CNAME to
hosting.customer.example.net, the CAA must additionally check CAA for
customer.example.net, example.net, and net. This may introduce new
hostnames into your CAA path that were not there before. If any of those
hostnames fails CAA lookup, issuance will be blocked.

There’s another issue with legacy CAA: Mixed CNAME/tree-climbing loops.
Normally loops in CNAME records are handled automatically by recursive
resolvers, and result in lookup failures. As a result, CNAME loops in the
wild are rare. However, the tree-climbing behavior introduces a new
potential loop. Say, for example, blog.example.com is a CNAME to
www.blog.example.com. According to a strict interpretation of RFC6844, the
CA is required to check CAA for blog.example.com, then www.blog.example.com,
then blog.example.com, then blog.example.com, and so on forever. We’ve
addressed this in our code by setting a limit on how deep we will chase
such CNAMEs. In the interest of security and correctness, we fail closed in
such a scenario and prevent issuance. RFC6844 does not specify how to
handle such loops; under erratum 5065 there is no possibility for loops.
Unfortunately, such mixed CNAME/tree-climbing loops are a very common and
legitimate DNS setup in the wild, so this blocks issuance for some domains.

We’ve already gotten several reports from users that this is causing
breakage:

   - Consistent 500's for new-cert (failing CAA for one domain)
   <https://community.letsencrypt.org/t/consistent-500s-for-new-cert-failing-caa-for-one-domain/41334/9>
   - Too many CNAMEs when looking up CAA
   <https://community.letsencrypt.org/t/too-many-cnames-when-looking-up-caa/42321>
   - https://github.com/letsencrypt/boulder/issues/3093

We understand this is causing issuance problems for many people, and we’re
going to be continuing to push hard to find a solution soon that allows
continued issuance and renewal for affected domains.

One workaround that may work for if your DNS provider fully supports
setting CAA records: As described in our CAA documentation
<https://letsencrypt.org/docs/caa/>, CAA processing terminates early if any
CAA record is found. Setting a CAA record for your domain that explicitly
allows issuance by Let’s Encrypt can help avoid these problems. This is of
course not an ideal solution: not all DNS software supports setting CAA
records, and not everyone has direct control of their DNS.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20170915/7676b7d9/attachment-0002.html>