Re: [lamps] CAA records on CNAMEs

[Phillip Hallam-Baker <[e-mail]>]

The logic of override would be that you end up with an override version of
each tag.

I don't think the semantics end up as being what you want them to be
either. Example.com could have hundreds of Web Service hosts, so the
override scheme would end up with an enormous collection of CAA records.


On Mon, Mar 18, 2019 at 12:53 PM Tim Hollebeek <[e-mail]>
wrote:

> 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
>
> _______________________________________________
> Spasm mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/spasm
>