On Tue, 11 Aug 2020 at 09:11, Mohit Sethi M <mohit.m.se...@ericsson.com> wrote: > > Section 5.7 "Resumption" says: > > > When resumption occurs, it is based on cached information at the TLS > > layer. 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. We use the term "cached data" to describe such > > information. Authorization during resumption MUST be based on such > > cached data. The EAP peer and sever MAY perform fresh revocation > > checks on the cached certificate data. > > This text indicates what needs to be cached and seems pretty clear to me.
Hi Mohit, Agreed, that's clear. Typo: "sever" > The next question is how to lookup the cached information. This is what > the text says currently: > > > There are two ways to retrieve the cached information from the > > original full handshake. The first method is that the TLS server and > > client cache the information locally. The cached information is > > identified by an identifier. For TLS versions before 1.3, the > > identifier can be the session ID, for TLS 1.3, the identifier is the > > PSK identity. 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. The following > > requirements apply to both methods. > The first mechanism is obvious, both sides store the information from > the initial handshake and lookup using the Session ID or the PSK identity. No disagreement here. > In the second mechanism, the server can avoid storing information. It > instead puts that information in the PSK or the session ticket and sends > it to the client. However, the client still needs to store information > from the original handshake. This is why there is the sentence "Note > that the client still needs to cache the information locally.". The > client can't obviously read the contents of the ticket or the PSK. I agree with the sentiment, but the current text seems a bit "Sherlock": Once you've eliminated all other possibilities whatever remains must be the case. I think it should directly state that the client uses the opaque ticket or PSK as a key to identify the cached information corresponding to the original session. Whereas the server may use the decoded content of the ticket or PSK to achieve the goal of remaining stateless. Aside: The latter part might be obvious since shifting the burden of storing the server-side state from the server to the client is the whole point of ticket/PSK schemes. However it's not obvious to me that the additional goal introduced by this RFC of performing a deep revalidation of the authorisation data (resume-time certificate checks, etc.) is shared with the RFC5077 or RFC8446 whose concern appears to be with lightweight bootstrapping of the connection using the original parameters. (Maybe I have missed something?) If that's true then as Alan mentions, perhaps it is worth enumerating the types of information that should be stored in the ticket to facilitate the resume-time authorisation check rather than merely to reestablish the crypto parameters required to perform an abbreviated handshake? > Do you have some concrete suggestion on improving the text? We are happy > to edit or receive pull requests on github: > https://github.com/emu-wg/draft-ietf-emu-eap-tls13 > > Would this be better: > > > The second method for retrieving cached information is > > via [RFC5077] or [RFC8446], where the TLS server avoids storing > > information locally and instead encapsulates the information into a > > ticket or PSK and sends it to the client. Note that the client still > > needs to cache the information locally. The client can subsequently > > do resumption using the obtained ticket. IMO, that's better. How about: > The second method for retrieving cached information is via [RFC5077] or > [RFC8446], where the TLS server avoids storing information locally and > instead encapsulates the information into a ticket or PSK, which it encrypts > using a key that only the server knows, and sends to the client. Note that > the client still needs to cache the original handshake information locally > and will use the opaque ticket or PSK to lookup this information during > resumption, however the server is able to decrypt the ticket or PSK to obtain > the original handshake information. I think this emphasises that the ticket is opaque to the client yet clear to the server, and that it is the blob itself that is used by the client to lookup the information in its cache. This gives the correct intuition for why the scheme works without needing to understand the detail in the aforementioned RFCs to read between the lines. Terry > On 8/10/20 6:58 PM, Terry Burton wrote: > > 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
