Complete QUIC 0-RTT Design

[nibanks]

Thanks to @tatsuhiro-t much of the 0-RTT work is done. All that is left (I think) is around NST management (on both client and server side). Luckily it seems much (if not all?) of the work is already done in some shape or another and might just need to be cleaned up and moved to this fork. I will try to enumerate what I believe is still needed here:

Client Side

• The client needs an explicit indication somehow when a ticket has been received and is ready to be consumed.
• Received tickets on the client need to be retrieved in a serialized byte form that can be passed up the stack (in a platform agnostic way) to the app, so that it may then use it for a future QUIC connection.

It seems openssl#5932 does the serialization already, but just needs to be merged here.

Server Side

• The server needs explicit control over when/if to send an NST.
• The server needs to be able to encode custom data in the NST.
• The server needs to know when an NST is received from the client and extract the custom data from it.

Apparently openssl#11416 achieved some of this but it doesn't quite work for QUIC.

[tmshort]

Client Side:

• SessionTickets on the client-side are only available as a binary blob of data. There already exists an API to get the blob. Not sure of the API necessary to reuse that blob, but I believe the openssl s_client is able to do it.

ServerSide:

• There is already APIs to add and extract "app_data" to the session ticket (I added this API to upstream).

I can provide more details when I'm in front of a Linux box...

[kaduk]

Client Side:

• SessionTickets on the client-side are only available as a binary blob of data. There already exists an API to get the blob. Not sure of the API necessary to reuse that blob, but I believe the openssl s_client is able to do it.

s_client doesn't try to care if a session is using a ticket or stateful resumption; the abstraction just (de)serializes an entire SSL_SESSION object (which would include the ticket if there is one) and uses SSL_set_session() to use it for resumption.

ServerSide:

• There is already APIs to add and extract "app_data" to the session ticket (I added this API to upstream).

I can provide more details when I'm in front of a Linux box...

These are the SSL_SESSION_{set1,get0}_ticket_appdata() APIs, documented in SSL_CTX_set_session_ticket_cb(3).

[nibanks]

Ok, so I'm trying to add support for the serialization on the client side, and I'm getting a failure from PEM_write_bio_SSL_SESSION with a ERR_get_error() of 0x2007507E. I'm not exactly sure how to map this to a particular problem. Any help would be appreciated. Code snippet:

uint32_t Length = 64000; // TODO - What size? Could we maybe piggyback the TLS buffer instead?
void* SessionBuffer = CXPLAT_ALLOC_NONPAGED(Length, QUIC_POOL_TLS_BUFFER);
if (SessionBuffer) {
    BIO* Bio = BIO_new_mem_buf(SessionBuffer, (int)Length);
    if (Bio) {
        int WriteLength;
        if ((WriteLength = PEM_write_bio_SSL_SESSION(Bio, Session)) > 0) {
            TlsContext->SecConfig->Callbacks.ReceiveTicket(
                TlsContext->Connection,
                (uint32_t)WriteLength,
                SessionBuffer);
        } else {
            QuicTraceEvent(
                LibraryErrorStatus,
                "[ lib] ERROR, %u, %s.",
                ERR_get_error(),
                "PEM_write_bio_SSL_SESSION failed");
        }

Error log:

11:48:53.044955500 [Microsoft-Quic][ lib] ERROR, 537350270, PEM_write_bio_SSL_SESSION failed.

[tmshort]

Try openssl errstr <errnum>

[nibanks]

Ah, never knew that! Thanks!

> openssl errstr 0x2007507E
error:2007507E:BIO routines:mem_write:write to read only BIO

I'm not quite sure why it says this is read only. I must be doing something wrong?

[nibanks]

Looks like I just needed to do something like this instead:

BIO* Bio = BIO_new(BIO_s_mem());

Things seem to be getting farther along now. Thanks.

[nibanks]

Ok, so I have the following code to serialize the session:

BIO* Bio = BIO_new(BIO_s_mem());
if (Bio) {
    if (PEM_write_bio_SSL_SESSION(Bio, Session) == 1) {
        TlsContext->SecConfig->Callbacks.ReceiveTicket(
            TlsContext->Connection,
            (uint32_t)BIO_number_written(Bio),
            (uint8_t*)BIO_get_data(Bio));

Then I am trying to use the buffer/length from above to deserialize with the following:

BIO* Bio =
    BIO_new_mem_buf(
        Config->ResumptionTicketBuffer,
        (int)Config->ResumptionTicketLength);
if (Bio) {
    SSL_SESSION* Session = PEM_read_bio_SSL_SESSION(Bio, NULL, 0, NULL);
    if (Session) {
        if (!SSL_set_session(TlsContext->Ssl, Session)) {

But I am getting the following error:

12:52:06.526168100 [Microsoft-Quic][ tls][0xB7F3AFF470] ERROR, 151584876, PEM_read_bio_SSL_SESSION failed.

And that seems to map to:

> openssl errstr 0x909006C
error:0909006C:PEM routines:get_name:no start line

What am I doing wrong?

[nibanks]

Interestingly, if I use file BIO instead of mem, things seem to work. Is there any known reason these wouldn't be interchangeable?

[kaduk]

I suspect (but did not attempt to verify) that the file BIO is maintaining separate read and write offsets, but the mem BIO is just trying to read from the end of the data (not the beginning of it). It's pretty rare to write to and read from the same memory BIO in the same process -- usually it's just a convenient way to (de)serialize something to/from a blob and the blob that's conveyed via a different channel

[nibanks]

I am creating new BIOs. It would effectively be the following:

BIO* BioOut = BIO_new(BIO_s_mem());
PEM_write_bio_SSL_SESSION(BioOut, Session);

BIO* BioIn = BIO_new_mem_buf(BIO_get_data(BioOut), BIO_number_written(BioOut));
SSL_SESSION* NewSession = PEM_read_bio_SSL_SESSION(BioIn , NULL, 0, NULL); <== FAILS

[kaduk]

Ah. Well we can scratch that theory, then.

[nibanks]

With some help from a coworker I figured out that I needed to call BIO_get_mem_data to get the data & length from the mem BIO correctly.

[nibanks]

So, is there a way to dynamically trigger the sending of a session ticket on the server side? You can configure the number of tickets, but then OpenSSL just sends them ASAP, before our App has had the chance to give us the custom data we need to associate with the ticket.

[kaduk]

So, is there a way to dynamically trigger the sending of a session ticket on the server side? You can configure the number of tickets, but then OpenSSL just sends them ASAP, before our App has had the chance to give us the custom data we need to associate with the ticket.

There is one for regular TLS connections (SSL_new_session_ticket()) but it is currently hooked into the state machine in a way that is not useful for QUIC. I have a plan for how to make it work for QUIC but it hasn't gotten to the top of my list yet. Please go ahead and file an issue for that and I will try to reprioritize.

[nibanks]

Done: #25

[nibanks]

Closing this issue as everything from here seems to work. We can track the rest of what is needed in #25. Thanks!