Hello Daiki,
Just to clarify something I seem to have failed to mention in my
original e-mail: my application is client-side. I'm sorry about any
possible confusion that may have caused.
In the end, the actual error seemed to be in my incorrect use of ngtcp2,
although I was only ever able to reproduce it in the specific case of
having "%NO_TICKETS" in the priority string and passing the
GNUTLS_ENABLE_EARLY_DATA flag to gnutls_init() at the same time. Even
after correcting the use of ngtcp2's API, I still get errors while
trying to send early data, though (I have not yet found out what the
actual errors are, since the calls are "hidden away" in ngtcp2's crypto
library and not propagated outside), so it might still be worth adding a
reliable way of detecting this misconfiguration and maybe falling back
to disabling 0-RTT, as you mentioned.
Best regards
Oto Šťáva
On 1/29/24 06:16, Daiki Ueno wrote:
Hello Oto,
Sorry for the late response.
Oto Šťáva <oto.st...@nic.cz> writes:
I have an application that allows the user to set their own priority
string for GnuTLS, including the %NO_TICKETS keyword, which disables
TLS resumption. That same application also supports QUIC via the
ngtcp2 library. There is an edge-case where if I set %NO_TICKETS and
attempt to use 0-RTT functions of the ngtcp2 library, the QUIC
connection gets into an invalid state and eventually crashes with an
assertion error. Is there some API through which I can reliably check
whether tickets are enabled for a session so as to avoid calling the
0-RTT-related functions in such a case? I tried via
(gnutls_session_get_flags(...) & GNUTLS_SFLAGS_SESSION_TICKET), but
that returns true even when %NO_TICKETS is present in the priority
string. Would I have to parse the priority string manually?
Right, GNUTLS_SFLAGS_SESSION_TICKET can only be used to check whether a
session ticket is received. There is currently no API that returns the
settings of the use of session tickets, and I generally agree that it
would make sense to have one like gnutls_session_ticket_enabled_server.
I haven't looked into the actual error when used with ngtcp2, but does
it happen around (or inside) the call to GnuTLS API
gnutls_record_*_early_data? If so, we might rather want to add a
fallback behavior (i.e., disabling 0-RTT) rather than erroring out.
Regards,
_______________________________________________
Gnutls-help mailing list
Gnutls-help@lists.gnutls.org
http://lists.gnupg.org/mailman/listinfo/gnutls-help
