Re: Quic: the Elephant in the Room

David Schinazi <> Tue, 20 April 2021 17:07 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C75F03A0A3D for <>; Tue, 20 Apr 2021 10:07:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id s-IzC6Z7qgua for <>; Tue, 20 Apr 2021 10:07:15 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::634]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D63D33A0A38 for <>; Tue, 20 Apr 2021 10:07:15 -0700 (PDT)
Received: by with SMTP id n10so8872958plc.0 for <>; Tue, 20 Apr 2021 10:07:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=yttsJwunFdlU6HBwthvj7u77YVqiHFLJ1zgZEGjj200=; b=EyJEWl85SG+7QaXe8jQWoTz1hfwlofU7G/VUyQvRirtpMuWBTmD+tJyEtDYWXZH/F8 rSyzP3TPk2nyF5yBOU4zFm77DrQm2T7FarWo11HM8WErCCEFDUnpW3a8BGMfbH8FNfJk bqs/xCNFPVSB5G7Tl5/lzCmcIs8SSoOnkXE61Ts/3TMsh4oGeKyTbD/casC0oO7Orw5K Lanu2v2VFzKd+B+OQJHBC7anqThK6YMxLdK9dIzzlsL97QoGiiuzgRmfCK6dgUfoiTq6 hHEqNLFpd0s1Sg1DfPNUuFSKOgeCNrMPiJu73rIYpSxmZ3EPWrPPdZ/QdTjH+M/ApkJt ZhaQ==
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=yttsJwunFdlU6HBwthvj7u77YVqiHFLJ1zgZEGjj200=; b=Y6jI3HgnvrVlTGavUDIRqwb08dHgL+PLn5gdqWJRbBVGyg4E54dgQZOXV3/rV+rBXi ZTpUZHrW0L5jWYRXGvAfzXaFsxR3hD9p0ijr6UzfRoVFlmSbBQcJqVmBFMTXZKwYUibI tVIHamlLhJQ6QYq4pKSdHSL3FhhJ68UsSt9ZDZcBJto3/rD+mbGr84s8Znbl4l1D4SDe ZLuKVbHSCo2ss7rjpwltZySZq0msezrJYv1NAKCUABb7bOL/k25vxJT5pWz0VyWu3htM wdivADvX7AkIsxGmNcTaqchMm8fTryGVpZeagccq9rv+v1olTsSBW0pQIBbirqL1jzXY Ab3g==
X-Gm-Message-State: AOAM531VB6pfxPjoxfWhmzfspD17uXCKqVEnhRvdRoDxGl3PiaPgl6HI kD2+QAbaefCh6nDiYm+AFb3ZpRsYtjslV2csT0I=
X-Google-Smtp-Source: ABdhPJy1H9Nefgdj4cnmfNIGeTyfD2NgjQrstlBfqxbt/GscAoBdm/km8NU2Avyoev3kP2BRjQjy4s3n7p+QXjik6Uc=
X-Received: by 2002:a17:90b:30d2:: with SMTP id hi18mr5941727pjb.94.1618938434653; Tue, 20 Apr 2021 10:07:14 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <> <> <>
In-Reply-To: <>
From: David Schinazi <>
Date: Tue, 20 Apr 2021 10:07:03 -0700
Message-ID: <>
Subject: Re: Quic: the Elephant in the Room
To: Michael Thomas <>
Cc: Lucas Pardue <>, IETF QUIC WG <>, Matt Joras <>
Content-Type: multipart/alternative; boundary="0000000000004f933705c06a7a05"
Archived-At: <>
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Main mailing list of the IETF QUIC working group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 20 Apr 2021 17:07:21 -0000

Hi Mike,

I read your blog post, and I failed to find what problem you're trying to
The fact that some handshakes spend a couple packets on certificates?
We can actually quantify the user-visible impact of the handshake size, and
from everything I've seen this particular topic isn't impactful enough to
apart from ensuring support for RFC 8879. It's even less realistic if the
solution involves the minor task of switching PKIs and roots of trust.
Speaking as one of the QUIC tech leads at a "Google-like company", I can
ensure you that we don't spend time on experiments that don't benefit users.
It seems that you have a solution in search of a problem here.


On Mon, Apr 19, 2021 at 3:39 PM Michael Thomas <> wrote:

> On 4/19/21 3:33 PM, Lucas Pardue wrote:
> > I'm struggling to see what the problem statement that is unique to the
> > QUIC protocol is.
> >
> > That certificates can be large is not new information, it was a prime
> > motivator for RFC 7924 [1] and RFC 8879 [2].
> >
> > Operators can, of course, experiment with new optimal ways of doing
> > things. The broader IETF community is likely interested in the outcome
> > of such experiments. Since QUIC version 1 uses TLS, any changes that
> > stand to improve a QUIC handshake would likely be applicable to TLS
> > too. So the concept of replacing current TLS mechanisms with the DNS
> > doesn't seem to be something the QUIC WG should be leading. Should
> > such work identify QUIC protocol design evolution or extension, then
> > it could be suitable for WG consideration.
> >
> I'm not asking this working group to do anything. Just socializing
> something that generated a lot of discussion on the IETF list that might
> be of interest to the Quic community.
> Mike