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

From: Judson Wilson <[email-masked]>
Date: Fri, 26 Feb 2016 01:27:45 -0800

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

---

From: Ilari Liusvaara <[email-masked]>
Date: Fri, 26 Feb 2016 14:24:25 +0200

> that the other side has received and acted upon an earlier KeyUpdate

Well, the KeyUpdates are designed to be asynchronous so that the other
end does not need to know if the other has acted on KeyUpdate.
 
> Hence the receive_generation field.

There are better (and less broken) ways to do this kind of thing
(involving two MACs).
 
> extra rounds or messages. Thanks in advance for any feedback.

The KeyUpdate design is so that crossings don't matter.

-Ilari

---

From: Eric Rescorla <[email-masked]>
Date: Sat, 27 Feb 2016 09:53:16 -0800

> end does not need to know if the other has acted on KeyUpdate.

That's correct. And would continue to be the case here.

> There are better (and less broken) ways to do this kind of thing

I agree that there are arguably more elegant approaches if you are willing
to change TLS. It seems like the argument here is that this doesn't require
ay significant changes.

> The KeyUpdate design is so that crossings don't matter.

FWIW, this seems like it would be harmless and not difficult to implement
once you had KeyUpdate (since you need to keep count anyway).

-Ekr

>
>
>
> -Ilari
>
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>