[gnutls-devel] GnuTLS | WIP: add support for 0-RTT (!775)
Development of GNU's TLS library
gnutls-devel at lists.gnutls.org
Mon Oct 22 21:30:09 CEST 2018
Nikos Mavrogiannopoulos commented on a discussion on doc/cha-gtls-app.texi:
> + ret = gnutls_record_recv_early_data(session, buffer, sizeof(buffer));
> + assert(ret >= 0);
> + ...
> + return ret;
> +int main()
> + ...
> + gnutls_handshake_set_hook_function(server, GNUTLS_HANDSHAKE_END_OF_EARLY_DATA,
> + GNUTLS_HOOK_POST, handshake_hook_func);
> + ...
On the sending size, I agree that some kind of separation is important to avoid inadvertently sending 0rtt data. But on the receiving size, is there a benefit in that separation in practice? I'm thinking that an HTTPS server, could it skip the early data and only process the "late" ones?My understanding from [rfc8470](https://tools.ietf.org/html/rfc8470#section-2), is that there is no real distinction for the application, so aligning the API with the expectation may be simpler. In case such a distinction is needed in the future, maybe we can use session flags to indicate whether early data reading is in progress or complete, so that there is a way to distinguish the state of recv.
Alternatively to session flags, we could also use the packet API (`gnutls_record_recv_packet`) to pass the information on whether the received packet was early data (e.g. with a new function `gnutls_packet_get_flags` or so).
Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/775#note_110858846
You're receiving this email because of your account on gitlab.com.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Gnutls-devel