Re: [TLS] KeyUpdate and unbounded write obligations

[Keith Winstein <[e-mail]>]

Okay, this is a different question -- whether P3 is a valuable property or not.

I made the case for this in my Monday thread[1] and in my Berlin
presentation[2].

[1] https://www.ietf.org/mail-archive/web/tls/current/msg20787.html

[2] https://www.ietf.org/proceedings/96/slides/slides-96-tls-3.pdf

I'm happy to make the case for P3 here again but didn't want to hijack
David's thread. My claim here was that there are some simple designs
that satisfy everybody and grant P1+P2+P3+P4, and that David's
concern's and my concerns are "basically orthogonal issues."

===

On the value of P3, I think you're giving us a crimped reading. We
gave three use cases in Berlin and in my email:

- 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. (If confirmation is absent, the device 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.

On this last use case, I agree that incumbent IDS vendors may not be
eager to support it. But adoption would probably come from a different
direction. IoT devices today forbid anybody, including a middlebox
controlled by the device owner, from auditing their own traffic and
seeing what the devices are sending and receiving. (Unlike a browser,
they don't let the user add a private CA cert to be able to MITM.) In
my conversations with IoT device vendors, some expressed interest in
allowing device owners to grant read-only access to themselves. I
really do think this would be a good thing.

Unlike Heartbeat, we are not talking about an ack that would be
generated by something, and we're not really talking about altering
TLS's design. We're talking about piggybacking one field in a protocol
message that is going to be sent anyway, where the message (KeyUpdate)
is new in TLS 1.3 anyway.

As I said, it is orthogonal to David's issues here. Yes, it is
possible to get P1+P2+P4 by themselves -- P3 has to live or die on its
own merit. But it is really just one piggyback field to get it.

-Keith

On Thu, Aug 18, 2016 at 12:42 PM, Adam Langley <[e-mail]> wrote:
> On Thu, Aug 18, 2016 at 12:20 PM, Keith Winstein <[e-mail]>
> wrote:
>>
>> Yes, you need current_receive_generation, or something like it, to get
>> P3. This is the subject of our PR #426/580.
>
>
> The KeyUpdate messages are encrypted and thus sequenced with all the
> application data. Apart from the Heartbeat message (TLS 6520), which has not
> been significantly used in TLS (I think), we've never worried about a
> TLS-level ack before.
>
> PR 426 wants a way to retrospectively disclose keys to middleware and wants
> to make sure that the receive side is no longer going to trust those keys
> before doing so. Having spoken to several vendors of these products in the
> past and tried to persuade them to accept read-only access I don't think we
> should alter TLS's design for that unless there's a novel argument about why
> they would ever accept it. (Because they won't. Their competitive interest
> is to have as many "features" as possible, many of which would require
> modifying traffic.)
>
>
> Cheers
>
> AGL