Re: [quicwg/base-drafts] TLS application data isn't possible (#3043)

Kazuho Oku <> Tue, 17 September 2019 21:47 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 897AD1208C9 for <>; Tue, 17 Sep 2019 14:47:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.596
X-Spam-Status: No, score=-6.596 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, HTML_IMAGE_ONLY_28=1.404, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, RCVD_IN_DNSWL_HI=-5, 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 SOmp31Oi-GDE for <>; Tue, 17 Sep 2019 14:47:38 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id B3A6F120072 for <>; Tue, 17 Sep 2019 14:47:38 -0700 (PDT)
Date: Tue, 17 Sep 2019 14:47:37 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=pf2014; t=1568756858; bh=78xDEKYFVhk9SKVJRiB3KDSsYwvCCLwvptMmPA8EhNc=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=iBIp0BP/u9n8pKCEu0mjmKg1H+t4F2u6BZOCose106uKRsdctNprFuiYT9CvZQWEx 14f2lmYpTH9gmvh17X4cCwrAykvGv6CYLqn+ldGhVC3ch0pnY/NHLaGpTR8ku1oEwv zoWK8Yvo8nNxAdQqDECw7d3MHTc/bqIsOq3+H2ZQ=
From: Kazuho Oku <>
Reply-To: quicwg/base-drafts <>
To: quicwg/base-drafts <>
Cc: Subscribed <>
Message-ID: <quicwg/base-drafts/pull/3043/review/>
In-Reply-To: <quicwg/base-drafts/pull/>
References: <quicwg/base-drafts/pull/>
Subject: Re: [quicwg/base-drafts] TLS application data isn't possible (#3043)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5d815479ef4c5_6c4d3f89866cd96023802f"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: kazuho
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: Tue, 17 Sep 2019 21:47:41 -0000

kazuho commented on this pull request.

 QUIC takes the unprotected content of TLS handshake records as the content of
 CRYPTO frames. TLS record protection is not used by QUIC. QUIC assembles
 CRYPTO frames into QUIC packets, which are protected using QUIC packet
+QUIC is only capable of conveying TLS handshake records in CRYPTO frames.  TLS
+alerts are turned into QUIC CONNECTION_CLOSE error codes; see {{tls-errors}}.
+TLS application data and other message types cannot be carried by QUIC at any
+encryption level and can be treated as an error if they are received from the

This is a clarification of fact, that a TLS stack can never return application data, unless there is a bug in the TLS stack or in the way the QUIC stack uses the TLS stack.

Therefore I think that "can be treated as an error" is fine. Changing it to "is an error" would be fine too.

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