Re: Quic: the Elephant in the Room

Michael Thomas <> Mon, 19 April 2021 21:02 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 847F43A26A9 for <>; Mon, 19 Apr 2021 14:02:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0.149
X-Spam-Status: No, score=0.149 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_NONE=-0.0001, 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 HWy8dXP0x2Bs for <>; Mon, 19 Apr 2021 14:02:31 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::102c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 0A1803A26A6 for <>; Mon, 19 Apr 2021 14:02:30 -0700 (PDT)
Received: by with SMTP id f2-20020a17090a4a82b02900c67bf8dc69so21135304pjh.1 for <>; Mon, 19 Apr 2021 14:02:30 -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=QLNxgB2xF0H+pD79nHMk67B4Rvf9BcIxwQYGiPQV5Dk=; b=Lknq3G9ivLEZDCE0QSAY39bawcx+euQWU9irs3WENbHBTtMtf/w0wjezFvxG+H6j4J zKPYUBfKkKal19XZUpyCKTR06dZaWpSOIeUbYHe+n1VRQbC5vN7au3EfXVvIb4AmwKkb nQnAA9cxZoY7ABGFVzpUyHZjmN2NwJtoHQCkTbFK5a9FVw2kMyxJPShkvlCBjQG5QJM9 Fv+HEjMg466nAHnxQcPkx9HGZMj+JklTHqZOlT5AQJMbxEeCi2UWqb9ED+cD+jGD5bGC LpXjR5xTnCGt9ec4F7550yXyFXjAA0kxZSSMRg7LeFXlAQ/9/Waoey3L1KgoKV49j3WA tQ9A==
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=QLNxgB2xF0H+pD79nHMk67B4Rvf9BcIxwQYGiPQV5Dk=; b=ftFHScJ75Sbmsc59ZK6VXwreHMJiAPBsrUC2P1d8ZbSNucuS+yarlLVYMMyI+hfP+K zvtb/zxZoJi9J+0I5Pvne8sWsOo+vDKck5vofalf7VGX89mfUo41ECggKZR3wKmCdjEs wUN3qKrHEOaYhOIBhH6LE+ta2WkbPTFRbdOsGPO2MlonPYlIzHRNUzhJKPJ8osAtZY3a hQyOv8cd4LD4yRGsiv0gaB6awQbDZWsgBcWCJAZvEeVW1l5kHznCD6oUhFeLyEteuOp6 APGJS57gSOWyQYfujcCoWr2Qnm+181WeRtsicVzMbodGLPusNH8QeGpLstdukkPazecu yc+Q==
X-Gm-Message-State: AOAM530MRWCHIBgSfXf/QGzIXWkkicQwXgkl2XyzkhdJ0Sr821aI7b8R KvQv1LXdiqsDu7durIWmEUlvNYTxelhS6w==
X-Google-Smtp-Source: ABdhPJwAG6oE6gy9GmDUe73huHSAw6qYZj7kkMSMUiE5vNJAcfySN4r6tkSqZp5CvWpEi8Lq+m5x0A==
X-Received: by 2002:a17:90b:1a85:: with SMTP id ng5mr1062773pjb.116.1618866147901; Mon, 19 Apr 2021 14:02:27 -0700 (PDT)
Received: from mike-mac.lan ( []) by with ESMTPSA id z12sm4410803pfn.195.2021. (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 19 Apr 2021 14:02:27 -0700 (PDT)
Subject: Re: Quic: the Elephant in the Room
To: Matt Joras <>
References: <> <>
From: Michael Thomas <>
Message-ID: <>
Date: Mon, 19 Apr 2021 14:02:26 -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: 8bit
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 21:02:36 -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.
> 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.
Well, the overall point of my post was that it would be interesting to 
run an experiment and that Google, MS and Apple would be in a good 
position to do that. Out of  all of this I found out that Google doesn't 
DNS sign their zone which is a little shocking. But it's sort of hard to 
call DNS "out of band" since it's needed for A/AAAA records and as my 
flow showed the TLSA record could be requested at the same time as the 
A/AAAA lookup which would on average not stall the handshake (and of 
course, RR's are cached). If you wanted to be really clever, the TLSA RR 
could be stapled to the name lookup too.

When I was looking this over with Wireshark it sure seemed like it was 
mostly doing a 5 message handshake, but it was hard to make a lot of 
sense because... encrypted.

Mike, i'll check out TLS resume though