Rich brings up a very important point which is worth generalizing: Proposals to change a deployed infrastructure must support every feature of that legacy infrastructure if they are going to be a replacement.
People start off saying 'we will build on X because it is widely used'. What they don't realize is that when you do that, you have to spend time discovering and working around all the bizarre ways X is being used. The design of CAA is a case in point, it uses the DNS to publish information and was originally based on one set of assumptions. Between the original spec being written and the CABForum making it a requirement the use of CDNs went from being a niche concern to a common one and that required the handling of wildcards to be retooled.
It was the exact same thing with DKIM where most of the work was discovering and working around bizarre corner cases.
Any proposal that begins 'lets change the way people use DNS' has a mighty hard lift. And it is not just the technical infrastructure you need to understand, it is the commercial. The reason I was so heavily involved in DKIM was that our resellers were the businesses that would have to implement the TXT records.
Ten years after DANE started, my very very large Web hosting provider I use for my secondary hosting does not support TLSA records. And they appear to have no plans to do so. And there are tens of thousands of other similar businesses that have no plans to implement TLSA because doing so is simply going to take revenue out of their pocket. They sell domains at cost and they only make profits from added value services, the biggest of which is selling SSL certificates.
Same thing happened with IPv6, for at least the first decade of IPv6, the people working on it naively assumed that the way to make it attractive was to reserve functionality that would only be supported in IPv6. IPSEC being originally part of that. Only gradually did some people start to understand that the applications were not going to make use of any functionality that wasn't supported by at least 95% of the network and so features that were IPv6 only would be uninteresting and unusable. And some folk are still in denial.
And the thing that worries me here is that the IETF likes to think of itself as fostering discussion and interworking between specialists in different areas. Which sounds fine in practice only those of us who actually do work at multiple layers are not exactly made to feel welcome anywhere.
On Mon, Apr 12, 2021 at 8:58 AM Salz, Rich <rsalz=40akamai.com@xxxxxxxxxxxxxx> wrote:
> one may as well delegate the TLSA record management to the CDN:
Sure, if you're never going to switch CDN's.
Many big customers switch CDN's and will not delegate because, well, they need to switch.
There is a whole industry and providers around switching CDN's in real time. Web-search "Cdn switch" will find them, for example.
> But any sort of TLSA RR on the customer side, while the cert rollover
are managed by the CDN is too fragile. The TLSA RRs should properly
be published by the CDN as above.
Sure, if there's one CDN.
> If indeed sub-minute migration from one CDN to another is required, then
the TTL for the _443._tcp.[...] CNAME would need to be sub-minute. Is
such a short cutover time really a requirement?
If millions of dollars of commerce are happening per minute, then yes. Or the head of state dies and the official news source is overloaded.
