From juliane.schmueser at cispa.de Wed Jan 10 15:29:02 2024 From: juliane.schmueser at cispa.de (=?UTF-8?Q?Juliane_Schm=C3=BCser?=) Date: Wed, 10 Jan 2024 15:29:02 +0100 Subject: [gnutls-help] Study Invitation: Development of Cryptographic APIs Message-ID: <5d8ac587-b70a-4339-86b7-540555efcd3d@cispa.de> *Dear Developers of GnuTLS!* * *I hope this message is appropriate for this mailing list.* We are looking for participants for an interview study on developer?s experiences with the implementation of cryptographic APIs. Our goal is to investigate?the area of ?Human Crypto Interaction?, ?analyzing challenges and?developing?guidelines, tools, and recommendations for stakeholders. Interviews will be conducted online using a platform of your choice,? and last about 60 minutes. We can compensate for your time and effort with $60. If you have contributed code to at least one cryptographic API, please consider signing up: https://cispa.qualtrics.com/jfe/form/SV_8zYC2UHMySdICLs You can find more information about us and the study at https://research.teamusec.de/2023-crypto-api-design/ .If you have any questions, please do not hesitate to contact me. Best regards, Juliane Schm?ser Researcher at TeamUSEC and CISPA Helmholtz Center for Information Security * -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4869 bytes Desc: Kryptografische S/MIME-Signatur URL: From zfridric at redhat.com Thu Jan 11 11:24:59 2024 From: zfridric at redhat.com (Zoltan Fridrich) Date: Thu, 11 Jan 2024 11:24:59 +0100 Subject: [gnutls-help] GSoC 2024 participation Message-ID: Good day folks, Google Summer of Code (GSoC) is currently calling for organizations to apply for participation [1]. We have successfully participated in GSoC in the past and we would like to participate in GSoC this year as well and for that we will need mentors. Please, if you would be interested in volunteering for mentoring and/or administration in this year's GSoC, let us know. The current list of possible student projects is available here: https://gitlab.com/gnutls/gnutls/-/wikis/Projects-for-newcomers Footnotes: [1] https://developers.google.com/open-source/gsoc/timeline Kind regards, Zoltan -------------- next part -------------- An HTML attachment was scrubbed... URL: From ueno at gnu.org Tue Jan 16 11:25:17 2024 From: ueno at gnu.org (Daiki Ueno) Date: Tue, 16 Jan 2024 19:25:17 +0900 Subject: [gnutls-help] gnutls 3.8.3 Message-ID: <87r0ih7eya.fsf-ueno@gnu.org> Hello, We have just released gnutls-3.8.3. This is a bug fix and security release on the 3.8.x branch. We would like to thank everyone who contributed in this release: Clemens Lang, Daiki Ueno, Jakub Jelen, and Mark Harfouche The detailed list of changes follows: * Version 3.8.3 (released 2024-01-16) ** libgnutls: Fix more timing side-channel inside RSA-PSK key exchange [GNUTLS-SA-2024-01-14, CVSS: medium] [CVE-2024-0553] ** libgnutls: Fix assertion failure when verifying a certificate chain with a cycle of cross signatures [GNUTLS-SA-2024-01-09, CVSS: medium] [CVE-2024-0567] ** libgnutls: Fix regression in handling Ed25519 keys stored in PKCS#11 token certtool was unable to handle Ed25519 keys generated on PKCS#11 with pkcs11-tool (OpenSC). This is a regression introduced in 3.8.2. ** API and ABI modifications: No changes since last version. Getting the Software ================ GnuTLS may be downloaded directly from https://www.gnupg.org/ftp/gcrypt/ A list of GnuTLS mirrors can be found at http://www.gnutls.org/download.html Here are the XZ compressed sources: https://www.gnupg.org/ftp/gcrypt/gnutls/v3.8/gnutls-3.8.3.tar.xz Here are OpenPGP detached signatures signed using key: 462225C3B46F34879FC8496CD605848ED7E69871 https://www.gnupg.org/ftp/gcrypt/gnutls/v3.8/gnutls-3.8.3.tar.xz.sig Note that it has been signed with my openpgp key: pub rsa4096 2009-07-23 [SC] [expires: 2026-06-29] 462225C3B46F34879FC8496CD605848ED7E69871 uid [ultimate] Daiki Ueno uid [ultimate] Daiki Ueno sub rsa4096 2010-02-04 [E] Regards, -- Daiki Ueno -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 832 bytes Desc: not available URL: From oto.stava at nic.cz Wed Jan 17 14:47:59 2024 From: oto.stava at nic.cz (=?UTF-8?B?T3RvIMWgxaXDoXZh?=) Date: Wed, 17 Jan 2024 14:47:59 +0100 Subject: [gnutls-help] Reliable way to check if there is %NO_TICKETS in the current configured priority Message-ID: Hi all, 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? Regards Oto From ueno at gnu.org Mon Jan 29 06:16:11 2024 From: ueno at gnu.org (Daiki Ueno) Date: Mon, 29 Jan 2024 14:16:11 +0900 Subject: [gnutls-help] Reliable way to check if there is %NO_TICKETS in the current configured priority In-Reply-To: ("Oto =?utf-8?B?xaDFpcOhdmEiJ3M=?= message of "Wed, 17 Jan 2024 14:47:59 +0100") References: Message-ID: <87mssou3c4.fsf-ueno@gnu.org> Hello Oto, Sorry for the late response. Oto ???va 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, -- Daiki Ueno From oto.stava at nic.cz Mon Jan 29 12:01:52 2024 From: oto.stava at nic.cz (=?UTF-8?B?T3RvIMWgxaXDoXZh?=) Date: Mon, 29 Jan 2024 12:01:52 +0100 Subject: [gnutls-help] Reliable way to check if there is %NO_TICKETS in the current configured priority In-Reply-To: <87mssou3c4.fsf-ueno@gnu.org> References: <87mssou3c4.fsf-ueno@gnu.org> Message-ID: <9eac95d4-4c6e-4b0e-b896-e6350d853cde@nic.cz> 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 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,