On Friday, March 15, 2019 at 9:26:02 PM UTC-4, Jan Schaumann wrote: > Matt Palmer via dev-security-policy <dev-security-policy@lists.mozilla.org> > wrote: > > > I've read through your posts on this topic several times, and I still don't > > understand the problem you're trying to solve. If you point a CNAME at > > someone else, then you're delegating to them control of that name. If they > > set CAA records on the CNAME target (or if they don't), and those CAA > > records > > (or lack thereof) do not represent a functioning configuration, you work > > with them to change it. > > someapp.example.com, over which I have control is a CNAME, so I can't > set a CAA record there. Let's say the CNAME points to > ghs.googlehosted.com. > > Your suggestion is to contact Google and ask them to please add a CAA > record to that domain for a CA that a third-party (to them and myself) > chooses. My experience has been that Google, Akamai, Cloudflare, > Amazon, and Microsoft etc. are not amenable to adding such records. > > > I speak on this issue not from a theoretical perspective > > I'm sure there are many scenarios where CNAMEs are not a problem and > work entirely as intended. My use cases have not been that. > > -Jan
If I recall correctly, there was some discussion in late 2017 in the IETF LAMPS WG (the working group producing the successor to the current CAA RFC 6844) about modifying the CAA tree-climbing algorithm to query a prefix/"attribute leaf" subdomain to allow domain owners the ability to set a CAA configuration on domains which contain a CNAME record. You can see this referenced on slide 9 of the CAA presentation given at the LAMPS session at IETF 100: https://datatracker.ietf.org/meeting/100/materials/slides-100-lamps-rfc-6844-bis-00.pdf. However, this idea was not pursued any further, as RFC 6844-bis (https://tools.ietf.org/html/draft-ietf-lamps-rfc6844bis-05#section-3) contains no such provision in its tree-climbing algorithm definition. Thanks, Corey _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
