msquic
msquic copied to clipboard
Support Async Resumption Ticket Validation
Describe the feature you'd like supported
Currently, the QUIC_CONNECTION_EVENT_RESUMPTION_TICKET_RECEIVED event assumes the app returns a success or failure inline. This is not ideal because there are scenarios where validation may require additional IO (network request to nonce server?) that can take time. So, to support these types of scenarios, the API should support a return of QUIC_STATUS_PENDING and completion of the validation at a later point in time.
Proposed solution
Unfortunately, the TLS layers (OpenSSL for sure at least) currently require immediate inline success/fail return. To support async at the QUIC/app layer we will have to work around this limitation. My proposal is that for success and pending returns from the app, we return success to TLS inline. If the app pended, then we pend the resulting CRYPTO payload until the app completes the validation. If the validation succeeds, we just continue as normal. The tricky part comes if they fail the validation (but not the connection). In this scenario, we will need to recreate the TLS state and reprocess the initial packet and then immediately fail the ticket validation. This shouldn't be too hard to pull off because we still have the received CRYPTO data cached from before.