Hi, Reading "Using EAP-TLS with TLS 1.3" I find the text potentially misleading when it comes to resumption within TLS 1.3, specifically for the case where the peer wishes to re-validate the certificate originally provided by the server during the initial handshake using only its locally cached data and without redoing the handshake, e.g. to determine that the original certificate hasn't expired or been revoked.
5.7. Resumption ... To perform resumption in a secure way, the EAP-TLS peer and EAP-TLS server need to be able to securely retrieve authorization information such as certificate chains from the initial full handshake. ... There are two ways to retrieve the cached information from the original full handshake. ... The second method for retrieving cached information is via [RFC5077] or [RFC8446], where the TLS server encapsulates the information into a ticket and sends it to the client. The client can subsequently do resumption using the obtained ticket. Note that the client still needs to cache the information locally. In TLS 1.3, the PSK ticket is defined as being encrypted using a key that only the server knows. Even without encryption, the format for the ticket is opaque to the client with only a suggested format presented in RFC 8446. How is the original handshake data determined? A casual reading of the text seems to imply that the client performs some verification using the encapsulated information within the ticket. However I believe that the intent is to use the full PSK blob, or some digest thereof, as a key to lookup the corresponding cached handshake data. Perhaps this could be made clearer? Thanks, Terry _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
