Re: [quicwg/base-drafts] Separate key/secret availability from usage (#1654)

Christian Huitema <notifications@github.com> Tue, 14 August 2018 01:32 UTC

Return-Path: <noreply@github.com>
X-Original-To: quic-issues@ietfa.amsl.com
Delivered-To: quic-issues@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C1C5130E58 for <quic-issues@ietfa.amsl.com>; Mon, 13 Aug 2018 18:32:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.01
X-Spam-Level:
X-Spam-Status: No, score=-8.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=github.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sgJ6hnwGH_dX for <quic-issues@ietfa.amsl.com>; Mon, 13 Aug 2018 18:32:35 -0700 (PDT)
Received: from out-1.smtp.github.com (out-1.smtp.github.com [192.30.252.192]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 192F212F1AC for <quic-issues@ietf.org>; Mon, 13 Aug 2018 18:32:35 -0700 (PDT)
Date: Mon, 13 Aug 2018 18:32:34 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1534210354; bh=FQYBA9e4rzwTZxcOT/0ak3T1n8wK4iXTC/M2Q/6qQAA=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=j/Fmq8uapCFkwFSvhaHNK7DeGoiAVzxOj/ein8r5KMrAiunUZWYxsSad4JEoOeKAt tjlBdSQsZCH9E4zs2X+EEg9fMHOKMB7C2lPP+5qV+ZIy7S5ncqefFneBKwvch9xGHp p92HsYBY9sz5XxVHx3Du7twY83PkOjKN7DXWtY20=
From: Christian Huitema <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+0166e4abfa3b2465a0904ebaba4abf594f5a63fc8691b40d92cf000000011789f33292a169ce14db09b1@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/pull/1654/review/145891705@github.com>
In-Reply-To: <quicwg/base-drafts/pull/1654@github.com>
References: <quicwg/base-drafts/pull/1654@github.com>
Subject: Re: [quicwg/base-drafts] Separate key/secret availability from usage (#1654)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5b72313252ae1_4b4a3fedc46be620176288"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: huitema
X-GitHub-Recipient: quic-issues
X-GitHub-Reason: subscribed
X-Auto-Response-Suppress: All
X-GitHub-Recipient-Address: quic-issues@ietf.org
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic-issues/GOyiuUHILL14MplSjRR4qgdNfY0>
X-BeenThere: quic-issues@ietf.org
X-Mailman-Version: 2.1.27
List-Id: Notification list for GitHub issues related to the QUIC WG <quic-issues.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/quic-issues>, <mailto:quic-issues-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/quic-issues/>
List-Post: <mailto:quic-issues@ietf.org>
List-Help: <mailto:quic-issues-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/quic-issues>, <mailto:quic-issues-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 14 Aug 2018 01:32:37 -0000

huitema commented on this pull request.



> -CRYPTO frame in Handshake encryption) may send STREAM data (in 1-RTT
-encryption). However, if the Finished is lost, the client would have to
-retransmit the Finished, in which case it would use Handshake encryption.
-
+Although TLS only uses one encryption level at a time, QUIC may use more than
+one level. For instance, after sending its Finished message (using a CRYPTO
+frame at the Handshake encryption level) an endpoint can send STREAM data (in
+1-RTT encryption). If the Finished message is lost, the endpoint uses the
+Handshake encryption level to retransmit the lost message.
+
+In particular, server implementations need to be able to read packets at the
+Handshake encryption level before the final TLS handshake message at the 0-RTT
+encryption level (EndOfEarlyData) is available.  Though the content of CRYPTO
+frames at the Handshake encryption level cannot be forwarded to TLS before
+EndOfEarlyData is processed, the client could send ACK frames that the server
+needs to process in order to detect lost Handshake packets.
 

I may be suffering from excess of caution, after spending some time debugging the out of order EOED issue. But yes, the explicit mention of out of order EOED and need to reorder is there, so I guess I the text is fine.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/1654#discussion_r209806927