Support QUIC TLS API

Description of the feature:

QUIC decided to use TLS 1.3 as the foundation for the crypto and security layer to avoid inventing something new and instead lean on a trustworthy and existing protocol. However, A QUIC implementation needs to extract traffic secrets from the TLS connection and it needs to be able to read/write TLS messages directly – not using the TLS record layer. So it should only use "TLS messages" and not "TLS records" for the protocol.

Applications that this feature may be relevant to:

Currently any implementation of HTTP/3

Is this feature implemented in other libraries (and which)

There are tweaked versions OpenSSL that currently has the crypto API for QUIC TLS. Similar to this, there is an ongoing boringSSL patch as well. There is QUIC TLS APIs in PicoTLS as well.

changed the description

I'm willing to work on the implementation but then I need some help from the gnuTLS community to guide me quickly through the existing codebase :)

I suppose that change would be quite significant and we would first need to discuss how the API should look like, as in the NSS changes for that. In any case, I am happy to review/mentor; thank you for your interest!

I would love to get some sort of mentorship in this context :)

Yes, how about the API be something similar to how OpenSSL/BoringSSL does? in user perspective, it is always useful to have an API for similar functionality be similar to be implemented in their softwares. What do you think?

Sure, but each library has its own design principles. Do you have links to the other implementations that we can evaluate? Also I presume that the scope is to integrate it to QUIC libraries such as ngtcp2, right?

Sure, but each library has its own design principles

Yes, totally understandable. My initial plan was to study how other libraries does it at first and try to adapt something similar to gnuTLS.

Do you have links to the other implementations that we can evaluate?

(1) https://github.com/openssl/openssl/pull/8797/ (2) https://github.com/tatsuhiro-t/openssl/tree/quic-draft-22

Check these out.

presume that the scope is to integrate it to QUIC libraries such as ngtcp2, right?

yes, but not limited to.

added 3_7_x label

(1) https://github.com/openssl/openssl/pull/8797/ (2) https://github.com/tatsuhiro-t/openssl/tree/quic-draft-22

Thank you. Looks like (1) is more up to date than (2) and in fact the draft-22 branch of ngtcp2 is assuming the API from (1).

So we basically would need the following things:

1. a callback to notify the key (epoch) change
2. a callback to write a Handshake messsage, when it is being sent
3. a callback to write an Alert messasge, when it is being sent
4. a callback to flush the message - not sure if this is really needed in GnuTLS
5. a function to push data received from the peer to the TLS layer

I guess (1) would be quite straightforward. Would you like to start with it? Basically you would need to hook the callback where new traffic keys are set, e.g.,: https://gitlab.com/gnutls/gnutls/blob/master/lib/constate.c#L379

See also the NSS design document linked from my first comment.

@dueno, Sounds great! I'd love to start working on this right away. Though I might take some time initially to learn the gnuTLS codebase, as well as the QUIC TLS, needs. Since you are free to mentor me with this project, I think I would be easier :D.

Meanwhile digging into what you just said, do you think I should write all these functions/code in a seprate file within src as quic_crypto.c file or integrate in some existing file? Feel free to let me know if the file name should be something else :D, this is just a quick suggestion.

Next, does gnutls have some IRC channel or something which I could use to have a online quick chats with you while hacking into this project? :D, I personally feel like I would spend lesser amount of time on this if we are able to communicate properly atleast through some mean like this :D.

Hi @dueno

I started working on the implementation and a few pointers from you would be really helpful:

(1) Should we also wrap the callbacks within a struct as how OpenSSL has done it? Or is there something specific that we wish to follow? If yes, please share a few example code within our gnuTLS source code that I can refer to.

(2) Is there is specific place within our source code where I can retrieve TLS 1.3 data's like client early traffic secret, client handshake traffic secret, server handshake traffic secret etc?

For (1) I think there are two approaches: put all callbacks in a struct, or define each callback separately. The former makes it clear that the caller must set all callbacks to use QUIC functionality, while the latter would provide future extensibility if more callbacks are needed. Since QUIC is not yet finalized, I am leaning towards the latter approach: for secret retrieval, maybe something like:

typedef void (*gnutls_secret_hook_func)(gnutls_session_t session,
                                        unsigned int epoch,
                                        unsigned int incoming,
                                        const gnutls_datum_t *secret);

void gnutls_set_secret_hook_function(gnutls_session_t session,
                                     gnutls_secret_hook_func func);

For (2), as GnuTLS supports keylog file: https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSS/Key_Log_Format

you could git grep with the label in the source code, e.g., "CLIENT_EARLY_TRAFFIC_SECRET".

Hi @dueno

I have implemented the initial version of how gnutls_set_secret_hook_function should look like with gnutls_secret_hook_func callback. If possible, do let me know your reviews :). Check it out here: https://gitlab.com/Aniketh01/gnutls/tree/Aniketh01-QUIC-TLS-API

I have followed how the implementation of boringssl does the QUIC TLS API.

You can always file a merge request with a "WIP:" prefix so people can review and discuss. However, after a brief look at your branch, I would suggest:

• read CONTRIBUTING.md; we use "linux" indentation style and there is a naming guideline of functions and data types
• please organize your commits in logical units (with git rebase -i)

Sure, I can sent in WIP pull request.

About (1), sure thanks for pointing it out. I will look into it straight away :)

(2) sure, since it was just a personal repo, I thought I will do rebase it once I was to sent a pull request. Anyways, will do it soon!

Btw, did you get a chance to review the code? Looks good enough? I'm just starting out with TLS related implementation as well, so it would be great if you would give me few pointers on the same :)

Btw, did you get a chance to review the code?

Yes.

Looks good enough?

Sorry, I'm afraid not. I expect at least a test case that tells what you are trying to achieve (and I don't think the current code does anything meaningful: for example, gnutls_quic_secret_hook_exchange would only work after the handshake is complete, which is useless in QUIC).

Yes very true. I was trying to figure out which function in gnutls would help me to do so?

Are you asking how to write tests, or how to hook key scheduling?

The former is well explained in CONTRIBUTING.md, and for the latter see the last paragraph of my previous comment.

If you need any realtime assistance I will be available in the matrix room mentioned on https://www.gnutls.org/support.html.

mentioned in issue #849 (closed)

mentioned in issue #850 (closed)

mentioned in issue #852 (closed)

mentioned in merge request !1353 (merged)

changed milestone to %Release of GnuTLS 3.7.0

assigned to @dueno

mentioned in commit d648d35d

closed with merge request !1353 (merged)