Re: [quicwg/base-drafts] Receiver's behavior on key update (#2791)

Kazuho Oku <notifications@github.com> Mon, 17 June 2019 07:22 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 B3B861200F6 for <quic-issues@ietfa.amsl.com>; Mon, 17 Jun 2019 00:22:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.008
X-Spam-Level:
X-Spam-Status: No, score=-8.008 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_32=0.001, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, 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 478rblgFXJ3z for <quic-issues@ietfa.amsl.com>; Mon, 17 Jun 2019 00:22:18 -0700 (PDT)
Received: from out-18.smtp.github.com (out-18.smtp.github.com [192.30.252.201]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 918681200B9 for <quic-issues@ietf.org>; Mon, 17 Jun 2019 00:22:18 -0700 (PDT)
Date: Mon, 17 Jun 2019 00:22:17 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1560756137; bh=vEPEQIiiCxIJo0mZTBiYnrnEmfDY/UbYw7gAMwYVUUc=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=JTUBVcKNDaHAAm4/MntVgr9Az76EnIGkK7uaVGvzvkyD97ekta3BJAjDo17I1UN/R Orf8832Fq1PLRj3KV0lXaVtrgGZkXpIwsSG9bWBzLew6M830wRsRmwhfbgvdSTa0nO l1cRDadayEjUz+9WfTvXPhh/7YQz21EtPIWrdW9U=
From: Kazuho Oku <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJK73VTQXRMCFHGX2ATF3CRZCTEVBNHHBWLWXFE@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/pull/2791/review/250326681@github.com>
In-Reply-To: <quicwg/base-drafts/pull/2791@github.com>
References: <quicwg/base-drafts/pull/2791@github.com>
Subject: Re: [quicwg/base-drafts] Receiver's behavior on key update (#2791)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5d073fa9477d3_26f3fb6b8ccd964156530"; 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/7kUFRvuhNGFBI0W5S-ng3ozd8TY>
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: Mon, 17 Jun 2019 07:22:21 -0000

kazuho commented on this pull request.



> -discarding older keys.
-
-A receiving endpoint detects an update when the KEY_PHASE bit does not match
-what it is expecting.  It creates a new secret (see Section 7.2 of {{!TLS13}})
-and the corresponding read key and IV using the KDF function provided by TLS.
-The header protection key is not updated.
+While only one send key is used at a time, an endpoint SHOULD retain at least
+two receive keys during key update so that it can unprotect packets arriving
+out-of-order.
+
+An endpoint can detect which receive key to use by tracking the lowest packet
+number among the packets received with the currently active key phase.  If a
+packet is received that has a different KEY_PHASE bit and a lower packet number
+than this value, the endpoint uses the old receive keys for unprotecting the
+packet, if these keys are still available.  If the packet has a higher packet
+number, the endpoint installs the new receive keys by calculating the next

Ah. Thank you for the clarification. Updated the text and rearranged the following two paragraphs to better clarify when installation of the updated receive keys happen. PTAL.

-- 
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/2791#discussion_r294162982