[TLS] TLS 1.3 PR #426: KeyUpdate message: add receive

[TLS] TLS 1.3 PR #426: KeyUpdate message: add receive_generation field

Judson Wilson <wilson.judson@gmail.com> Fri, 26 February 2016 09:27 UTC

MIME-Version: 1.0
Date: Fri, 26 Feb 2016 01:27:45 -0800
Message-ID: <CAB=4g8Jp-04RQKSXDpos5PczdFfMU8bEv242qzf1HnC=aP0F2Q@mail.gmail.com>
From: Judson Wilson <wilson.judson@gmail.com>
To: tls@ietf.org
Content-Type: multipart/alternative; boundary="001a113ed3586b770d052ca8e9d5"
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/r6mqLr5SilIxRFGZbt4UMGleTno>
Cc: Dan Boneh <dabo@cs.stanford.edu>, Philip Levis <pal@cs.stanford.edu>, Judson Wilson <judsonw@stanford.edu>, Keith Winstein <keithw@cs.stanford.edu>, Henry Corrigan-Gibbs <henrycg@stanford.edu>, "Riad S. Wahby" <rsw@cs.stanford.edu>
Subject: [TLS] TLS 1.3 PR #426: KeyUpdate message: add receive_generation field
Precedence: list

Hello folks,

We'd like to add a field to the KeyUpdate message that represents the
generation of receive traffic keys in use by the sender of the KeyUpdate
message. (Our pull request: https://github.com/tlswg/tls13-spec/pull/426)

How this helps: In the current draft, an endpoint that sends a KeyUpdate
message and later receives a KeyUpdate message cannot know whether the
other side has actually updated its receive keys. The two messages may have
been generated independently and crossed in flight. Putting a
receive_generation field in the KeyUpdate message lets an endpoint confirm
that the other side has received and acted upon an earlier KeyUpdate
message.

Why we want this: We've been researching how to restrict corporate
middleboxes like intrusion-detection systems and virus scanners. Today,
these scanners generally demand man-in-the-middle access to TLS traffic and
require users to install a private root CA. We think it would be better if
they only had "read-only" access and didn't MITM the traffic.

One way for a client to grant delayed read-only access in TLS 1.3 is with a
"rotate and release." The client starts by sending a KeyUpdate. Later,
after all traffic keys from the previous generation have been superseded on
both sides, the client releases the (superseded) traffic keys to the
middlebox. The middlebox can use the keys to decrypt the previous
generation of ciphertext, without danger of compromising the integrity of
the session. The challenge is that an endpoint can't safely release its old
send keys until it knows that the other side has updated its receive keys.
Hence the receive_generation field.

We think this is a pretty lightweight way to resolve the ambiguity from
KeyUpdates crossing in flight; it doesn't add any blocking, waiting, or
extra rounds or messages. Thanks in advance for any feedback.

Sincerely,
Judson Wilson (+ Henry Corrigan-Gibbs, Riad S. Wahby
                 Keith Winstein, Philip Levis, and Dan Boneh)
Stanford University

[TLS] TLS 1.3 PR #426: KeyUpdate message: add rec… Judson Wilson
Re: [TLS] TLS 1.3 PR #426: KeyUpdate message: add… Ilari Liusvaara
Re: [TLS] TLS 1.3 PR #426: KeyUpdate message: add… Eric Rescorla
Re: [TLS] TLS 1.3 PR #426: KeyUpdate message: add… Philip Levis
Re: [TLS] TLS 1.3 PR #426: KeyUpdate message: add… Ilari Liusvaara