Re: [quicwg/base-drafts] Minor nits (#1800)

Martin Thomson <> Wed, 26 September 2018 15:46 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id F1F48130EAB for <>; Wed, 26 Sep 2018 08:46:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.456
X-Spam-Status: No, score=-3.456 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.456, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, RCVD_IN_DNSWL_NONE=-0.0001, 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 z7E3P6JywyvH for <>; Wed, 26 Sep 2018 08:46:42 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 9EE86124BE5 for <>; Wed, 26 Sep 2018 08:46:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed;; h=from:reply-to:to:cc:in-reply-to:references:subject:mime-version:content-type:content-transfer-encoding:list-id:list-archive:list-post:list-unsubscribe; s=s20150108; bh=mnCAcjpMz55KWqQQ2Tyxek3IYRs=; b=Qly7Z+DdgVlisbZF f0HPcayrtfGnTvt3/07/dQuJZH06oVojKvz7L148SoJpYxy5X70BgiveOUBjRqjO J/UXVLtAEtFusSsNXrTDTmG369yedEtwt8xNSLTyDd48IRoSkvTPYzBKtqZ8764t qyBxaR5nzvEZZEg76nuKrjYUUKQ=
Received: by with SMTP id filter1696p1mdw1-3072-5BABA9DF-30 2018-09-26 15:46:39.791508738 +0000 UTC m=+1707295.013990203
Received: from (unknown []) by (SG) with ESMTP id rEXu4WnFR-ScEz6nQjLwVQ for <>; Wed, 26 Sep 2018 15:46:39.764 +0000 (UTC)
Received: from (localhost []) by (Postfix) with ESMTP id B3D40401143 for <>; Wed, 26 Sep 2018 08:46:39 -0700 (PDT)
Date: Wed, 26 Sep 2018 15:46:40 +0000
From: Martin Thomson <>
Reply-To: quicwg/base-drafts <>
To: quicwg/base-drafts <>
Cc: Subscribed <>
Message-ID: <quicwg/base-drafts/pull/1800/review/>
In-Reply-To: <quicwg/base-drafts/pull/>
References: <quicwg/base-drafts/pull/>
Subject: Re: [quicwg/base-drafts] Minor nits (#1800)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5baba9dfabb01_775b3fb77d0d45c02131b4"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: martinthomson
X-GitHub-Recipient: quic-issues
X-GitHub-Reason: subscribed
X-Auto-Response-Suppress: All
X-SG-EID: l64QuQ2uJCcEyUykJbxN122A6QRmEpucztpreh3Pak2st0vm06nSXGNubcqi8o5pqFATOFPZbEk2jh Uqq2HDw/dvEk5eIvbiRwXB5utQVvLftFOZJ3BdG0mCDM63K8hyPh8cOe0Byf3reGCQn1ygfxxr7yAD t3zYsUKWyklIf5k6c54oRv4pGiXAnEtAI6bGEUUK0OqzZ6LEypb3xxNjLZb4so+qvrNwvOPH2QP8V6 Q=
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, 26 Sep 2018 15:46:45 -0000

martinthomson commented on this pull request.

> @@ -387,6 +392,10 @@ peer in CRYPTO frames. When TLS provides handshake octets to be sent, they are
 appended to the current flow and any packet that includes the CRYPTO frame is
 protected using keys from the corresponding encryption level.
+Unlike its operations with TCP, the TLS bytestream is never separately
+encrypted and decrypted. This operation only occurs on the QUIC packet as a

I know what you are saying, but it's equally confusing because it's not clear what the TLS bytestream is.  For QUIC, it's the sequence of TLS handshake messages, but TLS has other concepts that could be considered to be a bytestream: the sequence of TLS records (unencrypted), or the sequence of protected TLS records could very much be considered to be a bytestream.

Maybe the right thing to say here is that "QUIC takes the unprotected content of TLS handshake records as the content of CRYPTO frames.  Encapsulation of these messages in protected TLS records does not happen.  QUIC assembles CRYPTO frames into QUIC packets, which are protected using QUIC packet protection."

But isn't that written down elsewhere?

> @@ -320,14 +322,17 @@ Each encryption level has a specific list of frames which may appear in it. The
 rules here generalize those of TLS, in that frames associated with establishing
 the connection can usually appear at any encryption level, whereas those
 associated with transferring data can only appear in the 0-RTT and 1-RTT
-encryption levels
+encryption levels.

I think you want a colon:

> @@ -161,6 +161,9 @@ series of typed TLS records. Records are individually cryptographically
 protected and then transmitted over a reliable transport (typically TCP) which
 provides sequencing and guaranteed delivery.
+Note that Change Cipher Spec records, optional in TLS over TCP, have no
+encoding for TLS over QUIC.

I would say simply "Change Cipher Spec records cannot be sent in QUIC."

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