Re: Quic: the Elephant in the Room

Phillip Hallam-Baker <> Wed, 21 April 2021 00:43 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 169483A0CAB for <>; Tue, 20 Apr 2021 17:43:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.4
X-Spam-Status: No, score=-1.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 yG4CmG9M9kk9 for <>; Tue, 20 Apr 2021 17:43:24 -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 9C43B3A0CAE for <>; Tue, 20 Apr 2021 17:43:24 -0700 (PDT)
Received: by with SMTP id y2so43134897ybq.13 for <>; Tue, 20 Apr 2021 17:43:24 -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=cvv3Y/FwXATMkKX6SPGdkz2PUoamvQByi63S4m2LFwQ=; b=g6gZIEMItPXTNbTzhBniF26jkabD0mhrFpxcv2qEgi2zW/oNsN4GLkI9g6X2Iyx6Om Sz6O3deNWSufN3MQ9za+eEfW+STN/UO9RszHRN0fzamaW2MztaKkAdW8GNWMgm/7Yaes h2cxN+y5pL0TgTvPkVTb0KxLW4ikNt8slGgE3LBUzUtpiK3iphuQuOtiTJikbSCnjnNn ebzQNCEBXBMIDKvC12CYFoTD+I8cfoC2xjH/og5NzQ+rqGZGZyQ6is6VzybbUYVqyRVr Kl3HPCNdlDMEoEi+BSIK0RM6JwIWXY7hTPKDl5ifw04C+/qrStkaW8i9TWbKqaSIy/bV tTZA==
X-Gm-Message-State: AOAM530Kio/7j17lLBz6icr48a5UjndOLoXWc8D1CFuxOP6jx1CYNzBp f0E9KW0pB2vJFqpnT7nK8F6IqrplmMZfvgoc2UfuUr/sVqY=
X-Google-Smtp-Source: ABdhPJwtGPu1kWo5f1AopE6GY6aS1BxL/wUHz4RwOgbD/NsuxuQ11dbFr1Thu+TPYfMH5W0K9RzDUqofk40ngt+dZBA=
X-Received: by 2002:a5b:48c:: with SMTP id n12mr30163123ybp.273.1618965803501; Tue, 20 Apr 2021 17:43:23 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
From: Phillip Hallam-Baker <>
Date: Tue, 20 Apr 2021 20:43:11 -0400
Message-ID: <>
Subject: Re: Quic: the Elephant in the Room
To: Eric Rescorla <>
Cc: David Schinazi <>, Michael Thomas <>, Matt Joras <>, IETF QUIC WG <>, Lucas Pardue <>
Content-Type: multipart/alternative; boundary="0000000000009f09db05c070d969"
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 00:43:29 -0000

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.

There are now several people who have various prototypes of non-QUIC UDP
transports. Rather than discuss them here in QUIC, it would make more sense
to discuss them elsewhere, such as in an IRTF group. Some parts of QUIC are
probably re-usable, I plan to reuse the recovery scheme albeit with changes
to allow for my rather different approach to encryption.

Changing the PKI to save a few packets seems like the wrong move to me. We
should be bolder. If paying $30/yr for a certificate was an unacceptable
outrage, we should treat $10/yr for a domain name in like manner. $0.10
with no renewal fee ever seems fairer to me. If you build out a naming
scheme and a PKI at the same time, you don't need validation.