Re: [TLS] Resuming a session as part of a renegotiation.

[Fabrice Gautier <[e-mail]>]

On Thu, Sep 19, 2013 at 10:05 AM, Michael D'Errico <[e-mail]> wrote:
> Fabrice Gautier wrote:
>>
>>
>> Is there anything in the TLS RFCs that prohibit using a resumed
>> session as a result of a renegotiation handshake ?
>
>
> No.
>
>
>> I haven't found anything, but I can't think of an interesting use case
>> for that behavior either.
>
>
> Not sure if it's interesting, but you get fresh session keys.

Hum, I guess it depends your definition of 'fresh'. They might be
different after the renegotiation. But if you are resuming an old
session as part of a renegotiation, the freshness depends on how much
that particular resumed session has been used before.

Imagine the case where a server request renegotiation, but the client
send back a ClientHello with the same session ID as previously


> One possible use case: if you negotiated a block cipher with a
> small internal state and are sending large quantities of data,
> security might be improved by periodically renegotiating.

Thats only benefit a full handshake renegotiation.

The way I understand it, renegotiation allows you to have several
session in the same connection, and session resumption allows you to
have the same session across multiple connections.

Mixing the two gives you... well, I don't know if it gives you
anything useful...


-- Fabrice