Re: Quic: the Elephant in the Room

Eric Rescorla <> Tue, 20 April 2021 20:18 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 84B173A1759 for <>; Tue, 20 Apr 2021 13:18:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=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 rlavhWga1miq for <>; Tue, 20 Apr 2021 13:18:21 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::d2f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 40B613A1758 for <>; Tue, 20 Apr 2021 13:18:21 -0700 (PDT)
Received: by with SMTP id e186so39809967iof.7 for <>; Tue, 20 Apr 2021 13:18:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=gVxcwordbufj6E/J2cNXzJoKb4Ag8RzwsMRBjD3Nw1U=; b=oqD0MSQ1JwdECQAjsQm5UZz9iq0jz1++9/SenE0MUpacHUnGjkL33bjs3rT4Kb3ZfY HXTqHveop8uNS7JIZCIs7oVOjh3WIvc+00dkNy4r/4PTGcGT3T/xmRjr+WpCa/Tjp9Cr APPVP/P0iRxPsWOMWuIxLdx6T/tjMSBP10m1HTsKOuV1/gFsvbhvv+Uy7xJnwnLk4Vq4 iuuqCaKZ4cugK4ahgmB60kqrGdO/2pZCNb5ITHELsx9M1RXfANLu2HEVU47nwuhRwyIQ SyiUTSCyhicNSoPVn14bbr3brArP6McCm+dyoDxaq1dCmbvFsal/Xo9KWvA0Q189tI2O 4CyQ==
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=gVxcwordbufj6E/J2cNXzJoKb4Ag8RzwsMRBjD3Nw1U=; b=Rwx0uiVBJBviKhOX9woAVDng+UrOAdWZRcDqYFHNSpRSeCGY1YCpic11LBPgitn6Us EZ0eWv9zkBvhtJUrToQa9Pam27v1XjuvX1w+SOHrM5AvBp6IVpRwWm143bMccQDtjmy3 GKsbPNvlq5DHAyUObvRWrIBB2Oh7WL2QsWeba4wRchN2hdDEeOUx3A578/9xO0tlgReQ HwRXiHK250xTkeMS+2NECBtyPUVjO1O/d/d9XBAe8UIryzf+WYf56RpdgrBoVxq4kEvC pGEi/vKpzMULR7wgfrDXmHPTsyYuHPiWkS7zvhMysh2NA2PUT6CwuOKHfP0G1vzIGrF5 iABw==
X-Gm-Message-State: AOAM532jAE2RIe56lYkIvbfRgXFG3OvcLkvWIi761OEA9qUMTgDPeujX Dz30SMu9/GH1ZxiBGjbEIAZdpRpmVNPU0TZQb9CJeg==
X-Google-Smtp-Source: ABdhPJx6XEPkgx/nLQepzuFwEUvnVsSLUirjl5Gbs9fdx6fUdnYO6w9E8pI72lPLBxafK2NQ2lsBNITxGHBnLznuByw=
X-Received: by 2002:a05:6602:881:: with SMTP id f1mr13901973ioz.48.1618949900105; Tue, 20 Apr 2021 13:18:20 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <> <> <> <> <> <>
In-Reply-To: <>
From: Eric Rescorla <>
Date: Tue, 20 Apr 2021 13:17:43 -0700
Message-ID: <>
Subject: Re: Quic: the Elephant in the Room
To: David Schinazi <>
Cc: Michael Thomas <>, IETF QUIC WG <>, Matt Joras <>, Lucas Pardue <>
Content-Type: multipart/alternative; boundary="000000000000b48d4605c06d2528"
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 20:18:27 -0000

To follow up on what David Schinazi says, the primary determinant of
handshake latency for a protocol like TLS or QUIC is not the total number
of packets but rather the number of round trips. Of course these are not
unconnected because you don't have infinite congestion control window. This
is especially true for QUIC because the server is limited to 3x the
client's initial flight as an anti-amplification defense [0]. However, in
practice, most server certificate chains will fit within a single QUIC
flight, as documented in this post by Patrick McManus from Fastly [1]. And
if you use RFC 8879 certificate compression you should capture almost all
of the rest. For this reason, it seems unlikely that the TLSA approach you
propose would significantly decrease setup latency.

This is not to say that there is no room for improving latency via keying
material in the DNS, but the purpose of that would be to allow the client
to send data in its first flight (aka "zero-RTT priming"), not to reduce
the size of the server's first flight.


P.S.  Mike writes "TLS could be extended to allow clients to cache server
certificates." This already exists (
but in terms of applicability it has a lot of overlap with resumption.
[0] By contrast for TLS over TCP, the server has already confirmed the
client's IP and so it can use a larger initial window.

On Tue, Apr 20, 2021 at 10:20 AM David Schinazi <>

> Cutting down the number of packets was never a goal for QUIC.
> The goal was to save round trips in connection establishment,
> as that significantly impacts user-visible latency. The number of
> packets only slightly increases the probability of loss during the
> handshake which can be correlated to user-visible latency, but
> much less.
> I'm not saying that a 3-packet handshake would be bad, I'm saying
> that it's not worth boiling the ocean to remove 2 packets. I'll also
> note that your proposal doesn't fully reduce the number of packets
> because you still need a DNS TLSA request and response, and loss
> of those is much worse as DNS retransmissions are less optimized.
> David
> On Tue, Apr 20, 2021 at 10:15 AM Michael Thomas <> wrote:
>> On 4/20/21 10:07 AM, David Schinazi wrote:
>> Hi Mike,
>> I read your blog post, and I failed to find what problem you're trying to
>> solve.
>> 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
>> solve,
>> 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.
>> I thought the entire point of QUIC (aside from HoL blocking) was to cut
>> down the number of packets needed to start a connection. From what I can
>> tell, it takes it from an 8 packet exchange to a 5 packet exchange. If you
>> were to use a DANE-like solution that would be a 3 packet exchange most of
>> the time. Why is a 5 packet exchange good but a 3 packet exchange not?
>> Mike
>> David
>> 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