[gnutls-help] Reliable way to check if there is %NO_TICKETS in the current configured priority

[Oto Šťáva]

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.stava at 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,