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

[Development of GNU's TLS library]

Airtower 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);
> +  ...

I don't have a conclusion to offer, but here are considerations from my `mod_gnutls` point of view:
* Some HTTP-Requests can trigger actions on the server, so replay protection for those is critical. For simple downloads it doesn't matter.
* A simple solution would be to leave allowing 0-RTT data to the user, maybe per path, possibly filtering for certain request types.
* The problem with any settings other than "no 0-RTT" or "always accept 0-RTT" is: If we receive a request that isn't replay-safe we need a way to reject the early data and make the client send it again. This would probably get messy with the Apache stack, but a hook function that's called after receiving early data seems like an appropriate place for such a check.
* Other than that, I'd prefer to read early data via `gnutls_record_recv` as usual. Using a special function in a hook is fine, but I'd rather avoid having a special case in the filter functions.

-- 
Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/775#note_110620062
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/3425de6f/attachment-0001.html>