Re: [quicwg/base-drafts] Output of the discard keys design team (#2673)

Martin Thomson <notifications@github.com> Wed, 08 May 2019 00:26 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 3F0E512013A for <quic-issues@ietfa.amsl.com>; Tue, 7 May 2019 17:26:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.606
X-Spam-Level:
X-Spam-Status: No, score=-6.606 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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_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 AF9JtY_IcLQx for <quic-issues@ietfa.amsl.com>; Tue, 7 May 2019 17:26:04 -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 1B269120073 for <quic-issues@ietf.org>; Tue, 7 May 2019 17:26:04 -0700 (PDT)
Date: Tue, 07 May 2019 17:26:03 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1557275163; bh=8hHuaQoIWqBSF/bg3gkj728TT2E2Pb1FVKwxjMo4PqU=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=p+bltdF79e5FzZbaNKCW2fUpJDrw2XgTQFYxV6eeU4URiJFxCkNyTxo9ZkL9TFXbv JpF+gzR3Mp1uQqLHNXy5NN0TTC/KXtr5p2S5UFq9M0vfw41gV8l9+u++KWJvGiBdD2 4+ILOPfqQZ0WnRHHnMFJTnTcL8mh8rTKU5us3xVc=
From: Martin Thomson <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJK5JTD2T4LDZCQXS55N235KJXEVBNHHBUUAEMU@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/pull/2673/review/234819197@github.com>
In-Reply-To: <quicwg/base-drafts/pull/2673@github.com>
References: <quicwg/base-drafts/pull/2673@github.com>
Subject: Re: [quicwg/base-drafts] Output of the discard keys design team (#2673)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5cd2221b1ab2c_1ed43fe7674cd964963fb"; 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-GitHub-Recipient-Address: quic-issues@ietf.org
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic-issues/-1IX4zoqyooPjy7zZ1iDdDWCSgU>
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: Wed, 08 May 2019 00:26:06 -0000

martinthomson commented on this pull request.



> @@ -1116,9 +1147,20 @@ TLS KeyUpdate message.  Endpoints MUST treat the receipt of a TLS KeyUpdate
 message as a connection error of type 0x10a, equivalent to a fatal TLS alert of
 unexpected_message (see {{tls-errors}}).
 
-An endpoint MUST NOT initiate more than one key update at a time.  A new key
-cannot be used until the endpoint has received and successfully decrypted a
-packet with a matching KEY_PHASE.
+An endpoint MUST NOT initiate the first key update until the handshake is
+confirmed ({{handshake-confirmed}}). An endpoint MUST NOT initiate a subsequent
+key update until it has received an ACK for a packet sent at the previous
+KEY_PHASE.  This can be implemented by tracking the lowest packet number sent
+with the previous KEY_PHASE, and the highest value of the Largest Acknowledged
+field in any received 1-RTT ACK frame: once the latter is higher than the
+former, another key update can be initiated.
+
+Endpoints only need to maintain the two latest sets of packet protection keys

Ahh, my bad.  I added the wrong implication.

```suggestion
Endpoints MAY limit the number of sets of keys they retain to two sets
for removing packet protection and one set for protecting packets.  Older
keys can be discarded.  Updating keys multiple times rapidly can cause
```



-- 
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/2673#discussion_r281876435