application-defined session tickets

[marten-seemann]

Hello @ekr, @bifurcation,

I'm planning to implement QUIC session resumption in quic-go soon. We'll need a few changes to mint for that, so I wanted to use this issue to outline my plan for that.

At the moment, mint sends a random value for the ticket. We will need a way for the application to provide an arbitrary resumption token here. I suggest that we

• add a ResumptionTokenHandler somewhat analogous to the CookieHandler

The ResumptionTokenHandler would be set by the application, and when requested provide a resumption token (and a ticket lifetime, and the maximum early data size) to mint. This token would then be encrypted using the CookieSource implemented in #141. When mint receives a PskIdentity, it would ask the ResumptionTokenHandler to validate the provided token, and decide whether to continue with the resumption or to fall back to the normal handshake.

Currently, mint sends one NewSessionTicket after the handshake completes. In general, a server can send an arbitrary number of session tickets, so we should

• add a Conn.SendSessionTicket() to trigger sending of a new session ticket

We should probably keep sending one session ticket right after the handshake completes, since this provides a useful default for users who don't need fine-grained control.

I just read the corresponding sections of the TLS 1.3 spec, so I might have missed something important. What do you think?

[ekr]

This all sounds plausible and it matches the NSS API reasonably well...

…

-Ekr

On Mon, Dec 4, 2017 at 10:29 PM, Marten Seemann ***@***.***> wrote: Hello @ekr <https://github.com/ekr>, @bifurcation <https://github.com/bifurcation>, I'm planning to implement QUIC session resumption in quic-go soon. We'll need a few changes to mint for that, so I wanted to use this issue to outline my plan for that. At the moment, mint sends a random value for the ticket. We will need a way for the application to provide an arbitrary resumption token here. I suggest that we - add a ResumptionTokenHandler somewhat analogous to the CookieHandler The ResumptionTokenHandler would be set by the application, and when requested provide a resumption token (and a ticket lifetime, and the maximum early data size) to mint. This token would then be encrypted using the CookieSource implemented in #141 <#141>. When mint receives a PskIdentity, it would ask the ResumptionTokenHandler to validate the provided token, and decide whether to continue with the resumption or to fall back to the normal handshake. Currently, mint sends one NewSessionTicket after the handshake completes. In general, a server can send an arbitrary number of session tickets, so we should - add a Conn.SendSessionTicket() to trigger sending of a new session ticket We should probably keep sending one session ticket right after the handshake completes, since this provides a useful default for users who don't need fine-grained control. I just read the corresponding sections of the TLS 1.3 spec, so I might have missed something important. What do you think? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#148>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABD1oSo04eKY26N2qbX-UT5D7gTZ7ucTks5s9OK6gaJpZM4Q1zKO> .