On Aug 10, 2020, at 11:58 AM, Terry Burton 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
