Re: Quic: the Elephant in the Room

Michael Thomas <> Wed, 21 April 2021 01:10 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id F14D43A0F2E for <>; Tue, 20 Apr 2021 18:10:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.749
X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id dGB0a1wh8Vsy for <>; Tue, 20 Apr 2021 18:10:18 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::530]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 43BF53A0F0E for <>; Tue, 20 Apr 2021 18:10:18 -0700 (PDT)
Received: by with SMTP id p2so12700197pgh.4 for <>; Tue, 20 Apr 2021 18:10:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=fluffulence; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=870HaHiR4iw1lhGL2WCn7hozIia5XAeyR51No/4lvJs=; b=ZqGgxvJAl5BIt5TQGgpdEBeVyR3MksxJV/RVWX5FIelIOM0qwBWMf4lYOR6Tb8OO9H eY/j9eM4wpDtAjIfZVV9zlqFT7kb8a8yvvjAtdGeCUD93aV6UQ0cUSMtNe4FcN7ngifZ AR+LznrTPdyPsNenq/mhXYFdkKPmQqJk9ZhhnqJVR6samxDXLXBbWX3GP+JAqN6LAWko A9Kv6eRxvC1SIfb8dAT0RIYKWFMwZP+c24E2KCwfP3rrkZIsTFFP14YCNqgxyBrdY2p3 WFVxe82vWjay5Ivj0eJMBEO/lOZwU+AJIplAxTllLJ3JnhdDb6DTjYBExZbkmZvzsSCP Cdjg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=870HaHiR4iw1lhGL2WCn7hozIia5XAeyR51No/4lvJs=; b=I2u+Dzl7vpr/fOuDqbRNmFyI11Y/qrB4svi/IBJnMQ+h28OwJ+mRoITVAFxM0SVsXH qBqUwX8i4h6maxU+Lov6oHB+7M3mY4oClZScOfRTEBUM5ZhUqo9QCo3XlIvXO94q4jGo wD9aebpdpT4KHNVFTn9hOQXn7X1BB2E1UX7TvnmQrZeS7E1H7QLYHxj+SWlgFN2wc9sn l30rf8zGtjifynLYo6XdTECasaHc7WJaQKgMSqfLuXax9UACc+doum7JFGOmFY1ep0FJ /hhN6biVrEBIxfcRcTc0klM1CpUMTzBcvhhg6BE4m8wpJIu2Bnu0C8RK8sGJndIA+9GG p3bA==
X-Gm-Message-State: AOAM533weDQWQNwGhH/1Zy+187kdx+mHvjRHd5OXymJCIovlun3XpnSx vIPssu8c8yuxk3ba+5kh8lx24uz9lI35Jg==
X-Google-Smtp-Source: ABdhPJxoPXYosMzVPubyCchTvjqdrQRgARx5LEgmVT227g2oSIsOMXURCXdHblyGXBXI3wyfGn2CIA==
X-Received: by 2002:a63:e206:: with SMTP id q6mr19465761pgh.225.1618967417066; Tue, 20 Apr 2021 18:10:17 -0700 (PDT)
Received: from mike-mac.lan ( []) by with ESMTPSA id k21sm202422pfi.28.2021. (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 20 Apr 2021 18:10:16 -0700 (PDT)
Subject: Re: Quic: the Elephant in the Room
To: Phillip Hallam-Baker <>, Eric Rescorla <>
Cc: David Schinazi <>, Matt Joras <>, IETF QUIC WG <>, Lucas Pardue <>
References: <> <> <> <> <> <> <> <> <> <>
From: Michael Thomas <>
Message-ID: <>
Date: Tue, 20 Apr 2021 18:10:14 -0700
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.9.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: multipart/alternative; boundary="------------70BE88DB7D524DD0B9B5611E"
Content-Language: en-US
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: Wed, 21 Apr 2021 01:10:23 -0000

On 4/20/21 5:43 PM, Phillip Hallam-Baker wrote:
> On Tue, Apr 20, 2021 at 4:18 PM Eric Rescorla < 
> <>> wrote:
>     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
> If you win at Pinball, you get to play again.
> I decided not to engage in QUIC fairly early on. Not because I didn't 
> have any relevant ideas but because the scope was already large and my 
> ideas would tend to make it larger when was needed was to make it 
> narrower.
> As the work continued, I realized that QUIC is very different from TLS 
> and TCP: We don't have to try to make one size fits all. We can have 
> separate transports optimized for Browsing, RTC and transactional 
> services.

This is a picture perfect example of the power hungry working group 
chairs executing the infidels that have been the subject of many recent 
talks on the IETF list. this is exactly why nobody wants to work with 
the IETF. I predicated this on the IETF list with Keith Moore and turned 
out exactly as I expected. And it took less than 24 hours. Thanks for 
making my point Lucas Purdue. You are part of the problem, not part of 
the solution.