Re: Quic: the elephant in the room

Phillip Hallam-Baker <> Mon, 12 April 2021 15:11 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B13E63A21DD for <>; Mon, 12 Apr 2021 08:11:36 -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 DorYnYsJpBkY for <>; Mon, 12 Apr 2021 08:11:31 -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 7F6B73A22E3 for <>; Mon, 12 Apr 2021 08:11:13 -0700 (PDT)
Received: by with SMTP id b139so8730776qkc.10 for <>; Mon, 12 Apr 2021 08:11:13 -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=j2oyEeMTOK37V+1sZSeTLW2sNXwMfDzrtswWJYL1R4w=; b=KakkApNgE4Ng1WZo8xvIF6LFakAUPQICKuCbyI3cby64sUN3gtQP6vs6qMFacQw/n7 Pd+H62LAXY4bvAMoN10JwRyrDehe4XkmXKAnxbIZsoIpYfY75/ayi79IBQ8GpMUiu+uB +j1eyFYG/Xit3xxe/eSEyY4nHTtUDnrwvy3mjfAk4zXgU8gqw2I470/fPbPiSMX2+iuW Bivjo1RFWq9f8P5FDTV0ibYRHWkpPRSb2zNf9f7q35cS2s/OHR5V+lv2TDx32PrM6wzS dUFBvTKZQmbNe4eVL+IcbJhPxgfLIRgkVpWRbVHNAI/KvOIg5nT+0dTucS78zmjV9oNg SOkA==
X-Gm-Message-State: AOAM531S80Al0UIcLR4kg8fqRfnC28oz3m03NDDQ6PMkoRNCQxWKGAg3 ca42IIYDNap+Wl5O/bphnAvlw0/3xKsrROOmWk6bmehGWijoSg==
X-Google-Smtp-Source: ABdhPJy2EhxgTXrr/rT0p/iGZMiWxM2PlvqaabxhdJEemjx9UU/qrV81V6C9WdblRrz8AGpNuTrPyDrpRPdliAyIboA=
X-Received: by 2002:a25:850b:: with SMTP id w11mr38740669ybk.518.1618240271756; Mon, 12 Apr 2021 08:11:11 -0700 (PDT)
MIME-Version: 1.0
References: <>
In-Reply-To: <>
From: Phillip Hallam-Baker <>
Date: Mon, 12 Apr 2021 11:11:01 -0400
Message-ID: <>
Subject: Re: Quic: the elephant in the room
To: Michael Thomas <>
Cc: IETF Discussion Mailing List <>
Content-Type: multipart/alternative; boundary="0000000000008f32cc05bfc7ec47"
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 15:11:37 -0000

Responding back to Michael's original post, I and many others have tried to
get Google to implement some trial feature in Chrome. And on occasion, we
have succeeded. DANE was in some versions of Chrome at one point.

But persuading someone we know to frob Chrome is not a scalable approach.
And from the point of view of the stability of the Internet as a whole it
is a really bad idea to be alpha testing ideas on a testbed of a billion
users. Google is not the only gatekeeper of course, there is Safari and
Microsoft Edge. But those have also got rather large footprints. They are
still too big to play games with.

There is a large amount of customization possible within Chrome of course
but very little of the work we do in IETF is work that fits easily into a
Javascript extension. We want to be playing with the low level crypto
engine, the transports, etc. All the stuff we do NOT want to be accessible
to a plug in. Not ever.

So what is the solution?

What I think we need is a community of knowledge that can help get IETF and
other ideas into an alpha/beta test situation without having to become
total wonks on the Chrome code base which is very very large and keeping up
with it is pretty much a job in itself. Just setting up a machine to
compile Chrome is a major undertaking.

What we really need is a version of Chrome or Edge that has some of the old
extension points built back in and some new ones added so we can use it as
an engineering test bed. APIs like.

* Password vault interface (to drop in choice of password manager).
* Discovery interface (to change DNS lookup).
* Transport interface (to trial new TLS / QUIC like proposals).
* Compression interface (to enable testing of new compression and content
encryption schemes).
* Certificate validation

That is my API list wish at any rate. Other people might have different
asks but I don't think even a maximal list would be very long.

If there was a community interested in building such a tool, we should be
able to find the funds necessary to do it really right from somewhere. Much
of the knowledge we need exists within the browser community, it is just a
case of getting the right expert to tell us how to do something right.

The way I would find an audience for such a browser is really simple. Just
give me the ability to limit Chrome/Edge to never ever allocating more than
X GB of memory and I will switch to it immediately. I am sure many others
would do the same. No matter how much RAM I put in a machine, it is never
going to be enough if Chrome wants half, Visual Studio wants the other half
and I try to open Microsoft Word.

The business model for the non-profit callsign registry is to fund exactly
that sort of project but that is a couple of years off at this point.

On Fri, Apr 9, 2021 at 7:17 PM Michael Thomas <> wrote:

> I wrote a blog post about how something like DANE could be used instead
> of certificates for the TLS handshake to get it back to the original 3
> packet handshake. I know that isn't news to a lot of people, but the
> interesting part is that a Google could perform an experiment to see how
> well it works in real life just like they did with Quic and Spdy. Since
> Quic is all about making setup time faster, it seems like a pretty
> reasonable experiment since it would cut out 2 packets generally
> speaking since DNS can be cached.
> Mike