On Aug 10, 2020, at 11:58 AM, Terry Burton <terry.bur...@gmail.com> wrote: > 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.
I suspect that the client needs to cache the server certificate, and associate it with the session ticket. The certificate can then be re-validated on fast reconnect. > > 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. Hmm... yes, it should be nice to discuss *what* information is cached, and why it is cached, and what is done with it to re-validate it. > 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. If so, that should be clarified. The ticket is an opaque blob to the client. > 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? I agree. Alan DeKok. _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
