[TLS] KeyUpdate receive_generation field (again)

Keith Winstein <keithw@cs.stanford.edu> Tue, 16 August 2016 01:25 UTC

Return-Path: <winstein@gmail.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 3121B12D119 for <tls@ietfa.amsl.com>; Mon, 15 Aug 2016 18:25:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id hFknAgBH30uN for <tls@ietfa.amsl.com>; Mon, 15 Aug 2016 18:25:12 -0700 (PDT)
Received: from mail-yw0-x244.google.com (mail-yw0-x244.google.com [IPv6:2607:f8b0:4002:c05::244]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A27D912B068 for <tls@ietf.org>; Mon, 15 Aug 2016 18:25:12 -0700 (PDT)
Received: by mail-yw0-x244.google.com with SMTP id u134so2958540ywg.3 for <tls@ietf.org>; Mon, 15 Aug 2016 18:25:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:from:date:message-id:subject:to:cc; bh=JYbCVzYusDdToJFS2P+myvT2qek55wkBaSxrG63EZ9U=; b=B+8SnZdO+98eB+zXmxZA5fr999vNFxH2NCRWRn4jM9zkiLChOpSKP3wyMgiAjN+RiU LsKrvPYuouVeoNyM9oij+s+Yf8ZLPTgDy0CwkgQILdBSypsE03SVM1rBa4XWFBS3/k58 +qpVIaycwlbNhBI3Iii80WSyhEcNRmQrKyYGl42B6qZajseGGz/Joi03Gf+FOXy5Y0GC 2Ph6VnoEeUdVSp+R9TdTOuPYCGWOFfT0o5NIS/F52zM2VXdZDn1lVIKOEJRmz8gt3ita iJrzQAjPiMchDwv6CQg40FwPUHsa8+dsjzlHsiNBkPsT9KLQERDvbJ/N6hTKa1oh5Njm OL/w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:from:date:message-id:subject :to:cc; bh=JYbCVzYusDdToJFS2P+myvT2qek55wkBaSxrG63EZ9U=; b=LL8Nwdj4dgRFD+jZ+7NFrlEYmmx1oHIhu9IakBXGX4OFT+lO7RGFFn+3k0qqZcuRT1 RF0BTyQEN1yjCX+CzdarCNvtF9vpZi/pXD8ld/leh4Bc9LzIUonYMIZidp8RrIDwY/Ri P+xO1+wU0RGSbHNbDCAgVLLokshoAzs6JsVbvylluou5WcT/p/3PFxeXrfkMMFv2c4wk b86Ynm/wD5sNDfBGT0eeeWzBjqlEiDOH/rbpucdUL3Lw7fWJBsJhdFff7mh29W3bngGl C1uwwTvbS75lwcjjN2xUnazKSh1Hjm8NDiYfbfvDLRlCcphWelMRqZKg1NSI2si7u3ce GLQA==
X-Gm-Message-State: AEkooutCqijtAkXaUCkF+Ija5qXKgv6bznj+H2944b1h9ENQL8VrhHmw30ecuXBT1smLvf1PalzQKXcZKWY/lw==
X-Received: by with SMTP id a184mr25237049ywc.63.1471310711771; Mon, 15 Aug 2016 18:25:11 -0700 (PDT)
MIME-Version: 1.0
Sender: winstein@gmail.com
Received: by with HTTP; Mon, 15 Aug 2016 18:24:31 -0700 (PDT)
From: Keith Winstein <keithw@cs.stanford.edu>
Date: Mon, 15 Aug 2016 18:24:31 -0700
X-Google-Sender-Auth: 3aENf97AYUoDeojlNSc94KpmhEc
Message-ID: <CAMzhQmPbGN7pf429XfFP2QWLGWzNiBdyya+MjtKjETttAgG0Tw@mail.gmail.com>
To: tls@ietf.org
Content-Type: text/plain; charset=UTF-8
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/4O9r8QA7UHoGSXTSj23GqWNRIxM>
Cc: Henry Corrigan-Gibbs <henrycg@stanford.edu>, Dan Boneh <dabo@cs.stanford.edu>, Riad Wahby <rsw@cs.stanford.edu>, Judson Andrew Wilson <judsonw@stanford.edu>
Subject: [TLS] KeyUpdate receive_generation field (again)
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 16 Aug 2016 01:25:14 -0000

Hello all,

After our discussion in Berlin, I wanted to try to rally consensus
over adding an explicit receive_generation field to the TLS 1.3
KeyUpdate message.

The KeyUpdate message allows one side of the connection to instruct
the other to:

1) increment the receive-key generation,
2) de-trust and stop accepting data encrypted with receive-keys from
earlier generations, and
3) advance the send-key forwards to at least the same generation if it
isn't already (and send a KeyUpdate in the reverse direction as

Because either side can generate a KeyUpdate message whenever they
want, there's no way within the current draft to tell that this
instruction has actually been carried out. For some applications, it
would be helpful for an initiating side to receive a confirmation that
the KeyUpdate (especially part #2, de-trusting the old receive-key)
has taken effect:

- An embedded device may wish to fully rotate the session keys before
going to sleep.

- A paranoid device might fully rotate the session keys before closing
the session, with the hopes that the other side will de-trust and also
delete the old session keys, so that a subsequent compromise doesn't
betray the session plaintext. If an endpoint can't get confirmation
that the other side has incremented the receive-key generation, it
might use a higher-level mechanism to forcibly log out all open
sessions from that user.

- An endpoint that wishes to permit a read-only virus scanner or IDS
will want to fully rotate the session before sharing the directional
keys with the middlebox. Otherwise the middlebox could use them to
become a MITM in at least one direction.

Our proposal is to add a receive_generation field to the KeyUpdate
message, so an initiating node can learn when an earlier KeyUpdate has
taken effect. The KeyUpdate message would remain as async and
non-blocking as it is currently.

Pull request: https://github.com/tlswg/tls13-spec/pull/580

Earlier discussion:
https://www.ietf.org/mail-archive/web/tls/current/msg19347.html and