[quicwg/base-drafts] Rewrite key update section (#3050)

Martin Thomson <notifications@github.com> Thu, 19 September 2019 03:15 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 C73E412011D for <quic-issues@ietfa.amsl.com>; Wed, 18 Sep 2019 20:15:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.999
X-Spam-Status: No, score=-7.999 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_HELO_NONE=0.001, 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 FwJu-H4cGe6A for <quic-issues@ietfa.amsl.com>; Wed, 18 Sep 2019 20:15:07 -0700 (PDT)
Received: from out-2.smtp.github.com (out-2.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 B30A5120119 for <quic-issues@ietf.org>; Wed, 18 Sep 2019 20:15:07 -0700 (PDT)
Date: Wed, 18 Sep 2019 20:15:06 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1568862906; bh=BnZWXt/I2m1cYPwTCOKUliEN5iPcD9FWg3O58WyO88k=; h=Date:From:Reply-To:To:Cc:Subject:List-ID:List-Archive:List-Post: List-Unsubscribe:From; b=WqhNP3Azam0as8IeWzL94u/i6ekm36VIauT4tVn9CMSo4kTXyTYQfEAeWeFdLP3Y6 LKTWqSxUrp0CXm1W/nuBFOlQUYfnb9yQvD/G/uRkMnGjlyg4wFo466UnENWHt9eGQe ArqQq9e659IEO0DGIQ/1LcfuIxc49T/5C9o9kKjQ=
From: Martin Thomson <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJK52LH5SS6H24BWK3R53SALSVEVBNHHB3CL6HQ@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/pull/3050@github.com>
Subject: [quicwg/base-drafts] Rewrite key update section (#3050)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5d82f2ba11168_6a793fcaf7ecd964495fe"; 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/23a0W0dGloZy8XyaWEPxyHKXOk0>
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: Thu, 19 Sep 2019 03:15:10 -0000

This makes some significant editorial changes to the key update section,
hopefully making the various activities clearer and more explicit.

In the process, I am also trying to address #2792, which is the timing
sidechannel created by having the generation of updated keys inline with
packet processing.  In doing so, I&#39;m suggesting that endpoints create
the next keys at some time after the key update happens.  Right now, I&#39;m
thinking 1-2 PTOs is probably close enough to workable.  I&#39;ve limited
this at 3PTO.  This is, however, just a (firm) suggestion at this stage.

For endpoints that only want to keep 2 sets of keys, this is probably
the right time frame, especially if we keep the current advice for 3PTO
before a subsequent update.

The effect of this is that attempts to update at certain times could
cause all packets after the update to be discarded.  That would only
happen if implementations consistently ignored advice on update
frequency, so I think that&#39;s tolerable, but I&#39;d like input on this.

(This also attempts to take up the advice from the other, older PRs on
this subject.)

Closes #2792, #2791, #2237.
You can view, comment on, or merge this pull request online at:


-- Commit Summary --

  * Rewrite key update section

-- File Changes --

    M draft-ietf-quic-tls.md (296)

-- Patch Links --


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