Re: [quicwg/base-drafts] Describe inputs to TLS more clearly (#4011)

Marten Seemann <> Wed, 02 September 2020 02:42 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id CCAD73A0A8F for <>; Tue, 1 Sep 2020 19:42:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.697
X-Spam-Status: No, score=-1.697 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_IMAGE_ONLY_28=1.404, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id bRm-56kTEs-g for <>; Tue, 1 Sep 2020 19:42:57 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 5C9D73A0A93 for <>; Tue, 1 Sep 2020 19:42:57 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 348DFE0DA1 for <>; Tue, 1 Sep 2020 19:42:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=pf2014; t=1599014576; bh=sEJUDYsxR6DlvqkIATDiWa/zS2z/CmAN0ue4WqmEj8Y=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=DaY39+4mSlXkQ16w3rrs26p2neUBa1ueK/h/zcA9PvfhOXXJusLedoodGV/sFF6e4 zYI0lw44xB8k97ZEVNY6tPTlzk36u5uFshK9zv2PVW0nwe5Bb+0Nsz4HzHLmAH5LTH SM0UaOEyEsonCGwj3bwESv3nYwsrRB/k4CQ4JbaQ=
Date: Tue, 01 Sep 2020 19:42:56 -0700
From: Marten Seemann <>
Reply-To: quicwg/base-drafts <>
To: quicwg/base-drafts <>
Cc: Subscribed <>
Message-ID: <quicwg/base-drafts/pull/4011/review/>
In-Reply-To: <quicwg/base-drafts/pull/>
References: <quicwg/base-drafts/pull/>
Subject: Re: [quicwg/base-drafts] Describe inputs to TLS more clearly (#4011)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5f4f06b0236e6_452a19646823ba"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: marten-seemann
X-GitHub-Recipient: quic-issues
X-GitHub-Reason: subscribed
X-Auto-Response-Suppress: All
Archived-At: <>
X-Mailman-Version: 2.1.29
List-Id: Notification list for GitHub issues related to the QUIC WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 02 Sep 2020 02:42:59 -0000

@marten-seemann approved this pull request.

> -available.  If the keys are generated asynchronously, an endpoint MAY continue
-responding to the received packets that were processable while waiting for TLS
-to provide these keys.
+QUIC that reading or writing keys at that encryption level are available.
+The events that cause new keys to be available are not asynchronous; they
+always occur after TLS is provided with inputs. TLS only provides new keys
+after being initialized (by a client) or after being provided with new
+handshake data.
+However, a TLS implementation could perform some of its processing
+asynchronously. In particular, the process of validating a certificate can take
+some time. While waiting for TLS processing to complete, an endpoint SHOULD
+buffer received packets if they might be processed using keys that aren't yet
+available. These packets can be processed once keys are provided by TLS. An
+endpoint MAY continue to respond to packets that can be processed during this

endpoint SHOULD continue to respond to packets that can be processed during this

You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub: