Subject: [lamps] Next steps on CAA

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 4 Oct 2017 10:15:30 -0400

Before writing any text, I would like us to decide what the text should
say. There is no point in wordsmithing until we know what we want to say.

​There is a lot of traffic on the CABForum mailing lists with people
raising deployment issues. I see the following, which may not be exhaustive.

* Issues to do with DNAME implementation.

* Issues to do with DNSSEC interactions.

* Issues to do with when a CA must perform a retry.​

Looking at these, I think we need to consider two separate changes to the
document

1. A fix to the specification part describing the new discovery algorithm

2. An appendix that sets out worked examples for the following

* Site publishes CAA records without DNSSEC

* Site publishes CAA record with DNSSEC

These need to expose all the relevant logic paths:

* CNAME
* DNAME
* lookup fails
* DNSSEC fails
* loops
* any more ?

We are in an unusual situation for IETF as we are defining a document which
will be used for compliance purposes. This is not unique but I can't recall
an example where I was working on a document which I knew would be used for
compliance by a specific group.

On the design decisions side, I can only see one actual decision point.
There are many points where the issue is what do the DNS specs say, but the
only part where I can see us having a choice is on whether to support
recursive tree climbing on a prefixed name.

Consider the case that www.example.net is CNAME to www.example.com. This
may be because

1) The name www.example.net is owned by the same party as www.example.com
and wants the two to be precisely equivalent.

2) www.example.com is a CDN that is hosting www.example.net.

The DNS does not provide the ability to distinguish between the two. The
only information in the DNS describes WHAT and to distinguish them, we need
WHY.

The reason we would want to distinguish is if there is a CAA record at
example.net.

1) The CNAME is there to make the names equivalent so the CAA record at
example.net should aply

2) The CNAME is only there to make the CDN work and the CAA record at
example.net should be ignored.

These issues were discussed when CAA was originally proposed but CDNs were
somewhat niche at the time and so we decided on the first approach. By the
time CABForum mandated implementation, CDNs were on their way to being
ubiquitous and hence the errata changing this to the second.

One of the issues that makes this problematic is that the DNS spec says
that a node that has a CNAME entry MUST NOT have any other records. So it
is not legal to simply tell people to put a CAA record next to the CNAME
record.

At the Chicago IETF, someone proposed we use prefixed records to get around
the limitation. This seems the best approach to me. There are a few ways
that we could do this but the simplest one as far as I am concerned is

* Ignore ALL CNAME records in CAA discovery entirely

* Search for CAA records at www.example.com and _prefix.example.com

The obvious choice for the prefix is _caa but my gut tells me that what we
are defining here is rather more general and the prefix should be generic
as well. _attr perhaps.

One issue with the simplest approach is that we have legacy deployment and
even though we can tell CAs to change what they will do and expect them to
respond within 6 months, this is not the case for sites.

It seems to me that we have three choices

A) Stick with CNAME as currently defined in the errata

B) Use the simple approach

C) CAs process using the simple approach first, ignoring CNAMEs until the
root domain is reached and then process CNAMEs.

So to illustrate, consider the following

www.example.net CNAME -> www.example.com

The checking for CAA records is as follows:

A) www.example.net, www.example.com, example.net, .net

B) www.example.net, _prefix.www.example.net, example.net, _
prefix.example.net, .net, _prefix.net

C) www.example.net, _prefix.www.example.net, example.net, _
prefix.example.net, .net, _prefix.net, www.example.com

---

From: Jacob Hoffman-Andrews <[email-masked]>
Date: Wed, 4 Oct 2017 11:03:57 -0700

> say. There is no point in wordsmithing until we know what we want to say.

I've published an individual draft on it, and gotten some feedback:
https://www.ietf.org/id/draft-hoffman-andrews-caa-simplification-01.txt.
I'm fairly sure the revised algorithm there, which is equivalent to
erratum 5065 plus some clarification about DNAMEs, is what we want to
say. I'd like to start our wordsmithing on that basis, since we've
already done some discussion.

> 1. A fix to the specification part describing the new discovery algorithm

Yep, +1.

> * Site publishes CAA record with DNSSEC

There have been problems with CAA processing on DNSSEC-signed domains,
but they are not typically due to incorrect publishing of CAA records.
They are implementation problems in authoritative resolvers, typically
when the resolver incorrectly signs an empty response. In other words,
the problems crop up when DNSSEC is present, but no CAA records are
present. Examples of signed records wouldn't help here, but describing
the class of DNSSEC implementation errors that are commonly surfaced by
CAA lookups would. I'm happy to produce a paragraph to that effect.

> There are many points where the issue is what do the DNS specs say, but
> the only part where I can see us having a choice is on whether to
> support recursive tree climbing on a prefixed name.

IETF makes decisions based on "rough consensus and running code."
Erratum 5065-style CAA is the epitome of running code; all publicly
trusted CAs are required to implement it. We should formalize that into
an RFC before we consider new, incompatible alternatives.

> These issues were discussed when CAA was originally proposed

I went back and reviewed *all* the discussion on the PKIX mailing list
from when CAA was first proposed:
https://mailarchive.ietf.org/arch/search/?email_list=pkix&q=caa.

Between draft 11 and draft 12 we went from no tree climbing at all, to
tree climbing on the issuance domain, plus tree climbing on all aliases:

https://tools.ietf.org/html/draft-ietf-pkix-caa-11#section-3
https://tools.ietf.org/html/draft-ietf-pkix-caa-12#section-4

The discussion at the time was between querying only the leaf node, vs
leaf node + delegation point, vs tree climbing on the issuance domain.
There was no constituency asking for tree climbing on the issuance
domain *plus* tree climbing on the aliases.

When tree climbing was drafted, the example text stood as it stands
today; describing erratum 5065-style processing, in contradiction to the
formal algorithm drafted at the same time. It seems like the spirit of
the room was to only do tree climbing on the issuance domain. Tree
climbing on CNAMEs was introduced as a byproduct of trying to re-specify
CNAME processing instead of relying on RFC 1034's definition of CNAME
processing.

I think
https://www.ietf.org/id/draft-hoffman-andrews-caa-simplification-01.txt
is the ideal approach, and solves immediate problems we have without
introducing new complexity.

---

From: Russ Housley <[email-masked]>
Date: Wed, 4 Oct 2017 18:14:35 -0400

> On Oct 4, 2017, at 10:15 AM, Phillip Hallam-Baker <[email-masked]> wrote:
> 
> Consider the case that www.example.net <http://www.example.net/> is CNAME to www.example.com <http://www.example.com/>. This may be because
> 
> 1) The name www.example.net <http://www.example.net/> is owned by the same party as www.example.com <http://www.example.com/> and wants the two to be precisely equivalent.
> 
> 2) www.example.com <http://www.example.com/> is a CDN that is hosting www.example.net <http://www.example.net/>.
> 
> The DNS does not provide the ability to distinguish between the two. The only information in the DNS describes WHAT and to distinguish them, we need WHY.
> 
> The reason we would want to distinguish is if there is a CAA record at example.net <http://example.net/>. 
> 
> 1) The CNAME is there to make the names equivalent so the CAA record at example.net <http://example.net/> should aply
> 
> 2) The CNAME is only there to make the CDN work and the CAA record at example.net <http://example.net/> should be ignored.

If one looks in the DNS for www.ietf.org, one will see:

	www.ietf.org.		607	IN	CNAME	www.ietf.org.cdn.cloudflare.net.

I'm not sure how you would expect to distinguish the two cases.

Russ

---

From: "John Levine" <[email-masked]>
Date: 4 Oct 2017 22:43:49 -0000

>I'm not sure how you would expect to distinguish the two cases.

If your CDN tries to lock you in with a rogue CAA record, that's a
business issue, not a technical one.

R's,
John