[cabfpub] Continuing the discussion on CAA

[Gervase Markham]

On 26/10/16 04:08, Ryan Sleevi wrote:
> A concrete example of why I believe this is fundamentally a flawed
> design, and do not support it, is situations where 'example.com
> <http://example.com>' delegates subdomains to different marketing
> companies, who are then responsible for hosting and providing the
> content on those subdomains. Expressing CAA in this 'top down' approach
> means that, for the 'base domain', you must express the union of all
> possible CAs. We know, empirically, this is not viable.

Indeed, it would be unwise to change CAA to _only_ work this way.

> Further, I want to challenge your notion of 'base domain', 

I agree that making correct implementation of CAA depend on the PSL is
problematic - the more we can avoid using the PSL, the better.

Here is a straw-man proposal which does not require use of the PSL,
although it does require some caching outside of DNS in the case where
the new feature is used.

I don't think this solution is the most elegant technically, but Jeremy
raises the reasonable point about "what if I have to issue N million
certs for 1.example.com, 2.example.com etc.?" Because caching doesn't
help here, you would have to do a full CAA check from scratch for
everyone one of the N million. This is a rare situation, to be sure, but
I can see how it might be problematic when it does occur.

So here's the idea:

1) CA is asked to issue for foo.bar.example.com
2) CA does CAA check for foo.bar.example.com - no record
3) CA does CAA check for bar.example.com - no record
4) CA does CAA check for example.com - record found

The record is "issue 0 superca.com; subdomains=true"

What this means is that Super CA is permitted to use this CAA record for
all issuances under example.com for the TTL specified on the DNS CAA
record, without doing further CAA checks on subdomains. Once that TTL
expires, the process would begin again from scratch.

The obvious question which arises then is: what happens when records
conflict? Say a few minutes after the above events, example.com adds a
CAA record for bar.example.com saying "issue 0 ahmedscerts.com". The
answer is that the CA is allowed to use the cached info about
example.com for the DNS TTL, and after that they re-check CAA from
scratch, and hit this record, and so never get as far as checking
example.com. They instead refuse to issue, because only Ahmed's Certs is
allowed to.

OK, you ask, so what happens if the next domain they check is
wibble.example.com, which eventually gives them back the example.com CAA
record with "subdomains=true", and then they cache that, and use it to
issue later for bar.example.com, in "violation" of the CAA record
attached directly to bar.example.com? The answer is "don't put
conflicting CAA records into your DNS if you want defined and
predictable behaviour". But it still remains true that even in the worst
and most badly configured case, the only CAs which can issue anywhere
under example.com are the ones named in a CAA record somewhere within
the domain, which is still a massive improvement on the current situation.

Gerv