Re: [lamps] CAA records on CNAMEs

[Jan Schaumann <[e-mail]>]

Ilari Liusvaara <[e-mail]> wrote:
> On Sat, Mar 16, 2019 at 06:32:26PM -0400, Jan Schaumann wrote:
 
> > 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?
> 
> That lookup happens just on the full name, right after lookup on the
> 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


> > 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"
 
> 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.
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:[e-mail]"
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:[e-mail] 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