[gnutls-devel] GnuTLS | WIP: add support for 0-RTT (!775)

[Development of GNU's TLS library]

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...
URL: <https://lists.gnupg.org/pipermail/gnutls-devel/attachments/20181022/67cdf506/attachment.html>