Subject: [dane] Unintended consequences of CNAME chasing for DANE

From: Paul Hoffman <[email-masked]>
Date: Thu, 4 Aug 2011 09:56:35 -0700

As I read the recent threads, I see people who are saying, in essence, "if I do myname.com CNAME myhostername.com, I mean that I want my hosted to handle all of the associated parts of running my site". That is probably true, but not supported in the current DNS. The way around this proposed by Phill is that one chases the CNAME chain if the TLSA record is not found at the original name. (Matt McCutchen proposed something similar as well.) Doing so would match the perception that the hoster gets to provide all the parts needed.

However, if you want to control your own security policy, such as being able to assert that there is no TLSA record, these proposals fail. That is, your hoster will be able to insert a TLSA record for myname.com  without your consent. That seems like a bad idea.

Further, for the HTTP-over-TLS scenario that most people are talking about, the hoster can publish just one TLSA record that applies to every one of the domains that point to myhostername.com. If every hosting customer uses the same CA, that's probably OK; if every hosting customer is happy having the hoster use the same self-issued certificate for their site as for every other customer of the hoster whom they don't know, that's OK too. However, those seem like a stretch.

Given this, I believe that the balance of "helping administrators by not requiring a second CNAME" versus "forcing a second CNAME but giving more control to the name owner" tips strongly towards the latter. If we were creating something that completely prevented a hoster from offering TLSA, I would not feel this way, but the requirement that "if you want someone else to host TLSA for you, you need to add a second CNAME" is not too onerous when compared with "we made a protocol that allows someone to host TLSA for you even if you don't want to use TLSA".

--Paul Hoffman