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

From: Fabrice Gautier <[email-masked]>
Date: Thu, 19 Sep 2013 09:40:20 -0700

Hi,

Is there anything in the TLS RFCs that prohibit using a resumed
session as a result of a renegotiation handshake ?

I haven't found anything, but I can't think of an interesting use case
for that behavior either.

-- Fabrice

---

From: Michael D'Errico <[email-masked]>
Date: Thu, 19 Sep 2013 10:05:35 -0700

> session as a result of a renegotiation handshake ?

No.

> for that behavior either.

Not sure if it's interesting, but you get fresh session keys.

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.

Mike

---

From: Fabrice Gautier <[email-masked]>
Date: Thu, 19 Sep 2013 11:29:54 -0700

> 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

> 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

---

From: Yoav Nir <[email-masked]>
Date: Thu, 19 Sep 2013 18:50:01 +0000

> have the same session across multiple connections.

Renegotiation just means doing the handshake again. The end result is new keys. So if you believe that 3DES keys should not be used for more than 0.5GB of data, just doing a renegotiation gives you fresh keys (because they are mixed with the new nonces). If you resume the session, you don't get new client and/or server identities, you don't get re-authentication, and you don't get a new master key, so someone who has managed to get your old master key can figure out both your old and new encryption keys. But if the only reason you're renegotiating is that you need fresh keys, that's good enough.

So renegotiation+resumption gives you the same session, but new keys. Sort of like "phase II" in IKE.

Yoav

---

From: Alfredo Pironti <[email-masked]>
Date: Thu, 19 Sep 2013 21:07:15 +0200

I'd say that, over an existing connection, you'd mostly run an
abbreviated handshake resuming the current session to refresh keys.
You could also use it to reset sequence numbers, in case they're soon
going to overflow. I know no implementation doing that; all of them
seem to happily let the sequence number overflow, assuming the
connection will be tear down way sooner this happens (which is
probably true in most scenarios).

According to the spec, you could even run an abbreviated handshake
resuming a different connection form the current one. In a scenario
which I discourage (because it's asking for trouble confusing the
application), you could have a pool of established TLS sessions, each
using a different identity, and "swap" between them with abbreviated
re-handshakes over the same connection. Again, I'd take this as a
non-forbidden behavior, rather than a largely useful one.

On Thu, Sep 19, 2013 at 8:50 PM, Yoav Nir <[email-masked]> wrote:
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls

---

From: Fabrice Gautier <[email-masked]>
Date: Thu, 19 Sep 2013 13:01:34 -0700

> So renegotiation+resumption gives you the same session, but new keys. Sort of like "phase II" in IKE.

Oh I see... Same master secret but refreshed cipher keys.

Thanks

-- Fabrice