Implement channel bindings for TLS 1.3

The draft is now close to the IESG submission. It would make sense to consider adding support for it in our channel bindings API.

added triagedenhancement label

cc @rufferson

Sorry I didn't quite get what is going on here? The related MR is empty and closed, 1.3's finished is still not copied.

Is it a place-holder to implement TLSv1.3 binding? And if yes would you still agree having tls-unique implemented? Or at the very least handled properly to return error (instead of empty payload - hence breaking any binding implementation).

And then again is the expectation the binding will be wrapped into existing binding call (which kind of makes sense) as currently it gives only unique and only for 1.2 hence to get other bindings one would need to use lower-level APIs.

The related MR is empty and closed, 1.3's finished is still not copied.

Sorry, I mistakenly clicked the "Create merge request" button instead of "Comment", so please ignore that MR.

Or at the very least handled properly to return error (instead of empty payload - hence breaking any binding implementation).

Yes, my (vague) expectation was that the library implements tls-exporter for TLS 1.3 and below, keeping tls-unique for TLS 1.2 and earlier (the use of tls-unique in TLS 1.3 will be an error).

Would that make sense, or is there anything we will have to consider?

No that's ok, just need to return GNUTLS_E_UNIMPLEMENTED_FEATURE for 1.3 calling for GNUTLS_CB_TLS_UNIQUE. Do you want me to try to draft an MR or you prefer doing it yourself? I'll probably add server-end-point re-using the code from glib-networking.

It would be awesome if you could submit an MR :-)

mentioned in merge request !1422 (merged)

mentioned in commit cca0ac94

closed with merge request !1422 (merged)

changed milestone to %Release of GnuTLS 3.7.2 release

mentioned in issue #1391 (closed)