[quicwg/base-drafts] MAX_KEY_UPDATES frame (yet another proposal to solve the key retirement problem) (#2504)

Kazuho Oku <notifications@github.com> Fri, 08 March 2019 03: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 []) by ietfa.amsl.com (Postfix) with ESMTP id 5B755131071 for <quic-issues@ietfa.amsl.com>; Thu, 7 Mar 2019 19:22:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8
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_MESSAGE=0.001, MAILING_LIST_MULTI=-1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=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 ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id ROGAFpUcXenD for <quic-issues@ietfa.amsl.com>; Thu, 7 Mar 2019 19:22:35 -0800 (PST)
Received: from out-7.smtp.github.com (out-7.smtp.github.com []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AA9A712F1AC for <quic-issues@ietf.org>; Thu, 7 Mar 2019 19:22:35 -0800 (PST)
Date: Thu, 07 Mar 2019 19:22:34 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1552015354; bh=CNCUJLPpnrFsQ8sbyl0g/6geC/HwKyEorqtnoXX4fPs=; h=Date:From:Reply-To:To:Cc:Subject:List-ID:List-Archive:List-Post: List-Unsubscribe:From; b=bIseb1ZKAgSitV4EXZDnwb6LvfwSsEbTX82lbn0sYwRosqX8Y1pij8+HSFdDGQt1v 5KD9OrJr/c7U7DO8/vhmKjDa2HJOXa8wJX7crfU6AD9q9E5xPSQp0Q23xK40VETKv6 z+t9TNdiGMTD8dSnr61Kzq128gHpAGV/mKntweBQ=
From: Kazuho Oku <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+0166e4ab996bdf5652d81047df37da7ad3c479047e830b8292cf000000011899a1fa92a169ce18f38deb@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/pull/2504@github.com>
Subject: [quicwg/base-drafts] MAX_KEY_UPDATES frame (yet another proposal to solve the key retirement problem) (#2504)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5c81dffa94654_3d093fc5fb2d45b41801dc"; 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/6iVRxdEstLp_gCUY6ldvaPzaKbI>
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: Fri, 08 Mar 2019 03:22:37 -0000

This PR is yet another attempt to resolve #2214, along with #2237 and #2492. The principle behind the PR is to align the design of key updates to other parts of the protocol as much as possible, by reusing the design pattern we use to communicate the maximums.

* Does not change how the Initial keys are dropped.
* Introduce a MAX_KEY_UPDATES frame, that is similar to existing MAX_* frames.
  * The frame carries explicitly the cumulative number of key-updates being permitted.
  * No special retransmission rules are required, because the maximum number is carried as a field within the frame.
* Initial exchange of MAX_KEY_UPDATES frame indicates the completion of the handshake.
  * Disposal of 0-RTT and Handshake keys are negotiated using the frame.
* MAX_KEY_UPDATES carrying a maximum count of zero indicates the peer that handshake is complete, but key update is prohibited.
  * I think that this is the direction we are heading to. All the three proposals use explicit signal to communicate the disposal of the keys, which in turn means that the key-update can be forbidden by not sending the signal.
You can view, comment on, or merge this pull request online at:


-- Commit Summary --


-- File Changes --

    M draft-ietf-quic-tls.md (115)
    M draft-ietf-quic-transport.md (33)

-- Patch Links --


You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub: