Re: Quic: the elephant in the room

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

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=
[e-mail]> 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.
>
>
>