[TLS] KeyUpdate receive_generation field (again)

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

MIME-Version: 1.0
Sender: winstein@gmail.com
From: Keith Winstein <keithw@cs.stanford.edu>
Date: Mon, 15 Aug 2016 18:24:31 -0700
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)
Precedence: list

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
necessary).

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
subsequent

Cheers,
Keith

[TLS] KeyUpdate receive_generation field (again) Keith Winstein