Subject: [lamps] CAA records on CNAMEs

From: Jan Schaumann <[email-masked]>
Date: Sat, 16 Mar 2019 18:32:26 -0400

Hello,

I'd like to revisit how CAA records on CNAMEs are handled.

As noted in e.g.,
https://datatracker.ietf.org/meeting/100/materials/slides-100-lamps-rfc-6844-bis-00.pdf,
there are cases where it's desirable for an organization to set a CAA
record on a CNAME.  For example:

If I have existing CAA records on example.com and add a new name
someapp.example.com as a CNAME to a third-party provider's service.  If
the third-party provider uses a different CA from the one(s) I use, I
currently cannot selectively allow only this CA for this single name: as
a CNAME, the resolution logic mandates that the canonical name is
considered and, if no CAA record is found there, the CA crawl up to
example.com.

To illustrate the problem:

$ host -t caa example.com
example.com has CAA record 0 issue "digicert.com"
$ host -t cname someapp.example.com
someapp.example.com is an alias for ghs.googlehosted.com.
$

Let us assume that the third-party provider wants to use Let's Encrypt.

Here, my options are:

- add "letsencrypt.org" to the CAA records for example.com

  This is undesirable for me, because I do not wish to let LE to issue
  certificates for myotherservice.example.com.

- ask Google to add LE to the CAA record for ghs.googlehosted.com.

  This is not likely successful.  Google has no interest in either
  restricting this domain to only LE, as presumably other services may
  well point at this name and use other CAs.

- use a different domain, e.g., someapp.separate-example.com and set the
  CAA record there

  This is undesirable, because I want to keep all my things under
  'example.com' for a better user experience / branding / whatever.

The "easiest" solution would be to allow CAA records on CNAMEs.  This
(currently) violates RFC1912, Section 2.4. But per RFC2181, section
10.1, we already allow e.g. SIG, NXT, and KEY RRs on CNAMEs; would it
make sense to allow CAA on CNAMEs as well?

An alternative solution was suggested in the slides noted above: change
the CAA resolution algorithm to first attempt a _prefix on which I can
set an override (i.e., '_prefix.someapp.example.com IN CAA issue
"letsencrypt.org"').  This proposal was not reflected in
https://datatracker.ietf.org/doc/draft-ietf-lamps-rfc6844bis/, however,
so I assume there was discussion that concluded this to be undesirable?

A third possibility might be to add another 'override' tag to the CAA
definition, e.g.:

example.com CAA 0 issue "digicert.com"
example.com CAA 0 override "someapp.example.com issue:letsencrypt.org"

would mean that Digicert can issue certs for anything under example.com
with the exception of 'someapp.example.com', for which only Let's
Encrypt can issue a cert.

I.e., the 'override' tag may override CAA records for the given name.
The name must be within the same domain and must be deeper than where
this CAA record is set.

Let's say that this only is useful for CNAMEs; this would require the CA
to extend the handling of CNAMES:

   Let CAA(X) be the record set returned in response to performing a CAA
   record query on the label X, P(X) be the DNS label immediately above
   X in the DNS hierarchy, O(X) be the result of an override, and A(X)
   be the target of a CNAME or DNAME alias record chain specified at the
   label X.

   o  If CAA(X) is not empty, R(X) = CAA (X), otherwise

   o  If A(X) is not null, and CAA(A(X)) is not empty, then R(X) =
      CAA(A(X)), otherwise

   o  If X is not a top-level domain, then

      o  If R(P(X)) contains an 'override' for X, then R(X) = O(P(X)),
         otherwise

      o  R(X) = R(P(X))

      otherwise

   o  R(X) is empty.

I'm seeking input on whether the workgroup would consider any of these
options or otherwise would revive the discussion around the need to find
a way to set CAA records on a CNAME separate from the parent label.

Thanks,
-Jan

---

From: Russ Housley <[email-masked]>
Date: Sun, 17 Mar 2019 13:40:46 -0400

We need to get this sorted very quickly.  This document has already been sent to the IESG.

Russ

> From: Jan Schaumann <[email-masked]>
> Subject: [lamps] CAA records on CNAMEs
> Date: March 16, 2019 at 6:32:26 PM EDT
> To: [email-masked]
> 
> Hello,
> 
> _______________________________________________
> Spasm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/spasm

---

From: Ilari Liusvaara <[email-masked]>
Date: Sun, 17 Mar 2019 20:02:56 +0200

> make sense to allow CAA on CNAMEs as well?

Unfortunately that would break DNS. There are few exceptions to
"nothing alongside CNAME" rule, but that is because the RRtypes
involved are magic DNSSEC ones.

Trying to stick anything else alongside CNAME leads to horrible
failure rates. That is not some servers fail, but almost all servers
fail. E.g., see. CNAME@apex (SOA and NS).  

> so I assume there was discussion that concluded this to be undesirable?

That lookup happens just on the full name, right after lookup on the
name itself, right? I.e., not on any tree-climbed names.

> Encrypt can issue a cert.

One would presumably want to flag that as critical.

And are overrides recursive or not? Based on description it looked that
they require exact match.

And how is the name represented? DNS can present all sorts of really
wonky names, including ones containing spaces or dots. I do not think
public CAs are allowed to issue for such names tho.

> a way to set CAA records on a CNAME separate from the parent label.

-Ilari

---

From: Tim Wicinski <[email-masked]>
Date: Sun, 17 Mar 2019 11:49:28 -0700

We did not like using something like _caa.example.com ?

I mean we have an RFC and an IANA registry all set up to handle the
underscore name
(well almost https://tools.ietf.org/html/draft-ietf-dnsop-attrleaf-16)

We've been burned on CAA records for specific FQDNs which are CNAMEs.

Tim

---

From: Ilari Liusvaara <[email-masked]>
Date: Sun, 17 Mar 2019 21:16:49 +0200

> We've been burned on CAA records for specific FQDNs which are CNAMEs.

I think that was essentially one of the proposals.

And IIRC, the real nasty issue was treeclimbing on CNAME target, that
caused a lot of issues.

-Ilari

---

From: Tim Wicinski <[email-masked]>
Date: Sun, 17 Mar 2019 13:48:04 -0700

I am no DNS expert, but I routinely see DNS records of the form

foobar.example.com CNAME cdn.example.net
email.foobar.example.com MX
email.foorbar.example.com TXT

But of course RFC8499 is the better source.

Going back to the presentations, Phillip Hallam-Baker noted that _prefix
labels don't work with DNAME.

Tim

---

From: "Salz, Rich" <[email-masked]>
Date: Mon, 18 Mar 2019 15:28:58 +0000

Start by changing RFC RFC 1912, which does not allow any other data to appear with a CNAME. ;)

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 18 Mar 2019 11:46:47 -0400

This is exactly back where we started.

There are three technical options. Each time I comment on this I understand
that we have decided to go for the prefix records solution and every time
it turns out we didn't and a few months later the same problem comes up.

The problem here is that CNAME delegation is used to implement two entirely
different types of delegation and does not specify which one is intended.
When 6844 was written, the Web was in a different place, CDNs were not so
ubiquitous and so the needs then were different and when we discussed it
then we decided to make one particular choice. But it was a fully
considered choice.

Also at the time CAA was proposed, the DNS folk insisted that prefix
records represent some sort of heresy and must be avoided at all costs. It
has since been realized that they are necessary to fix the fact that the
DNS architecture does not meet DNS use. And why would something designed 35
years ago to meet the needs of the Internet scaling from 100 hosts to 1000
anticipate everything that came since?

The two uses of delegation are:

1) Asserting name equality. i.e. *.example.net = *.example.com

2) Delegating isolated domains www.example.com -> example.mycdn.com

On top of this there is the fact that DNAME isn't really a DNS RR only it
is because it has to be because of DNSSEC only it doesn't have the
semantics you would expect and certainly not the semantics that you want.

Long and the short of it is that if you want to do the right thing for both
the use cases, you need to distinguish one of the cases using a prefix to
the CAA record.

I am not going to be in Prague as I am still finishing the Mesh specs and
getting my company registered as an LLC. Right now it is
VentureCryptography.com

---

From: Jan Schaumann <[email-masked]>
Date: Mon, 18 Mar 2019 12:02:11 -0400

> name itself, right? I.e., not on any tree-climbed names.

I'm not the author of the original proposal, but I'd think the lookup
could work in one of two ways:

1) only perform the lookup on the full name iff it is a CNAME
2) perform the lookup on any tree-climbed name

(1) has the advantage of simplicity, at the cost of (some)
inconsistency; (2) has the advantage of consistency at the cost of
complexity and performance.  Worse is Better suggests (1).

As for how to handle combinations with DNAMEs, I suppose under (1), the
situation is largely unchanged:

With 'example.com DNAME example.net' a lookup for a CAA record for
someapp.example.com would yield:

- per the DNAME requirement, there must not be any record for
  someapp.example.com, so we only look at someapp.example.net:
- if someapp.example.net has a CAA record, return that; else
- if someapp.example.net is a CNAME to someapp.example.org:
  - if _caa.someapp.example.net has a CAA record, return that; else
  - if someapp.example.org has a CAA record, return that; else
- try example.com, which falls under the DNAME, so check example.net; if
  that has a CAA record, return; else
- try .com

> they require exact match.

For simplicity, I think it might make sense to require that an
'override' can only be given for specific labels above in the tree.
That is, no wildcards and no further recursion.

In order to simplify matching of records and names, we could swap the
order, to the symtax might be:

override "<issue|issuewild|iodef>:<value> <name>"

In example, this might look like so:

example.com CAA 0 iodef "mailto:[email-masked]"
example.com CAA 0 issue "digicert.com"
example.com CAA 0 override "issue:letsencrypt.org foo.example.com"
example.com CAA 0 override "issuewild:globalsign.com bar.example.com"
example.com CAA 0 override "iodef:mailto:[email-masked] bofh.example.com"

I'll also note that in a parallel thread on mozilla.dev.security.policy,
it was noted that there may be a need for an explicit way to allow any
CA to issue (in contrast to not having a CAA record, and thus requiring
a tree-climb ending only possibly in an implicit approval of any CA):
https://groups.google.com/d/msg/mozilla.dev.security.policy/DVa-xn1VsOA/DhQk9RZmDAAJ

-Jan

---

From: Tim Hollebeek <[email-masked]>
Date: Mon, 18 Mar 2019 16:53:25 +0000

The problem is the "override" proposal adds another huge level of complexity
on top of the semantics of the issue tag and every other tag involved in the
issuance of certificates in the future (there will be more).

As such, I think the proposal is strictly inferior to much simpler solutions
e.g. the ones involving prefix tags.  You can even do clever things like
saying the prefix tag is only relevant for CNAME records (this avoids having
to do an additional DNS lookup for every node just to check if the prefix
tag exists at that node).

The prefix tag issue resurfaces every six to twelve months or so; interested
persons should probably just concentrate on pushing that across the goal
line.  Though I think it probably isn't necessary to hold up RFC6844bis for
it.  We already said "no" to one other request to extend CAA that
potentially could have held up RFC6844bis.  It can be its own RFC.

-Tim

> -----Original Message-----
> From: Spasm <[email-masked]> On Behalf Of Jan Schaumann
> Sent: Monday, March 18, 2019 12:02 PM
> To: [email-masked]
> Subject: Re: [lamps] CAA records on CNAMEs
> 
> > > An alternative solution was suggested in the slides noted above:
> > > change the CAA resolution algorithm to first attempt a _prefix on
> > > which I can set an override (i.e., '_prefix.someapp.example.com IN
> > > CAA issue "letsencrypt.org"').  This proposal was not reflected in
> > > https://datatracker.ietf.org/doc/draft-ietf-lamps-rfc6844bis/,
> > > however, so I assume there was discussion that concluded this to be
> undesirable?
> >
could work
> in one of two ways:
> (1) has the advantage of simplicity, at the cost of (some) inconsistency;
(2) has
> the advantage of consistency at the cost of complexity and performance.
> Worse is Better suggests (1).
> 
> 
> > > A third possibility might be to add another 'override' tag to the
> > > CAA definition, e.g.:
> > >
> > And are overrides recursive or not? Based on description it looked
> > that they require exact match.
> 
> For simplicity, I think it might make sense to require that an 'override'
can only
> be given for specific labels above in the tree.
order,
> to the symtax might be:
it was
> noted that there may be a need for an explicit way to allow any CA to
issue (in
> contrast to not having a CAA record, and thus requiring a tree-climb
ending
> only possibly in an implicit approval of any CA):

---

From: Jan Schaumann <[email-masked]>
Date: Mon, 18 Mar 2019 13:49:44 -0400

Tim Hollebeek <[email-masked]> wrote:
 
> e.g. the ones involving prefix tags.

Agreed.

> The prefix tag issue resurfaces every six to twelve months or so

I'd be interested to hear arguments previously used against a prefix
tag to ensure they are addressed or at least considered should we
propose to pursue this.

-Jan

---

From: Tim Hollebeek <[email-masked]>
Date: Mon, 18 Mar 2019 18:06:31 +0000

I don't think there really have been any arguments against.  
People have just had other higher priorities.  Getting something
standardized takes time and effort.

The are a bunch of other reasonable extensions to CAA that 
can and should be considered.  I do agree that it's probably
time to start pulling a formal document together so that they
can be fleshed out.  RFC 6844bis was more of a "fix a bunch 
of broken stuff" thing than a "let's add some new features"
thing.  Now that that's on its way out the door, perhaps it
is time for a CAA extensions discussion.

-Tim

> Sent: Monday, March 18, 2019 1:50 PM
> To: [email-masked]
> > As such, I think the proposal is strictly inferior to much simpler
> > solutions e.g. the ones involving prefix tags.
> 
> Agreed.
> 
> I'd be interested to hear arguments previously used against a prefix tag
to
> ensure they are addressed or at least considered should we propose to
pursue
> this.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 19 Mar 2019 09:05:13 -0400

The logic of override would be that you end up with an override version of
each tag.

I don't think the semantics end up as being what you want them to be
either. Example.com could have hundreds of Web Service hosts, so the
override scheme would end up with an enormous collection of CAA records.

On Mon, Mar 18, 2019 at 12:53 PM Tim Hollebeek <[email-masked]>
wrote:

> solutions