Re: [lamps] CAA records on CNAMEs

[Tim Hollebeek <[e-mail]>]

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 <[e-mail]> On Behalf Of Jan Schaumann
> Sent: Monday, March 18, 2019 12:02 PM
> To: [e-mail]
> Subject: Re: [lamps] CAA records on CNAMEs
> 
> 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
> 
> _______________________________________________
> Spasm mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/spasm