Re: [quicwg/base-drafts] Clarify crypto context for Connection Close (#1818)

Kazuho Oku <notifications@github.com> Sat, 06 October 2018 03:03 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 3E9CB12F295 for <quic-issues@ietfa.amsl.com>; Fri, 5 Oct 2018 20:03:23 -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, 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] 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 4X6JbFnghxP0 for <quic-issues@ietfa.amsl.com>; Fri, 5 Oct 2018 20:03:20 -0700 (PDT)
Received: from out-3.smtp.github.com (out-3.smtp.github.com [192.30.252.194]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 99A71130DE3 for <quic-issues@ietf.org>; Fri, 5 Oct 2018 20:03:20 -0700 (PDT)
Date: Fri, 05 Oct 2018 20:03:19 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1538794999; bh=J0Cln1WUiNV71hFhFeejQQ23OkD37zHEAUFgpmjWMSM=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=qH5tx6vPKQlyPjmiWd2wH5SG2ssHdjHdb+07IrOIfGwVVcOWzSeC55G5qQJ0fiTS6 8MEqfFfMGLMgSjJXoh0wZ/uxNPf3sX3L3aJEzYO4MA2Uf63NY6seMRQw4fMhD6/nx3 1kxjMdGuNVWrOof7Ve+Lj5eVal1m3KumVuh7q7SU=
From: Kazuho Oku <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+0166e4ab955d558a8e8037192634667743e883e6f6a6405292cf0000000117cfe7f792a169ce15cb9be3@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/pull/1818/c427540971@github.com>
In-Reply-To: <quicwg/base-drafts/pull/1818@github.com>
References: <quicwg/base-drafts/pull/1818@github.com>
Subject: Re: [quicwg/base-drafts] Clarify crypto context for Connection Close (#1818)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5bb825f73d0e0_52213fcf654d45bc311413"; 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
X-GitHub-Recipient-Address: quic-issues@ietf.org
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic-issues/IFFWTId0GR__dtt5c8mHwB72yoo>
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: Sat, 06 Oct 2018 03:03:23 -0000

@mikkelfj I _think_ what the PR says is sufficient, because it an endpoint is expected to hold the Handshake key for 3 RTO after all transmission using the key has been complete. Quoting from Section 4.9 of the TLS draft:
> After all CRYPTO frames for a given encryption level have been sent and all expected CRYPTO frames received, and all the corresponding acknowledgments have been received or sent, an endpoint starts a timer. For 0-RTT keys, which do not carry CRYPTO frames, this timer starts when the first packets protected with 1-RTT are sent or received. To limit the effect of packet loss around a change in keys, endpoints MUST retain packet protection keys for that encryption level for at least three times the current Retransmission Timeout (RTO) interval as defined in [QUIC-RECOVERY]. Retaining keys for this interval allows packets containing CRYPTO or ACK frames at that encryption level to be sent if packets are determined to be lost or new packets require acknowledgment.


-- 
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/1818#issuecomment-427540971