Re: Quic: the Elephant in the Room

Michael Thomas <> Mon, 19 April 2021 22:18 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 095133A46B4 for <>; Mon, 19 Apr 2021 15:18:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0.15
X-Spam-Status: No, score=0.15 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, 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 zPNDzuOCSB51 for <>; Mon, 19 Apr 2021 15:18:18 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::636]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 3292E3A46AF for <>; Mon, 19 Apr 2021 15:18:18 -0700 (PDT)
Received: by with SMTP id p16so14593586plf.12 for <>; Mon, 19 Apr 2021 15:18:18 -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-transfer-encoding:content-language; bh=HaMthlGDg6TIkAE5R0pE2ElKU4iwS63sevbOjtuYZ8o=; b=B3me2Fngbjb2vDSH/oEMcHtRcptgcju2PmUJsiwmj8v8pikEcXGJ/G3NzQd1Vkq7Qd gCeNLdmA0Nyw4yiOM7/6c17p9E/Da1pjHTsxm9hZe9iXPW5NvGi4KOpQII2Cxw54A/m2 8oWxOEIf/CLCnAJjrG6S0ODEcugCAMWOVapt4b7IvHVoI5sCl/08bXpJqZzSByEEONxi LBVijJmtDILlSLFyQQg/LKxBZx1Ujmfv0JYUxVtQrNJQeoLuu3kLtXJaKmE39VLarh4I SO8JSlU1S4P0f7kug0xOOlkw/9wWnY9G4g+z5bMtWl+NdYgfQxUcd+Sr7Y64c2Ycb8M6 4tZA==
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-transfer-encoding :content-language; bh=HaMthlGDg6TIkAE5R0pE2ElKU4iwS63sevbOjtuYZ8o=; b=YvdhYu/I4RZiXAYrI2GPGssYKnz9CRCxPCynnYaOmXh3CT/VJ3D9IyymS2DkK63qsZ 5mr+fhdICShNy6ivDl5VzKYfy3ulxcWG8BwURqakkbRr7l/TWhKHIhj7VvcXIObQBT17 x++uRcFlPN/cSL+IRfNEWU5Y+33ZkPdf0NYGOp539ULxcmHmP8dsr/vPE8SGOopGn8Gn Yp0+MsfqEMGr77F3gP8mWf3e181/A8JPS1STx08Owr1H60SWvZrh84I4JSfdjpGfhyDZ nI3prMgLmjt7whhAL7FrMtr4kryoTdt2iBXAS+i/vLIXeQWXFCF7EQeCxhc4CsbadgSC UAxg==
X-Gm-Message-State: AOAM532200wHjs0IXdXo9WCt9tHWUqbIWRlJSyYpulvV1wR9PoLBFp8A ShRbKiBaj/KXcOU1qCkTMQ1rfCfTuG5vPg==
X-Google-Smtp-Source: ABdhPJz/4KqM9GVSoTRHvUsRP4I6ZsYasQWkDDkgoBZ87HBGXkBGQSwqXaSg035eOmWt1x3eIuuEAg==
X-Received: by 2002:a17:90b:1d92:: with SMTP id pf18mr1372880pjb.71.1618870697298; Mon, 19 Apr 2021 15:18:17 -0700 (PDT)
Received: from mike-mac.lan ( []) by with ESMTPSA id 18sm12715249pfu.190.2021. (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 19 Apr 2021 15:18:16 -0700 (PDT)
Subject: Re: Quic: the Elephant in the Room
To: Matt Joras <>
References: <> <>
From: Michael Thomas <>
Message-ID: <>
Date: Mon, 19 Apr 2021 15:18:15 -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: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 7bit
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: Mon, 19 Apr 2021 22:18:29 -0000

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.