Hi David, Thank you for the insight. I made some inline comments. In general your explanation clarifies the initial question.
Best regards Steffen From: David Benjamin <[email protected]> Sent: Sonntag, 18. September 2022 18:15 Subject: Re: [TLS] RFC 5746 applicable for session resumption? 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. [stf] okay, that is what I guessed. 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). [stf] Thank you for underlining this. I was indeed reading across this and missed the connection part. 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. [stf] yes, here it becomes obvious that this information is maintained in the connection state, not in the session state. On Fri, Sep 16, 2022 at 7:15 AM Fries, Steffen <[email protected]<mailto:[email protected]>> 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<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Frfc5077%23section-4&data=05%7C01%7Csteffen.fries%40siemens.com%7C04fa60b155084ba8dc7b08da9990eda5%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637991144984829874%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=dIUe7JogigO2hKPuSms%2B6KRVCv7k%2BD%2BDgxH1DYh6%2BM4%3D&reserved=0>). 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<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Frfc5746%23section-3.7&data=05%7C01%7Csteffen.fries%40siemens.com%7C04fa60b155084ba8dc7b08da9990eda5%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637991144984829874%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=ETAmhEbVvFyDF5ZW8H54sWLSd1ezV%2FzU54w5AoM%2Bi2E%3D&reserved=0>), 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 <[email protected]<mailto:[email protected]>> On Behalf Of > Viktor Dukhovni > Sent: Donnerstag, 15. September 2022 15:42 > To: [email protected]<mailto:[email protected]> > 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 > [email protected]<mailto:[email protected]> > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf%2F&data=05%7C01%7Csteffen.fries%40siemens.com%7C04fa60b155084ba8dc7b08da9990eda5%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637991144984829874%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=hRfm2wgnkwcZHeKQRxeXNAXOVfUYJJjQLpwPo4bx3dI%3D&reserved=0> > .org%2Fmailman%2Flistinfo%2Ftls&data=05%7C01%7Csteffen.fries%40sie > mens.com<https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmens.com%2F&data=05%7C01%7Csteffen.fries%40siemens.com%7C04fa60b155084ba8dc7b08da9990eda5%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637991144984829874%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=6mlmrGGBT7i0%2BTv8IB1f9V5gOSjj1G1bFogpPUkL8uI%3D&reserved=0>%7Cb07ba1db3dfc413ab86208da9720128d%7C38ae3bcd95794fd4ad > dab42e1495d55a%7C1%7C0%7C637988461247843608%7CUnknown%7CTWFpb > GZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6M > n0%3D%7C3000%7C%7C%7C&sdata=XWMXniQ6lhqUtpn89V1Nb0ap1VEsH > lOpeCkxsDBSgKU%3D&reserved=0 _______________________________________________ TLS mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/tls<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Ftls&data=05%7C01%7Csteffen.fries%40siemens.com%7C04fa60b155084ba8dc7b08da9990eda5%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637991144984829874%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=hZw3ah7S%2F0FiMq01ksvkpyZQfT5H%2F7VvkaFjHe2z2Q0%3D&reserved=0>
_______________________________________________ TLS mailing list [email protected] https://www.ietf.org/mailman/listinfo/tls
