Re: [TLS] Doing without renegotiation

On Thu, Apr 17, 2014 at 9:03 AM, Nico Williams <nico@cryptonector.com> wrote:
> On Thu, Apr 17, 2014 at 12:43 AM, Henrick Hellström
> <henrick@streamsec.se> wrote:
>> On 2014-04-17 05:50, Nico Williams wrote:
>>>   - For rekeying just introduce a CCS-like record whose purpose is to
>>>     indicate that the sender is changing to new keys on the send side.
>>>     The new keys are derived from the same master secret as the preceding
>>>     keys, in the same way, but with a counter appended to the "key
>>>     expansion" salt.
>>>
>>>     There's no need to synchronize, but DTLS requires retransmission of
>>>     such messages else when dropped the recipient will not be able to
>>>     decrypt any subsequent messages.
>>
>>
>> This might be an option if the purpose of the renegotiation is just to
>> reduce the risk of state collisions in the bulk encryption cipher, but it is
>
> Yes, much like SSHv2 recommends rekeying after 2^L/4 packets, where L
> is the cipher's block length (sadly no reference is given for this).

Real or random security. If we instantiate CBC mode with a PRF instead
of a PRP the security declines quadratically as we might call the PRF
on the same block with birthday bound issues. The PRP->PRF replacement
is another quadratic factor. So we get a probability of distinguishing
that is quartic in the number of blocks. I don't know if this is an
upper bound as well, or if other proof techniques can increase this
bound.

For CTR mode the only loss is quadratic from PRP->PRF.

>
>> no replacement for renegotiation of DHE/ECDHE sessions in order to refresh
>> the perfect forward secrecy.
>
> This could be done with a single round trip, no need for a full
> handshake.  The payloads containing the ephemeral keys for rekeying
> could be sent opportunistically when the application writes.

This actually doesn't work as well as you think it does.

Suppose Alice is sending a long message to Bob and needs to rekey in
the middle of the message. Alice sends her half of the ephemeral key
exchange. Before Bob can read the rest of the long message, he needs
to send data to Alice. It's cleaner than renegotiation, but still has
the C problem.

However, what it does isn't worth doing.
PFS means that revelation of the long term keys doesn't compromise a
connection made before the revelation. This holds true even if the
connection lasts beyond the compromise. If you leak the long term keys
and the connection keys, it's game over. If you leak only the
connection keys, then we need to reestablish a connection using the
long term keys, and can't use the compromised keys for authentication.

I do see the issue with letting keys stay in memory that can decrypt
lots of communications, but I think a cleaner method is to do the
proposed rekeying in such a way that the state transformation is
irreversible.

Sincerely,
Watson Ladd

>
> Nico
> --
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls

-- 
"Those who would give up Essential Liberty to purchase a little
Temporary Safety deserve neither  Liberty nor Safety."
-- Benjamin Franklin