Re: Quic: the Elephant in the Room

Matt Joras <> Mon, 19 April 2021 20:46 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 55BD43A435B for <>; Mon, 19 Apr 2021 13:46:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.198
X-Spam-Status: No, score=-0.198 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_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 E5z9whfR4MOU for <>; Mon, 19 Apr 2021 13:46:02 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 4937A3A4358 for <>; Mon, 19 Apr 2021 13:46:02 -0700 (PDT)
Received: by with SMTP id a25so27674837ljm.11 for <>; Mon, 19 Apr 2021 13:46:02 -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=XQQhTb+sxkQqwnN4Q/FBCxZ/PL+1XCrdB3Oa5LYoBuA=; b=nGCv9vOLqpBtOkasejzRfvrHYidFEskf4Y5MIe1rEE0Xj+/qAxKEyJZGD0tTgKnt0u YRN8WCe2o1QP8o2a//N7xyv6gcfWEU++fhFbsyC4AZR8EA+EHe1Yxg5ydd+5Mn48FFPS UctgOJ8O0yACIWiZ6v8R4DLmjfnhAPdDtoht01SJhTkVduN/kvO9GveTSDoX3W7T7ndr kwRAVKP8y+j4q5NDGo1L6zSl8hRVI80qLWT4WWYApgWRDu3ZW+oQ9eAmOYG8XQzbAtcG d0sdrMoLKtvUQQ9K0m1MMTuywalC3UMNWaLrOPNZBA3glli/ondyHY6gMp77XDknCg+X YW1A==
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=XQQhTb+sxkQqwnN4Q/FBCxZ/PL+1XCrdB3Oa5LYoBuA=; b=LY0Hli93ED/VPUzk9y4igWcUrjuBmLA0nwuO9GowOwtMx80tN1oNijbJE8aOcqsMzB hh4Vn0RV89M2XDaHB47Om9hq9sYF9OhYQF3CipK7eNn9pNuoBWk1OqTya3MG5GBFmI7x X9GMTfUTH8StPi/J5oGMGp7hjuOvx9ZWPE/+ACU8AchVZxZq2E4r1Ca51xPHFQwRVY7i MVF0oY2exkav7nI1DB+Sn8oAayQ/GiF1MRCuMNJs03Og53wi1EhqodsILNLGiRV9Hq42 CgyvhQpznV3dhgdVemYyjGrqn/820MePi7UJS37rQUMBsQ/EtibEvP5Ple+4DCpDjSL4 EPrw==
X-Gm-Message-State: AOAM532sgUp+CPJ9iUZ24R52HKzL4jRkDf3ThZUkS63XItihuNm+csyF /QP/9G7e91DbLNP5SUB01buSMN/I8Ye3hNCpiYfw4FV2yuM=
X-Google-Smtp-Source: ABdhPJx6NnDrRJ4OAVtN6Eopux8xZhj9aK86IEj72wXoghLnWSuSgty04Hb7ttCcURnA6QifFFlCd3PojutnyInl7Ew=
X-Received: by 2002:a2e:9597:: with SMTP id w23mr2663554ljh.270.1618865159408; Mon, 19 Apr 2021 13:45:59 -0700 (PDT)
MIME-Version: 1.0
References: <>
In-Reply-To: <>
From: Matt Joras <>
Date: Mon, 19 Apr 2021 13:45:48 -0700
Message-ID: <>
Subject: Re: Quic: the Elephant in the Room
To: Michael Thomas <>
Content-Type: text/plain; charset="UTF-8"
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 20:46:07 -0000


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

There is always an opportunity for using DNS features in a clever way
to improve things. I would say though that the complexity, especially
since it introduces out-of-band dependencies, makes it a hard sell for
someone to implement and explore without a really compelling reason
(i.e. data showing that there is a huge opportunity). Resumption makes
this particular concern a non-issue for most real world connections
and has other positive benefits.

Matt Joras

On Mon, Apr 19, 2021 at 11:34 AM Michael Thomas <> wrote:
> Hi all,
> I wrote a blog post called Quic: the Elephant in the Room and posted it
> to the ietf list which generated a lot of comments, so maybe it's
> worthwhile for this list to consider as well. The jist is getting the
> Quic startup exchange back down to a 3 way handshake and very analogous
> to the original TCP handshake. It can be implemented using a DANE-like
> approach, or could be TLS could be extended to allow clients to cache
> server certificates.
> My main purpose for writing it is because a Google-like company could
> actually implement it just like they did with Quic itself to see how it
> behaves in real life.
> Mike