Re: [TLS] KeyUpdate and unbounded write obligations

[Keith Winstein <[e-mail]>]

I think we have to oppose a change to KeyUpdate that adds P4 (bounded
write obligations) but not P3 (ability to learn that a KeyUpdate was
read by other side). These are orthogonal and easily achievable with a
pretty small tweak. Here are four options that would work for us:

1. No change to message structures. Forbid implementations from
sending an update_not_requested KeyUpdate unless it is triggered by an
update_requested KeyUpdate.

2. Add a uint8 field to KeyUpdate representing the sender's current
receive generation (lower 8 bits).

3. Keep request_update an 8-bit field (same width as it is in the PR),
and define the high bit as representing the update_requested boolean,
and the remaining bits represent the lower 7 bits of the sender's
current receive generation

4. Keep request_update an 8-bit field (same width as it is in the PR),
define the high bit as representing the update_requested boolean, and
the remaining bits represent a 7-bit opaque value that must be echoed
in the response. (If multiple update_requested KeyUpdates arrive, any
of their values can be the one that gets echoed.)

Approach 1 seems like it might be generally acceptable here, even
understanding the concerns of the list. I am happy to draft sample
text if helpful.

-Keith

On Thu, Sep 1, 2016 at 12:55 PM, Eric Rescorla <[e-mail]> wrote:
> I have created a PR for this at:
> https://github.com/tlswg/tls13-spec/pull/611
>
> As it seems there was rough consensus for this change, I will merge this
> weekend
> absent some violent objections or direction to the contrary from the chairs.
>
> -Ekr
>
>
> On Mon, Aug 29, 2016 at 3:06 PM, Russ Housley <[e-mail]> wrote:
>>
>> Eric:
>>
>> > Yes, I agree separate ladders would fix this. I don't necessarily object
>> > to this
>> > change, but I'm not sure it's that big a deal either, because you really
>> > only get
>> > into this case when there's a big asymmetry in sending rate, so much
>> > that
>> > one side wants to send multiple updates before the other side has sent
>> > any data at all.
>>
>> I can think of many situations where one side sends a lot more data than
>> the other.
>>
>> > Note: it's also possible to avoid the rollback problem with the existing
>> > single-ladder system: when you send a key update you compute:
>> >
>> > traffic_secret_N+1
>> > read_key_N+1
>> > write_key_N+1
>> >
>> > You then discard traffic_secret N, write_key_N, but key read_key_N, so
>> > if you
>> > are M updates ahead of the other side, you have M read keys outstanding,
>> > but these cannot be used to produce the write keys. However, this
>> > probably
>> > isn't simpler than just running two ladders if we think this is
>> > important.
>>
>> That seems to work.  However, I think that splitting the ladders seems to
>> marry well with the many situations where one side sends a lot more than the
>> other.  So, I suggest that we split the ladders.
>>
>> Russ
>>
>
>
> _______________________________________________
> TLS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls
>