Expose QUIC API

[nibanks]

Suggested enhancement

Expose the necessary APIs so that the QUIC protocol can leverage mbedTLS.

Justification

For microsoft/msquic, we are investigating adding support for embedded devices, and our existing supported TLS libraries (Schannel & OpenSSL) aren't going to do the job. So we'd really like to add support for mbedTLS. It'd be great if mbedTLS could expose the necessary interfaces that we could call.

[gilles-peskine-arm]

It would help a lot if you could define the API extension that you need (or even better, define and implement!).

[nibanks]

This might help with the definition: https://github.com/microsoft/msquic/blob/main/docs/TLS.md. As for the implementation, we don't have any knowledge or experience with mbedTLS specifically, and I don't know if we'd be able to quickly do anything ourselves.

[yanesca]

From draft-ietf-quic-tls:

For brevity, the acronym TLS is used to refer to TLS 1.3, though a
newer version could be used;

Prerequisite of this feature is TLS 1.3:
https://github.com/ARMmbed/mbedtls/projects/2#column-12964476

[nibanks]

@yanesca thanks for the pointer. We have zero knowledge of the current state of mbedTLS beyond it generally being the recommended TLS library for embedded devices. Can you give me any estimate as far as scheduling for this, so we can compare with our device schedules to see if this solution will even work for Microsoft?

[yanesca]

The current status is that there is a prototype TLS 1.3 implementation maintained by @hanno-arm (will be back from holiday tomorrow), which is gradually being upstreamed (see the PRs in the above linked epic). We are aiming to integrate a minimum viable implementation in the coming months.

Regarding the latest roadmap information and scheduling @shebuk can help you.

[hanno-becker]

Hi @nibanks,

As @yanesca mentioned, we're working on a TLS 1.3 prototype on an experimental branch currently hosted on https://github.com/hannestschofenig/mbedtls/tree/tls13-prototype/ (we will likely move it over to the main repo soon as a separate branch, for better visibility). The functionality is there, but more cleanup, documentation and test writing needs to be done before it meets Mbed TLS' standards. However, for prototyping and experimentation, the branch is fine to use, and we appreciate any feedback or comments you may have.

To the point of the issue: The above branch is not just hosting the TLS 1.3 prototype, but also a rewrite of the 'messaging layer' (datagrams, records, retransmission), part of which is an explicit abstraction boundary between handshake logic and messaging details. The goal is to be able to drop in different messaging implementations (QUIC, cTLS, DTLS) while keeping the handshake logic largely unmodified; or, conversely, to change the logic of TLS while keeping the messaging the same, e.g. KemTLS.

Specifically for QUIC, the goal is to use the record layer abstraction https://github.com/hanno-arm/mbedtls/blob/mps_implementation/include/mbedtls/mps/layer2.h#L1080 to drop-in in a QUIC stack instead of a TLS record layer implementation. The abstraction exposes stream-like interfaces for reading/writing data of the various content types, plus an interface for registering new keys.

Happy to discuss more details, here or by mail.

[nibanks]

Just checking back in. What's the best way we can keep track of the TLS 1.3 dependency for this? And then any estimates for if/when QUIC could be added afterwards? We've got some real interest to use MsQuic on embedded devices in official Microsoft products, and we'd really like to leverage mbedTLS, but we need to know if scheduling would line up or not. If you'd rather take this to email, feel free to email me.

[0Grit]

Mark me down as another who wants this.

[hanno-becker]

What's the best way we can keep track of the TLS 1.3 dependency for this?

We plan to have a TLS 1.3 MVP upstream by end of September, and continue the upstreaming of the remaining functionality in Q4. See the Mbed TLS Roadmap. You can see on https://github.com/hannestschofenig/mbedtls/tree/tls13-prototype/ (will move that as branch experimental to the main Mbed TLS repo soon - "experimental" hereafter) that the functionality is there, it's "just" a matter of getting it production ready and integrating with the [D]TLS 1.2 functionality.

And then any estimates for if/when QUIC could be added afterwards?

I can't comment on estimates for development (cc @daverodgman), but the place for the technical groundwork for QUIC integration is on the TLS 1.3 experimental branch, where another team has already provided a QUIC patch + integration into ngtcp2 there (see hannestschofenig#150, which is currently being updated to the current version of the experimental branch).

We've got some real interest to use MsQuic on embedded devices in official Microsoft products, and we'd really like to leverage mbedTLS, but we need to know if scheduling would line up or not

It would be fantastic to see that happening - let's follow up by mail and discuss how we can collaborate to get there.

[nibanks]

Thanks @hanno-arm! Any idea on how much hannestschofenig#150 might change before being officially adopted/integrated? I'm trying to get an idea if it'd be worth our time to try to prototype using that branch, or if it would end up being mostly throw away work.

[hanno-becker]

@nibanks hannestschofenig#150 is still based on the old 'messaging layer' of Mbed TLS (see the README on https://github.com/hannestschofenig/mbedtls). I would therefore expect some changes to hannestschofenig#150 prior to integration into upstream Mbed TLS.

One consideration for the Mbed TLS - QUIC interface is whether one wants to support copy-less operation by having the QUIC implementation own the buffers for reading and writing. This would lead to a read/write interface along the following lines:

/* Query the QUIC implementation for an arbitrarily-sized chunk of data at the provided encryption level.
   The returned buffer is owned by the QUIC implementation and guaranteed to be available until the TLS
   implementation signals that it has been completely processed via quic_read_hs_data_done() */
quic_read_hs_data_start( some_type_t encryption_level, unsigned char const **buf, size_t *len );
quic_read_hs_data_finish();
/* Query the QUIC implementation for a buffer to write handshake data to. Tell the implementation
 * about how much has actually been written at the finish stage. */
quic_write_hs_data_start( some_type_t encryption_level, unsigned char **buf, size_t *len );
quic_write_hs_data_finish( size_t actual_len );

In the new messaging layer implementation, this is roughly the API the TLS record layer implementation exposes to higher levels. The benefit of using this for QUIC, too, would be that we can share all higher-level code between QUIC and TLS: reassembling large incoming handshake messages, and splitting large outgoing messages, while allowing copy-less operation for handshake messages that fit into single QUIC frames / record.

I'd be interested in hearing your thoughts on this, esp. whether you think a copy-less interface like this would work well with MsQuic.

I'll be off for two weeks from tomorrow, but will be happy to continue afterwards.

[nibanks]

Hi @hanno-arm, in MsQuic, the QUIC layer manages the buffers already. It even verifies that complete TLS messages are available before calling down to the TLS layer, providing it both input and output buffers, along with metadata such as the encryption level the data was received in.

[hanno-becker]

@nibanks So MsQuic does TLS handshake header parsing and message reassembly? I was under the impression that the interface exposed by QUIC implementations would rather be that of stream transports tagged by encryption level, agnostic of the (handshake) content.