Subject: Re: [lamps] Next steps on CAA

From: Patrick Donahue <[email-masked]>
Date: Thu, 5 Oct 2017 15:07:36 -0700

I've provided a real-world counter example below that illustrates why
climbing the CNAME tree will cause significant real-world breakages for
companies like Cloudflare who provide free SSL certificate issuance and
termination.

While we believe that erratum 5065 fixes this, we are very much in support
of seeing straightforward RFC confirmed that will make it clear to CAs that
CNAME tree climbing is no longer required.

*Example:*
Cloudflare customers have, collectively, over 400,000 CNAMEs to
ghs.google.com. This CNAME value is what Google instructs[1] their Blogger
customers to use to serve their blog on their own custom domain.

Were a CA have to check for a CAA record at google.com (in addition to
ghs.google.com) they'd see this:

$ dig CAA +short ghs.google.com
$ dig CAA +short google.com
*0 issue "pki.goog"*

1 - https://support.google.com/blogger/answer/58317?hl=en

In article <[email-masked]>; you write:
> >> 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.
> 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

-- 
Patrick R. Donahue
[email-masked]

PGP Fingerprint: 2E8D 5A38 682E EC00 C0F3  E7F2 D9BE 68D2 ABF3 6B24

---

From: "John R Levine" <[email-masked]>
Date: 6 Oct 2017 17:04:20 -0400

> climbing the CNAME tree ...

Oh, sorry, I misread some previous messages and misunderstood the problem. 
I agree, the domain owner needs to be able to publish CAA independent of 
where it might be hosted.

Since I am not a fan of tree climibing or of the PSL, here's my 
suggestion:

www.mysite.example. CNAME something.smogflare.example.   ; indirect to web host

1. first look for CAA here, works whether name is CNAME'd

_caa.www.mysite.example. CAA  128 issue "letsencrypt.org"

2. failing that look for it here, backward compatible

www.mysite.example. CAA  128 issue "letsencrypt.org"

3. Failing that, stop.

This doesn't deal with DNAMEs but I don't see any reasonable solution to 
DNAMEs since I don't see any reasonble way to construct a non-DNAME'd name 
from a DNAME'd one.

R's,
John

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 6 Oct 2017 17:35:19 -0400

On Fri, Oct 6, 2017 at 5:04 PM, John R Levine <[email-masked]> wrote:

> Since I am not a fan of tree climibing or of the PSL, here's my suggestion:
>

​Tree climbing is necessary in the primary domain because of the widespread
use of split DNS. Many certificates are issued for machines that are not
and will not ever be visible on the public network. This is absolutely as
intended.

Wildcard certificates are not an acceptable solution because they are not
available for Extended Validation for good reasons.​

---

From: Jacob Hoffman-Andrews <[email-masked]>
Date: Fri, 6 Oct 2017 14:42:37 -0700

On 10/06/2017 02:04 PM, John R Levine wrote:
> This doesn't deal with DNAMEs but I don't see any reasonable solution
> to DNAMEs since I don't see any reasonble way to construct a
> non-DNAME'd name from a DNAME'd one.
Note that there is no need to deal explicitly with DNAMEs (or CNAMEs).
They are handled for us by the DNS spec, and are resolved transparently
by any recursive resolver. This is the main issue fixed in the
caa-simplification draft.

---

From: "John R Levine" <[email-masked]>
Date: 6 Oct 2017 18:14:37 -0400

> caa-simplification draft.

If you'll review the messages you're responding to, you'll see that the 
problem is that we want a CNAME'd web server and a non-CNAME'd CAA.  There 
are some cases where tree climbing might fix that, but a lot where it 
won't, e.g.:

mydom.example.  CAA issue "nope"   ; no web server here
www.mydom.example. CNAME somehost.example. ; web server here

Where does the CAA go?

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

---

From: Jacob Hoffman-Andrews <[email-masked]>
Date: Fri, 6 Oct 2017 15:20:20 -0700

On 10/06/2017 03:14 PM, John R Levine wrote:
> If you'll review the messages you're responding to, you'll see that
> the problem is that we want a CNAME'd web server and a non-CNAME'd
> CAA.  There are some cases where tree climbing might fix that, but a
> lot where it won't, e.g.:
>
Three options:

 - Remove the record on mydom.example
 - Adjust the record for mydom.example to allow issuance by preferred CAs
 - Ask the maintainer of somehost.example to install an appropriate CAA
record

---

From: "John R Levine" <[email-masked]>
Date: 6 Oct 2017 18:25:39 -0400

>  - Remove the record on mydom.example

I don't want a web server at all that name.  No dice.

>  - Adjust the record for mydom.example to allow issuance by preferred CAs

I still don't want a web server at that name.  No dice.

>  - Ask the maintainer of somehost.example to install an appropriate CAA

If you'll review the message two or three back at in this thread, you'll 
note that there are cases where somehost.example has 400,000 names CNAMEd 
to it.  No dice.

Waving this problem away is not helpful.

R's,
John

---

From: "John R Levine" <[email-masked]>
Date: 6 Oct 2017 18:27:38 -0400

I see that the current draft says that CAs climb up the tree a label at a 
time all the way to the TLD, looking for a CAA policy record.

I think you will find a great deal of resistance to that design, because 
it runs into the dbound problem. If I register fobar.hockey, I do not want 
the .hockey TLD setting my default certificate policy.

DMARC has a similar problem looking for policy records for mail 
authentication.  If there's no _dmarc record for a particular domain, 
implementations find the related "organizational domain", roughly the 
highest name under the same management, and it looks for a _dmarc record 
for the organizational domain.  Current implementations use the mozilla 
PSL or something similar; if we were able to converge in something in 
dbound or its reincarnation, they'd use that instead.

I cheefully agree that the PSL is awful, but as far as I can tell all of 
the alternatives are worse.

R's,
John

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 6 Oct 2017 22:50:15 -0400

> Waving this problem away is not helpful.

​Hence the proposal for

_prefix.​www.mydom.example CAA ...

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 6 Oct 2017 23:17:46 -0400

There is an interesting difference with this spec. If the spec goes through
IETF process and becomes an RFC and the folk in CABForum vote to do so,
this goes into production as a compliance requirement.

One side effect of that is that there cannot be any loose ends. PSL is a
loose end.

We debated the dbound problem at great length and then decided that it
doesn't matter. There are really only a few TLDs of any consequence and if
they did something silly, we can vote to unsilly as a special case. And
since they know that, it is unlikely folk will be silly.

Yes, VeriSign could put a CAA record in .com but I bet they won't because
even if they go mad and do, we can pass a CABForum rule with a special
exception.

On Fri, Oct 6, 2017 at 6:27 PM, John R Levine <[email-masked]> wrote:

> for the organizational domain.  Current implementations use the mozilla PSL
> or something similar; if we were able to converge in something in dbound or
> its reincarnation, they'd use that instead.
>
> _______________________________________________
> Spasm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/spasm
>

---

From: "John R Levine" <[email-masked]>
Date: 7 Oct 2017 11:09:04 -0400

> One side effect of that is that there cannot be any loose ends. PSL is a

Perhaps, but CAs already use it a zillion times a minute to decide what 
certs to issue.

> since they know that, it is unlikely folk will be silly.

It would not be silly for Verisign to put a CAA at com. saying it has no 
certs at all.  But it would be extremely silly for CAs to apply that CAA 
to 2LDs or 3LDs under .com.

Or are you saying that CAAs only work in "real" TLDs?  If so it would be 
useful to have a list.

R's,
John

---

From: Ryan Sleevi <[email-masked]>
Date: Sat, 7 Oct 2017 12:24:41 -0400

On Sat, Oct 7, 2017 at 11:09 AM, John R Levine <[email-masked]> wrote:

> certs at all.  But it would be extremely silly for CAs to apply that CAA to
> 2LDs or 3LDs under .com.
>

I don't think that's the same meaning. I think, especially in the world of
gTLDs, it's both reasonable and sensible to allow CAA records at the TLD,
and there's no need for the public suffix list concerns. At best, such
problems are business problems - not technology problems.

---

From: "John R Levine" <[email-masked]>
Date: 7 Oct 2017 12:33:39 -0400

> problems are business problems - not technology problems.

I suppose there's some merit in that viewpoint.

Regards,

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sat, 7 Oct 2017 13:30:34 -0400

> problems are business problems - not technology problems.

​My original proposal was that CAs were required to state what their CAA
policy was. This could range from ignore completely to enforce exactly. I
deliberately left that slack in the system because the alternative was to
deal with all the implications of ICANN world in IETF.

The stick there was that any CA that mis-issued was going to find
themselves on a very sticky wicket if they had not checked CAA. Contrawise
if the subject had not issued a CAA record then they would be at fault.

The problem with that approach was that there is a network effect. There is
little value in publishing CAA until it is checked and vice versa. Hence
the need for CABForum to make it mandatory.

Given that we have CT, we could have a scheme in which a CA may use any
domain exclusion list provided that they publish it in a CT log first.​ But
that seems like something more in 'policy' space than 'technical'.

---

From: "John Levine" <[email-masked]>
Date: 7 Oct 2017 18:51:03 -0000

>_prefix.​www.mydom.example CAA ...

Right.  I think that solves everything but the DNAME problem, and I
think the DNAME problem, if it actually exists, is insoluble.

R's,
John

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sat, 7 Oct 2017 15:10:29 -0400

> think the DNAME problem, if it actually exists, is insoluble.

​I don't think there is a DNAME problem.

DNAME is not a DNS RR, it is a DNSSEC RR. The only time it should be
returned is when a synthetic CNAME is returned.

DNAME is just like an NSEC3 record​, it is not a record that carries data
or signature information directly. All it does is to provide a record that
a signature can be attached to for a wildcarded CNAME.

---

From: "John R Levine" <[email-masked]>
Date: 7 Oct 2017 16:13:35 -0400

> ​I don't think there is a DNAME problem.

Neither do I but for a completely different reason.

The CNAME problem here is that you use a CNAME to point your web server at 
a third party host but you want to publish your own CAA, not the host's 
CAA.

Hypothetically, you might want to do the same thing with DNAME, but every 
DNAME I've ever seen other than AS112 aliases two name trees where the 
corresponding names are (or at least are supposed to be) under the same 
control.

Regards,

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sat, 7 Oct 2017 16:25:54 -0400

On Sat, Oct 7, 2017 at 4:13 PM, John R Levine <[email-masked]> wrote:

> a third party host but you want to publish your own CAA, not the host's CAA.
>

​If DNAME appeared on the wire, that would be a good reason to make use of
it. for that purpose. Unfortunately, the only time you can rely on it being
published is when DNSSEC is in use.

When CAA was originally written, CDNs were sufficiently rare that the main
use of CNAME was also name equality under the same control. That has
changed.

---

From: "John R Levine" <[email-masked]>
Date: 7 Oct 2017 16:39:55 -0400

> ​If DNAME appeared on the wire, t...

> use of CNAME was also name equality under the same control. That has

Right about CNAMEs.

The DNAME problem (if it exists) has nothing to do with whether the DNAME 
shows up in the DNS answer.  It's whether it's important to be able to 
publish a CAA record that describes a policy for a DNAME'd web server, 
with the CAA not DNAME'd, just like the CNAME problem that prefixed names 
address.

As I've said several times, although it's hypothetically possible, I doubt 
it's an issue in practice because other than the exotic AS112 I've never 
seen anyone use DNAME to point names at a third party.  That's fortunate 
since the prefix hack doesn't help for DNAMEs.

R's,
John