Re: Quic: the Elephant in the Room

Lucas Pardue <> Mon, 19 April 2021 22:33 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id BC1A93A4723 for <>; Mon, 19 Apr 2021 15:33:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0.054
X-Spam-Status: No, score=0.054 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, 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 w-52ppNDSHAd for <>; Mon, 19 Apr 2021 15:33:19 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::52c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id EB9A93A471F for <>; Mon, 19 Apr 2021 15:33:18 -0700 (PDT)
Received: by with SMTP id z5so6153214edr.11 for <>; Mon, 19 Apr 2021 15:33:18 -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=H+RE/3BHbmW5rSmfop1nJK4gWb9TPTKLYS3Fl1fY7eE=; b=aGsdwd9Sr51ZlO+v5OkHmqTrI40dMY3CEsgoL62u/aw/O6erG3dTjCVra5yMepTZ8t 5uLNL5h1mlDcc8F0Zf7hlD07dG8WsBNtHbv5ulR9Cp45eo7Iax9clLLBKV6YNZ+V3iJH KH+/f67ZWecyd8IIwrR3HcwyygUBl/H29juTERVD7tYk/3P/nuGv6t7gKetiVcNoKaU1 qnOgV5OK5aPrs59HHAMdu75z1by3LJ5sWLm33HIGhc3w5LDz5tj9x9NoKTMduOqN7Auh MR8JKIYO7hoLfe2DNGZVvGg1b+RvpcwrWzy5bAWb8cHCNmjpU89abl3/qAxYGMUbPcoT Ig8Q==
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=H+RE/3BHbmW5rSmfop1nJK4gWb9TPTKLYS3Fl1fY7eE=; b=PDp82ajlMNl5P45PWXysPpx0LPsrPe5t2PGji+a7VyqV83w31GDvNgemMtmNJUpXgD g9P6OYWEKH7So8mbXTEc8JCKbHS8qlEhpKRta3smqE3CQgXvxSIxtTaOQxbiSp703baT 718QNoNZReDpCtbA4LJazJYB5PoeSzh02w41ECRySVaGtK20hnJMuboyCOY4EZ6y5CTR nSaMi2I6fYgdOM91Kw6wtteqvCcQ0mmpzOz1JRG3J/ArHm95tSn4+1NY7DBE5Mx++mgK fgp+Wcw+4PsYJsjBTHGYKiXkzIF6lhAfH8JPsv1z/AewkUxHMl+0XB5NdMNU/2iXzs7S 5hGA==
X-Gm-Message-State: AOAM5304nXshajIsqzuVjkFBs9Cnwx2F7d5xfNivGqIAHJJNLWEjgH4g w7b4XJd68amyEcTnD52MYrOAaf3VtNsrwJxXbP3ectR/YZs=
X-Google-Smtp-Source: ABdhPJxHkNseU0tvhGIitoRxb8Txb/n3ig097FPpCaIlczIYUCWVFEV/c6t0RVQ0N9gHvsPmFEQl2dg6u0taIMv6xOA=
X-Received: by 2002:aa7:d15a:: with SMTP id r26mr5723310edo.283.1618871596923; Mon, 19 Apr 2021 15:33:16 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <>
In-Reply-To: <>
From: Lucas Pardue <>
Date: Mon, 19 Apr 2021 23:33:05 +0100
Message-ID: <>
Subject: Re: Quic: the Elephant in the Room
To: Michael Thomas <>
Cc: Matt Joras <>, IETF QUIC WG <>
Content-Type: multipart/alternative; boundary="00000000000078bca405c05aea31"
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: Mon, 19 Apr 2021 22:33:24 -0000

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



On Mon, Apr 19, 2021 at 11:18 PM Michael Thomas <> wrote:

> On 4/19/21 1:45 PM, Matt Joras wrote:
> > Hi,
> >
> > Note that there is a TLS feature which reduces the crypto (TLS) data
> > needed to be sent during the handshake considerably, resumption. The
> > vast majority of QUIC connections in our deployment (and TCP + TLS for
> > that matter) are resumed. In a typical resumed connection the total
> > crypto data transferred is around 500 bytes in both directions.
> > Resumption is also less CPU intensive on the server than a fresh
> > handshake.
> >
> Ok, I just looked up TLS Restore and it has the problem that it needs to
> keep fairly hard state in the typical case where there are a lot of
> servers listening. A Cloudflare blog post said that they use memcached
> which implies that they have to do a out of band lookup for the
> session-id. To my mind, it sort of begs the question of why you'd ever
> kill the transport session in the first place, but that's the browser's
> choice to make.
> That's in contrast to the DANE or client cert caching solutions which
> cache on the client side and would be fairly rarely be waiting for the
> TLSA RR, and no state of any kind is required at all in the backend. So
> I don't think this is exactly a slam dunk. That Cloudflare even wrote a
> blog post about it shows that Restore introduces operational complexity
> at the very least.
> Mike