[quicwg/base-drafts] 85db1f: Rewrite key update section

Martin Thomson <noreply@github.com> Thu, 19 September 2019 02:59 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 05D6B1209CD for <quic-issues@ietfa.amsl.com>; Wed, 18 Sep 2019 19:59:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7
X-Spam-Level:
X-Spam-Status: No, score=-7 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, 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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4OKOsQSxX44c for <quic-issues@ietfa.amsl.com>; Wed, 18 Sep 2019 19:59:52 -0700 (PDT)
Received: from out-19.smtp.github.com (out-19.smtp.github.com [192.30.252.202]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EC9E31209CB for <quic-issues@ietf.org>; Wed, 18 Sep 2019 19:59:51 -0700 (PDT)
Date: Wed, 18 Sep 2019 19:59:50 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1568861990; bh=skadhzXz0DHHxmz9va3i5r8RAOHoswNBKxOb9Gqjjw8=; h=Date:From:To:Subject:From; b=0G0Ai2AM2MZGWAnPxy9/C4zU76Adafyp8cSHuRLOfzHYGKsLWkKe3AYW5/vNl509r zG9msTIXF3RtrVW2Wss0Y/4YD+JZc67SymZf8AeY8WCHNmFpX9jmb5ZGgsj3wxSeZV 0uFN1Ljbk8cfgKkXJFnXRszMehh0Ky2vga3wLkrg=
From: Martin Thomson <noreply@github.com>
To: quic-issues@ietf.org
Message-ID: <quicwg/base-drafts/push/refs/heads/rework-key-update-2/000000-85db1f@github.com>
Subject: [quicwg/base-drafts] 85db1f: Rewrite key update section
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-GitHub-Recipient-Address: quic-issues@ietf.org
X-Auto-Response-Suppress: All
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic-issues/62UHSegpj_UGTOIjmijECJ4v82E>
X-BeenThere: quic-issues@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
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:00:00 -0000

  Branch: refs/heads/rework-key-update-2
  Home:   https://github.com/quicwg/base-drafts
  Commit: 85db1f71811872bc01e4ac3692e545620258b82e
      https://github.com/quicwg/base-drafts/commit/85db1f71811872bc01e4ac3692e545620258b82e
  Author: Martin Thomson <mt@lowentropy.net>
  Date:   2019-09-19 (Thu, 19 Sep 2019)

  Changed paths:
    M draft-ietf-quic-tls.md

  Log Message:
  -----------
  Rewrite key update section

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'm suggesting that endpoints create
the next keys at some time after the key update happens.  Right now, I'm
thinking 1-2 PTOs is probably close enough to workable.  I'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's tolerable, but I'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.