3
$\begingroup$

Please explain the difference between TLS re-negotiation and resumption.

My understanding is as follows: in the context of TLS 1.2, re-negotiation and resumption look the same, but the former can be started with either a HelloRequest/ClientHello from server/client while the latter can start with just with ClientHello from the client. In both cases, a client-server dialog followed by an abbreviated handshake occurs (or not ?), security parameters do not change, and new keying materials are recalculated using an "old" pre-master secret with new random numbers.

From the record layer point of view, all re-negotiation/resumption messages should be processed using "current record state"-- which means they are encrypted/authenticated using "current" keys.

Re-negotiation may happen in the middle of an existing session, a "session ticket" or "session Id" are not required to find "current state parameters", just 5 tuple may be used to look for proper running session context. ( is it true ?)

Moreover, resumption may happen even after actual connection has been closed (is it true? ) and we need sessionTicket or sessionId to look for security parameters and DO decryption, BUT the ClientHello message itself is encrypted. How is this solved for TLS1.2 ?

In the context of TLS1.3, renegotiation is done by using KeyUpdate message, and is clearly described by draft, but resumption has the same issues. How is resumption solved for TLS1.3 ?

Improve this question
$\endgroup$
2
  • 1
    $\begingroup$ The main difference is: Renegotiation runs a full new handshake (encrypted with the previous record layer encryption) and resumption essentially uses keys still available on both sides to run an abbreviated PSK handshake w/o asymmetric crypto. $\endgroup$
    – SEJPM
    Feb 8, 2018 at 10:41
  • $\begingroup$ Yes, but how TLS1.2 resumption solves the "chicken and egg" problem were we need security parameters to decrypt a message that carries hint to look for security parameters ? $\endgroup$
    – Elena Gurevich
    Feb 8, 2018 at 11:57

2 Answers 2

Reset to default
3
$\begingroup$

Re-negotiation may happen in the middle of existing session, "session ticked" or "session Id" are not required to find "current state parameters", just 5 tuple may be used to look for proper running session context.

Yes.

[...]BUT ClientHello message itself is encrypted. How this is solved for TLS1.2 ?

The ClientHello on an abbreviated handshake is in fact not encrypted. The message flow for an abbreviated handshake goes roughly as follows: Client sends unencrypted ClientHello, Server responds with ServerHello, ChangeCipherSpec and Finished message and client answers with ChangeCipherSpec and Finished message and application data. Also see page 37 of RFC 5246.

in both cases client-server dialog follow abbreviated Handshake

No, only for session resumption the abbreviated handshake is used, for renegotiation a full handshake is performed.

In opposite resumption may happen even after actual connection has been closed

Yes.

In context of TLS1.3 renegotiation is done now using KeyUpdate message and clearly described by draft, but resumption has the same issues. How resumption is solved for TLS1.3 ?

Section 2.2 of the TLS 1.3 draft (-23) talks about the session resumption protocol flow. Section 4.6.1 talks about how the ticket mechanism works in detail. Section 4.2.11 talks about how the tickets are used in the Hello Messages. It turns out that the client may offer the server multiple PSK identities in the (cleartext!) ClientHello of which the server selects and thus "consumes" at most one and indicates which in its ServerHello message.

Improve this answer
$\endgroup$
1
  • 1
    $\begingroup$ Actually renegotiation (in 1.2 and below) can either do a full handshake (creating a new session) or an abbreviated one (resuming an existing session) -- in particular it can resume the session already used on that connection in order to re-key (now handled separately in 1.3). However, most renegotiation is done to establish new security parameters, such as adding client-auth, and that means a full handshake. See security.stackexchange.com/a/91375 . $\endgroup$
    – dave_thompson_085
    Apr 29, 2022 at 10:44
2
$\begingroup$

Resumption and renegotiation are rather opposites. Resumption restarts a previous TLS session in a new TCP connection, using the same TLS parameters. Renegotiation continues an existing TLS session in the same TCP connection, but changes some of the parameters.

Improve this answer
$\endgroup$
2
  • $\begingroup$ so resumption messages are not encrypted even we run over the same TCP connection ? $\endgroup$
    – Elena Gurevich
    Feb 8, 2018 at 12:01
  • $\begingroup$ They're orthogonal, not strictly opposites. @ElenaGurevich (since I had to necro this): resumption is usually done at the beginning of a new TCP connection, and is not encrypted; but when it is combined with renegotiation on an existing connection, the handshake is encrypted using the prior session up until ChangeCipherSpec. (Only for 1.2 or below, in 1.3 renegotiation is prohibited.) $\endgroup$
    – dave_thompson_085
    Apr 29, 2022 at 10:44

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.