Re: Quic: the Elephant in the Room

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

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id CE0953A4753 for <>; Mon, 19 Apr 2021 15:39:17 -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 bQJt4NcZ8RLd for <>; Mon, 19 Apr 2021 15:39:13 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::634]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 37F263A4752 for <>; Mon, 19 Apr 2021 15:39:13 -0700 (PDT)
Received: by with SMTP id e2so14266290plh.8 for <>; Mon, 19 Apr 2021 15:39:13 -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=lWhLVJhXEWwTHF40pszno2dBqTh0Pe+0KyH4+l2bjVU=; b=WK2pKuVEOYWe3Qzz0ikesN8oqvFA/53WWZonOC+LA9gm/nOShi+u+5Aq7ORdZhQSlV XD4AgCpS6XsC3P9My+dx/mL29DCOctAscR3pFmOc83tBD7xfZ+Ju7nFkJ9mxZb1acLlK A69E51FV6S6QGogNQbF/yuRhB3HPALBcwN2CR2ai2ox+sG0lLbRq+EGqY7hBDfNdLSKo Qi9TK6gDBSwgeIPsX4HPaQzmM9LKL5Hg+Aa6wSih5s3TrIQC2vCBMI+eWzqIh7Pa+DcY 3paxwttDO4DluMKSx402M8Gs/uBkPTWKo/41g4+yqYppZNaz3uwhDzPVCkKma7WRGU9a p1NA==
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=lWhLVJhXEWwTHF40pszno2dBqTh0Pe+0KyH4+l2bjVU=; b=XBpWa/FrV9v9HBhwqmmvNFMqNq8Z0DPMF51QK4JYOTVPvRuKKoopJfdKTrvjH1Yo/e 7EUaLcE4/MHz38dpPSjkOR2vp3vgQsjM3i1g1jpyVbT0yYGFVq4pvlM2242sCvIe3nIw odgJrBNUak1wKOMFwHZJHxLJjjx0XsYTgAREX3lohYcpYwxqpjIbH86/gZvZCc8BEfP4 4Zbvp0TvNFN1Oz6lKQIQ6EZ3wYxn8LuuuleIPTnTo2DVfdPmdD9FGSv/wxMzBGfqavQ1 VcX2q63YyTBhL3r8BaMNRZWbbL0sOVAN7tZisI2kGHVsV1YENp4yBxemR9DJOfyywPVW KopA==
X-Gm-Message-State: AOAM533YR5eIlSrFhhZYqD3Ch85/EQ0Zs+M+eLrBYj8hlOCVtamEHEpD Ig/kvuBqjl1hsO4l2qYm7BafLL189q9WiQ==
X-Google-Smtp-Source: ABdhPJxmvqrSZCKb5brkJCt74BQ7uHS3SP9xvyoayaSgkBbTtjPwYJwaP2ww0fnvxpaOOEZMZXe12Q==
X-Received: by 2002:a17:90a:6582:: with SMTP id k2mr1447354pjj.11.1618871951667; Mon, 19 Apr 2021 15:39:11 -0700 (PDT)
Received: from mike-mac.lan ( []) by with ESMTPSA id q135sm7519885pfc.26.2021. (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 19 Apr 2021 15:39:11 -0700 (PDT)
Subject: Re: Quic: the Elephant in the Room
To: Lucas Pardue <>
Cc: Matt Joras <>, IETF QUIC WG <>
References: <> <> <> <>
From: Michael Thomas <>
Message-ID: <>
Date: Mon, 19 Apr 2021 15:39:09 -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:39:18 -0000

On 4/19/21 3:33 PM, Lucas Pardue wrote:
> 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 consideration.
I'm not asking this working group to do anything. Just socializing 
something that generated a lot of discussion on the IETF list that might 
be of interest to the Quic community.