CAA records on a CNAME

[Jan Schaumann]

Hello,

While this is at its core a DNS question, since it's about CAA records
and cert issuance, I thought to post it here as well. If this is viewed
as off-topic, my apologies.

It seems to me that the behavior in combination with CNAMEs is
suboptimal at best. I believe we need to allow CAAs to be set on
CNAMEs:

Suppose you have example.com, intended to use for misc. internal
services, such as yourinternaltickettracker.example.com,
yourinternalcoderepository.example.com, and yourintranetcms.example.com.

This allows your employees to easily access all internal services via a
common domain, which makes a whole lot of sense.

You set CAA records 'issue "your-preferred-ca"' on example.com, to
ensure that only the CA you trust can issue certs.

Now you create someapp.example.com, which is hosted by a third-party
provider. Because it's 2019, they host their app on AWS, Azure, GCE,
possibly adding a CDN, so someapp.example.com becomes IN CNAME
someapp.thirdparty.com, which may have a CNAME record to e.g.,
mumblefumble.akamaiedge.net or ghs.googlehosted.com, or
someapp.example.com.cdn.cloudflare.net or whatever.

The third-party provider offers certificates (hooray!), and because it's
easy, low cost, and low friction, they use Let's Encrypt (also
hooray!). But LE can't issue a cert, because your CAA record on
example.com doesn't include "letsencrypt.org".

So what are your options?

You're not going to get AWS, Azure, GCE, or the CDN in question to
update their CAA records to allow LE for whatever the CNAME is. That's
not scalable for them, and they're not going to add another CA to their
second-level domain CAA records. Fair enough.

You're also not going to get the 3rd-party to send you a CSR (and
automate renewal), so you can use your preferred CA. (Also fair; this is
not scalable either, and they're probably already overwhelmed by the
whole cert business & just wanted to tick the "military grade
encryption" checkbox on their offerings page.)

You could create a new second-level domain for this particular app so
that you can set the restrictive CAA record there, but then you're
breaking the user experience of having all services under the same
domain.

So your only option is to add LE at the second-level domain name,
example.com. But of course that applies to all names under that domain,
present and future. LE can now issue certs for your misc. internal
services, including those not hosted by a third-party provider. You did
not want that, which is why you initially set the CAA records as you
did.

The only way I see around this would be to allow CAA RRs on CNAMEs,
which (currently) violates RFC1912, Section 2.4. But per RFC2181,
section 10.1, we already allow e.g. SIG, NXT, and KEY RRs on CNAMEs.
Wouldn't it be prudent to also allow CAA records on a CNAME?

-Jan

[Ryan Sleevi]

I’m not sure I follow - when you go someapp.example.com to
someapp.thirdparty.example, and they point to somewhere.somecdn.example,
why is the assumption that somewhere.somecdn.example WOULDN’T place a CAA
record?

Given that somewhere.somecdn.example has the business relationship with the
CA to do provisioning, I would have thought they’d have a CAA record
expressing their provisioning relationship.

[Jan Schaumann]

Ryan Sleevi <ry...@sleevi.com> wrote:
> I?m not sure I follow - when you go someapp.example.com to

> someapp.thirdparty.example, and they point to somewhere.somecdn.example,

> why is the assumption that somewhere.somecdn.example WOULDN?T place a CAA
> record?

It's been my observation that those systems do not set CAA records, for
example, a domain hosted via

$ host someapp.example.com
someapp.example.com is an alias for ghs.googlehosted.com.
ghs.googlehosted.com has address 172.217.7.179
ghs.googlehosted.com has IPv6 address 2607:f8b0:4004:800::2013
$ host -t caa ghs.googlehosted.com
ghs.googlehosted.com has no CAA record
$

or

$ host someapp.example.com
someapp.example.com is an alias for someapp.example.com.cdn.jiveon.com.
someapp.example.com.cdn.jiveon.com is an alias for vanity20.jiveon.com.edgekey.net.
vanity20.jiveon.com.edgekey.net is an alias for e13068.dscb.akamaiedge.net.
e13068.dscb.akamaiedge.net has address 104.108.119.92
e13068.dscb.akamaiedge.net has IPv6 address 2600:1400:d:68a::330c
e13068.dscb.akamaiedge.net has IPv6 address 2600:1400:d:697::330c
$ host -t caa e13068.dscb.akamaiedge.net
e13068.dscb.akamaiedge.net has no CAA record
$

or

$ host someapp.example.com
someapp.example.com is an alias for someapp.example.com.cdn.cloudflare.net.
someapp.example.com.cdn.cloudflare.net has address 104.16.125.51
someapp.example.com.cdn.cloudflare.net has address 104.16.126.51
$ host -t caa someapp.example.com.cdn.cloudflare.net
someapp.example.com.cdn.cloudflare.net has no CAA record


I also think that's reasonable, since any number of services might host
their apps on the provider's platform, so they likely have a large
number of CNAME records pointing to them. For each one, the service in
question might use a different CA, and ghs.googlehosted.com (in this
example) would need to add those CAs to its CAA records.

-Jan

[Ryan Sleevi]

On Fri, Mar 15, 2019 at 12:31 PM Jan Schaumann via dev-security-policy <
dev-secur...@lists.mozilla.org> wrote:

> I also think that's reasonable, since any number of services might host
> their apps on the provider's platform, so they likely have a large
> number of CNAME records pointing to them. For each one, the service in
> question might use a different CA, and ghs.googlehosted.com (in this
> example) would need to add those CAs to its CAA records.
>

I guess I'm confused still.

It sounded like your concern was that CDN was using their own
CDN-contracted CA, in which case, adding those CAA records should be fine.
But this response makes me think you're thinking of a "bring your own cert"
scenario, in which case, lacking CAA records is exactly what's intended.

I don't think we here will really be able to do anything for this; as you
note, this is really a question about fundamental DNS specification, and
whether or not other records can live along-side a CNAME. That seems like
it'd be IETF's DNS group?

If CDN wants to restrict what CAs its customers use (e.g. because the CDN
provisions certificates), having the CDN set CAA seems fine. If the CDN
does not want to restrict, it's not clear that having the "original" site
restrict is necessarily good or desirable? I'm just confused still about
the use case and value.

[Jan Schaumann]

Ryan Sleevi via dev-security-policy <dev-secur...@lists.mozilla.org> wrote:

> I don't think we here will really be able to do anything for this; as you
> note, this is really a question about fundamental DNS specification, and
> whether or not other records can live along-side a CNAME. That seems like
> it'd be IETF's DNS group?

Fair. I was just wondering if this group had any concerns or opinions
on the matter.

> If CDN wants to restrict what CAs its customers use (e.g. because the CDN
> provisions certificates), having the CDN set CAA seems fine. If the CDN
> does not want to restrict, it's not clear that having the "original" site
> restrict is necessarily good or desirable?

To me, the value in being able to do that is that I can allow one-offs
for certain subdomains of a domain for which I already have CAA records
set. I.e., I don't want to open the second-level domain entirely to
whichever CA the 3rd-pary app uses, but I do want the 3rd-party app to
get their certs for that one subdomain.

It's alright if others don't see value in that; as you said (and I
agree), it's ultimately a DNS question, so I can take it there.

-Jan

[Ryan Sleevi]

On Fri, Mar 15, 2019 at 4:40 PM Jan Schaumann via dev-security-policy <
dev-secur...@lists.mozilla.org> wrote:

> Ryan Sleevi via dev-security-policy <dev-secur...@lists.mozilla.org>
> wrote:
>
> > I don't think we here will really be able to do anything for this; as you
> > note, this is really a question about fundamental DNS specification, and
> > whether or not other records can live along-side a CNAME. That seems like
> > it'd be IETF's DNS group?
>
> Fair. I was just wondering if this group had any concerns or opinions
> on the matter.

Yeah, apologies if that seemed dismissive; it was more that I don't think
we could accomplish the specific proposal.

It does highlight opportunities to understand the problem though and look
at ways to address it. One could imagine an alternative solution (as
opposed to changing the CAA spec) would be a way to delegate authority for
certain CNAME'd subdomains. That is, an issue/issuewild parameter tag with
a CA-specific property defined by the CA/Browser Forum (or by IETF) that
detailed specific provisions for certain CNAMEs children. Elegant? No. But
perhaps easier than updating DNS RFCs :)

[Jan Schaumann]

Ryan Sleevi <ry...@sleevi.com> wrote:

> That is, an issue/issuewild parameter tag with a CA-specific property
> defined by the CA/Browser Forum (or by IETF) that detailed specific
> provisions for certain CNAMEs children.

Hmm, maybe something like

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.

Ie, 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.

> Elegant? No.

Indeed...

-Jan

[Matt Palmer]

On Fri, Mar 15, 2019 at 05:40:29PM -0400, Jan Schaumann via dev-security-policy wrote:
> Ryan Sleevi <ry...@sleevi.com> wrote:
> > That is, an issue/issuewild parameter tag with a CA-specific property
> > defined by the CA/Browser Forum (or by IETF) that detailed specific
> > provisions for certain CNAMEs children.
>
> Hmm, maybe something like
>
> 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've read through your posts on this topic several times, and I still don't
understand the problem you're trying to solve. If you point a CNAME at
someone else, then you're delegating to them control of that name. If they
set CAA records on the CNAME target (or if they don't), and those CAA records
(or lack thereof) do not represent a functioning configuration, you work
with them to change it.

I speak on this issue not from a theoretical perspective -- I work for a
SaaS provider which provides CNAME targets to its customers, and I built
their certificate issuance pipeline, which uses LE for certificate issuance
by default, and I built it to manage CAA records on the CNAME target to
enforce that. For those (very few) customers who insist on BYO certs, we
adjust the CAA record we publish to suit their requirements (remove it or
point to another CA, as required).

So far, several years in (we've been running this system for longer than CAA
checking has been mandatory), this arrangement has managed to satisfy all of
our customers, without any desire from anyone for alternate strategies.

In fact, I think this "override" mechanism would be *worse* than the current
situation, as it would be separating operational control from the
declaration of policy. What if whoever runs the site behind
`someapp.example.com` changes from LE to Honest Achmed? They've got to
contact all those customers who have setup "override" records and ask them
to change those records. I can assure you that "ask customers to change
their DNS records" comes a very close second to "perform a self-appendectomy
without anaesthetic" on the list of things I really, really never want to
have to do.

- Matt

--
<FreeFrag> The most secure computer in the world is one not connected to the
internet. Thats why I recommend Telstra ADSL.
-- bash.org/?168859

[Jan Schaumann]

Matt Palmer via dev-security-policy <dev-secur...@lists.mozilla.org> wrote:

> I've read through your posts on this topic several times, and I still don't
> understand the problem you're trying to solve. If you point a CNAME at
> someone else, then you're delegating to them control of that name. If they
> set CAA records on the CNAME target (or if they don't), and those CAA records
> (or lack thereof) do not represent a functioning configuration, you work
> with them to change it.

someapp.example.com, over which I have control is a CNAME, so I can't
set a CAA record there. Let's say the CNAME points to
ghs.googlehosted.com.

Your suggestion is to contact Google and ask them to please add a CAA
record to that domain for a CA that a third-party (to them and myself)
chooses. My experience has been that Google, Akamai, Cloudflare,
Amazon, and Microsoft etc. are not amenable to adding such records.

> I speak on this issue not from a theoretical perspective

I'm sure there are many scenarios where CNAMEs are not a problem and
work entirely as intended. My use cases have not been that.

-Jan

[Corey Bonnell]

If I recall correctly, there was some discussion in late 2017 in the IETF LAMPS WG (the working group producing the successor to the current CAA RFC 6844) about modifying the CAA tree-climbing algorithm to query a prefix/"attribute leaf" subdomain to allow domain owners the ability to set a CAA configuration on domains which contain a CNAME record. You can see this referenced on slide 9 of the CAA presentation given at the LAMPS session at IETF 100: https://datatracker.ietf.org/meeting/100/materials/slides-100-lamps-rfc-6844-bis-00.pdf.

However, this idea was not pursued any further, as RFC 6844-bis (https://tools.ietf.org/html/draft-ietf-lamps-rfc6844bis-05#section-3) contains no such provision in its tree-climbing algorithm definition.

Thanks,
Corey

[Jan Schaumann]

Corey Bonnell via dev-security-policy <dev-secur...@lists.mozilla.org> wrote:

> If I recall correctly, there was some discussion in late 2017 in the
> IETF LAMPS WG (the working group producing the successor to the
> current CAA RFC 6844)

Thanks for noting this. Sounds like that's the best group to continue
the discussion in.

-Jan

[Jan Schaumann]

[Hector Martin 'marcan']

On 16/03/2019 10:25, Jan Schaumann via dev-security-policy wrote:
> someapp.example.com, over which I have control is a CNAME, so I can't
> set a CAA record there. Let's say the CNAME points to
> ghs.googlehosted.com.
>
> Your suggestion is to contact Google and ask them to please add a CAA
> record to that domain for a CA that a third-party (to them and myself)
> chooses. My experience has been that Google, Akamai, Cloudflare,
> Amazon, and Microsoft etc. are not amenable to adding such records.

I think part of the problem here is that the CAA specification has no
"allow all" option. Third party hosting providers probably want to allow
their customers to use any CA they wish, so they lack CAA records.
However, there is no way to specify this once you have already
encountered a CAA record, so by the time you follow the CNAME, you're stuck.

The default CAA behavior can *only* be specified by default, by the
absence of records throughout the entire tree. In my optinion this is an
oversight in the CAA specification.

My use case is different, but somewhat related. I host services for an
event under example.com, e.g. <service>.example.com, but I also have a
dynamic user.example.com zone (several, actually) where users
automatically get a dynamic record assigned at
<hostname>.user.example.com. I use Let's Encrypt for all of the
services. Currently I have a CAA record for example.com, but this also
locks all the dynamic users into using Let's Encrypt, while I want them
to be free to use any CA. I could instead have a CAA record for <every
individual service>.example.com, but this is hard to manage and less
secure, as it would allow issuance for all nonexistent names and is
harder to manage. Ideally I would just set a CAA record for "*" on
user.example.com and that would solve the issue, but the current CAA
specification has no mechanism for this.

If CAA had a way to signal an explicit "allow all", then third party
hosting services could signal that on their overall zones in order to
solve this problem with CNAMEs (of course, customers who wish to lock
down their CAA records for such third-party hosted domains would have to
get CAA records added to them, but I think that makes more sense as an
explicit thing rather than breaking CNAMEs by default).

--
Hector Martin "marcan"
Public key: https://mrcn.st/pub

[Corey Bonnell]

Perhaps not very elegant, but you can encode an “allow all issuers” CAA RRSet by specifying a single iodef CAA record without any issue/issuewild records in the RRSet, which will probably be treated as permission to issue for CAs. I say “probably” because the RFC wasn’t clear on the proper handling RRSets with no issue/issuewild property tags, but this was clarified in the CAB Forum in Ballot 219 (https://cabforum.org/2018/04/10/ballot-219-clarify-handling-of-caa-record-sets-with-no-issue-issuewild-property-tag/) to explicitly allow the above behavior (although of course some CAs may be more restrictive and disallow issuance in this case).

Thanks,
Corey
________________________________
From: Corey Bonnell <corey.j...@outlook.com>
Sent: Monday, March 18, 2019 16:42
To: Hector Martin 'marcan'; Jan Schaumann
Cc: dev-secur...@lists.mozilla.org
Subject: Re: CAA records on a CNAME

Perhaps not very elegant, but you can encode an “allow all issuers” CAA RRSet by specifying a single iodef CAA record without any issue/issuewild records in the RRSet, which will probably be treated as permission to issue for CAs. I say “probably” because the RFC wasn’t clear on the proper handling RRSets with no issue/issuewild property tags, but this was clarified in the CAB Forum in Ballot 219 (https://cabforum.org/2018/04/10/ballot-219-clarify-handling-of-caa-record-sets-with-no-issue-issuewild-property-tag/) to explicitly allow the above behavior (although of course some CAs may be more restrictive and disallow issuance in this case).

Thanks,
Corey
________________________________
From: dev-security-policy <dev-security-...@lists.mozilla.org> on behalf of Hector Martin 'marcan' via dev-security-policy <dev-secur...@lists.mozilla.org>
Sent: Monday, March 18, 2019 14:26
To: Jan Schaumann
Cc: dev-secur...@lists.mozilla.org
Subject: Re: CAA records on a CNAME

Public key: https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmrcn.st%2Fpub&amp;data=02%7C01%7C%7C8c18001675284d88925f08d6ab6246d5%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636884835910007451&amp;sdata=AvRYycQp7w0zMB2to49mL0MqPdkscrDmw91ePNwKJ5k%3D&amp;reserved=0
_______________________________________________
dev-security-policy mailing list
dev-secur...@lists.mozilla.org
https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.mozilla.org%2Flistinfo%2Fdev-security-policy&amp;data=02%7C01%7C%7C8c18001675284d88925f08d6ab6246d5%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636884835910017456&amp;sdata=OGYmdLZfK8Rktf7N62tUzaJsswMiF64cQF8uGL6eekw%3D&amp;reserved=0

[Hector Martin 'marcan']

On 18/03/2019 16:42, Corey Bonnell wrote:
> Perhaps not very elegant, but you can encode an “allow all issuers” CAA
> RRSet by specifying a single iodef CAA record without any
> issue/issuewild records in the RRSet, which will probably be treated as
> permission to issue for  CAs. I say “probably” because the RFC wasn’t
> clear on the proper handling RRSets with no issue/issuewild property
> tags, but this was clarified in the CAB Forum in Ballot 219
> (https://cabforum.org/2018/04/10/ballot-219-clarify-handling-of-caa-record-sets-with-no-issue-issuewild-property-tag/)
> to explicitly allow the above behavior (although of course some CAs may
> be more restrictive and disallow issuance in this case).

Huh, I hadn't considered that interpretation. Indeed, a strict reading
of the RFC suggests that would work. It seems an arbitrary non-defined
non-critical CAA tag record should work too (if using an actual iodef is
undesirable for some reason). Maybe such a tag should be defined for
this purpose?

Though this won't help Amazon/Google/etc, as having a higher-level CAA
record would require tree-climbing on CNAME targets, which was removed
by errata 5065. Sorry for the noise.

--
Hector Martin "marcan"
Public key: https://mrcn.st/pub