Re: [quicwg/base-drafts] Merge crypto timeout into PTO (#2655)

Jana Iyengar <notifications@github.com> Sun, 28 April 2019 07:07 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 B8D75120094 for <quic-issues@ietfa.amsl.com>; Sun, 28 Apr 2019 00:07:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8
X-Spam-Level:
X-Spam-Status: No, score=-8 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_32=0.001, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] 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 znMbD1Rtt09b for <quic-issues@ietfa.amsl.com>; Sun, 28 Apr 2019 00:07:43 -0700 (PDT)
Received: from out-6.smtp.github.com (out-6.smtp.github.com [192.30.252.197]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0F123120092 for <quic-issues@ietf.org>; Sun, 28 Apr 2019 00:07:43 -0700 (PDT)
Date: Sun, 28 Apr 2019 00:07:41 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1556435261; bh=HvAMvfiAl4JlvQBA+Y8YB+nPHYBxc2m1jxNwMllqDgc=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=DIVYxmknT6DyGzHPIctp05zTqXuf9K0mmyNeTFo69UjBakNiQ9PdJ3+tNBFFlBb+C yPOB04oBeuCs2Smwsu2bS6pdIEBRDlTftIOvaJRSxwh0JrkP8j9iHadNWPcKk6oKIx cFVDn3xqt+Zz2wRFl3AhQv5qO8uPRSnrT0ktah0o=
From: Jana Iyengar <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJK42NOR62YLXDKMGLPF22KB33EVBNHHBUGOXBA@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/pull/2655/review/231452207@github.com>
In-Reply-To: <quicwg/base-drafts/pull/2655@github.com>
References: <quicwg/base-drafts/pull/2655@github.com>
Subject: Re: [quicwg/base-drafts] Merge crypto timeout into PTO (#2655)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5cc5513dd1dd9_3d303feb99ecd960313748"; charset=UTF-8
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: janaiyengar
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/nAdXMe5qlMmHU8TfC8x5-Z84Xwg>
X-BeenThere: quic-issues@ietf.org
X-Mailman-Version: 2.1.29
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: Sun, 28 Apr 2019 07:07:45 -0000

janaiyengar commented on this pull request.



> +the count of bytes in flight.
+
+Endpoints stop sending and receiving Initial packets once they start exchanging
+Handshake packets (see Section 17.2.2.1 of {{QUIC-TRANSPORT}}). At this point,
+recovery state for all in-flight Initial packets is discarded.
+
+When 0-RTT is rejected, recovery state for all in-flight 0-RTT packets is
+discarded.
+
+If a server accepts 0-RTT, but does not buffer 0-RTT packets that arrive
+before Initial packets, early 0-RTT packets will be declared lost, but that
+is expected to be infrequent.
+
+It is expected that keys are discarded after packets encrypted with them would
+be acknowledged or declared lost.  Initial secrets however might be destroyed
+sooner, as soon as handshake keys are available (see Section 4.10 of

This is pre-existing text, not new to this PR. The point however here isn't that you discard keys based on declaring packets lost, but that it is generally expected to be the case that packets are already declared lost (or acked) by the time keys are discarded.

-- 
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/2655#discussion_r279180560