Re: Quic: the elephant in the room

Phillip Hallam-Baker <> Mon, 12 April 2021 14:44 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id AF26A3A20D6 for <>; Mon, 12 Apr 2021 07:44:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.398
X-Spam-Status: No, score=-1.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id mxbXieZF2ybB for <>; Mon, 12 Apr 2021 07:44:23 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 4AD723A20D1 for <>; Mon, 12 Apr 2021 07:44:23 -0700 (PDT)
Received: by with SMTP id o17so5454637qkl.13 for <>; Mon, 12 Apr 2021 07:44:23 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=f82PWimYQhh6ppBuXLpGR9oC3pkqoGa3iWUvPbcpI+M=; b=QkAzwxYVN5sQYm1Gsxdv7vj2VqjIk3hkfFZQ7QBbdxL9c8tjCqWTq4xR3h36LefX3U FB17RnfEAFPEFiU+Z6U3HpnwKEpFIwkQTbjR5LuWpAqffHtNChDDoX8ddIHEBKehO39P hGmuNafQM3oUDipMHNmu2/LoBAKpB367jrboOZzGhvkT/CIcw0MoHpfy1gg7Gu97nQR7 aPaVLkC67k7szeJc7w1n7zk4qkkFPTbiNznYfidiKHy2/+4e2TvwXle9uDcotohYhcqv qrcGRV+b3jbNJBT72FHSGyVj1TCE3jqqYTOA33rCGhSAzJ3uopyixvD/75jA/YRXgzbW avRg==
X-Gm-Message-State: AOAM530qgbKgFr3Ch3vziAK35iRTV5zZ/YW8GQgm7D0y+yaTccWGGTqN a5Xp2FV7yir53G/A6pL0AJUEuI06vYieCSpe4Js=
X-Google-Smtp-Source: ABdhPJzUU9rwfjMRZ/2mFNVYyjn6pKdAVtUhiItSFX9flIUT4qd1UHHXxEtp37KIW6oQ8JYODjDZPWaiP0gwveA0ahc=
X-Received: by 2002:a25:7752:: with SMTP id s79mr31637033ybc.522.1618238662125; Mon, 12 Apr 2021 07:44:22 -0700 (PDT)
MIME-Version: 1.0
References: <20210412021224.GP9612@localhost> <> <20210412002634.GO9612@localhost> <> <> <>
In-Reply-To: <>
From: Phillip Hallam-Baker <>
Date: Mon, 12 Apr 2021 10:44:12 -0400
Message-ID: <>
Subject: Re: Quic: the elephant in the room
To: "Salz, Rich" <>
Cc: "" <>
Content-Type: multipart/alternative; boundary="0000000000009e2b4f05bfc78c83"
Archived-At: <>
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF-Discussion <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 12 Apr 2021 14:44:28 -0000

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

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

On Mon, Apr 12, 2021 at 8:58 AM Salz, Rich <rsalz=> 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.