The exact contents and structure of StatePlaintext and ticket itself are up to the implementation to decide. This format is merely a recommendation or example. The only interop requirements are that the server maintain enough state that it can correctly resume a session on the subsequent request. OpenSSL, for example, uses a different serialization that includes bits of ASN.1. Indeed the spec specifically says:
Other TLS extensions may require the inclusion of additional data in the StatePlaintext structure. So, no, you are not intended to take that structure as the literal, complete format. However, while other TLS extensions may require additional data, I believe you are also misreading RFC 5746. There is no such requirement to retain client_verify_data. client_verify_data is remembered across *renegotiations* within a *single connection*, not for *resumptions* across *different* connections. Indeed RFC 5746, section 3.1 explicitly says: Both client and server need to store three additional values for each TLS connection state (see RFC 5246, Section 6.1). Note that these values are specific to connection (not a TLS session cache entry). Renegotiation and resumption are not the same thing. Renegotiation is when you perform multiple handshakes *within a single connection*. Resumption is when, for an individual handshake, you carry over key material and other state from a previous connection as an optimization. It is possible for a renegotiation handshake to be a full or resumption handshake, but RFC 5746 applies independently of this. Sections 3.4 and 3.6 say: Note that this section [3.4] and Section 3.5 apply to both full handshakes and session resumption handshakes. Note that this section [3.6] and Section 3.7 apply to both full handshakes and session-resumption handshakes. This applies to both session-ID-based resumption and session-ticket-based resumption. However, this does *not* mean you retain client_verify_data and server_verify_data in the session state. You maintain it in the *connection*. Whatever the previous handshake at the connection was, you use its Finished messages as the next handshake's renegotiation_info values. (All applicable handshakes, full or resumption, ticket or ID, have Finished messages.) Maintaining it in the session state wouldn't be useful because a session may span connections, and that's not the binding that RFC 5746 is intended to apply. That is, suppose connection C1 handshakes and established session S1, sending Finished messages F1. If connection C2 handshakes and happens to resume session S1, you *do not* use F1 as the renegotiation_info C2. It is even possible that, within a single connection, handshake 3 resumes a session established by handshake 1. Even so, you use handshake 2's Finished messages in handshake 3, not handshake 1. On Fri, Sep 16, 2022 at 7:15 AM Fries, Steffen <steffen.fr...@siemens.com> wrote: > Hi Viktor, > > Thank you for the info. Regarding the information in the ticket, I was > looking at the recommended ticket structure in RFC 5077 section 4 ( > https://datatracker.ietf.org/doc/html/rfc5077#section-4). There is the > encrypted_state mentioned, which contains the encrypted information stated > in the structures in section 4. For the renegotiation extension > verification from RFC 5746 section 3.7 ( > https://datatracker.ietf.org/doc/html/rfc5746#section-3.7), the server > must have the client_verify_data, which is not part of the ticket in the > StatePlaintext structure. That was the reason for assuming that the > renegotiation extension may not be used in the case of ticket based > resumption. If the server puts this information (from the Finish message) > into the ticket, it could reconstruct it. Maybe I was taking the section 4 > of RFC 5077 to literally. > > Best regards > Steffen > > > -----Original Message----- > > From: TLS <tls-boun...@ietf.org> On Behalf Of Viktor Dukhovni > > Sent: Donnerstag, 15. September 2022 15:42 > > To: tls@ietf.org > > Subject: Re: [TLS] RFC 5746 applicable for session resumption? > > > > On Thu, Sep 15, 2022 at 01:16:33PM +0000, Fries, Steffen wrote: > > > > > I was just double checking if there was an answer to the question of > > > using the TLS renegotiation extension from RFC 5746 in the context of > > > TLS session resumption. As stated below, based on the RFC it is not > > > crystal clear if it applies. In general I would think yes, but only > > > for session resumption based on the sessionID, not based on tickets. > > > > There should be no difference between (server-side) stateful and > stateless > > resumption. The server should serialise into the session ticket > sufficient > > information to allow it to fully recover the session, as though it were > cached > > locally to facilitate stateful resumption. > > > > This is the case at least with OpenSSL, the session ticket contains and > encrypted > > and MACed serialised SSL_SESSION object, in exactly the same form as it > would > > have in a server-side session cache. > > > > -- > > Viktor. > > > > _______________________________________________ > > TLS mailing list > > TLS@ietf.org > > > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf > > .org%2Fmailman%2Flistinfo%2Ftls&data=05%7C01%7Csteffen.fries%40sie > > mens.com%7Cb07ba1db3dfc413ab86208da9720128d%7C38ae3bcd95794fd4ad > > dab42e1495d55a%7C1%7C0%7C637988461247843608%7CUnknown%7CTWFpb > > GZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6M > > n0%3D%7C3000%7C%7C%7C&sdata=XWMXniQ6lhqUtpn89V1Nb0ap1VEsH > > lOpeCkxsDBSgKU%3D&reserved=0 > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
