From gnutls-devel at lists.gnutls.org Mon Oct 1 09:48:48 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 01 Oct 2018 07:48:48 +0000 Subject: [gnutls-devel] GnuTLS | Please document session ticket key rotation (#581) In-Reply-To: References: Message-ID: @nmav Sure, no problem. Will be done this week. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/581#note_105438489 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Oct 1 10:16:34 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 01 Oct 2018 08:16:34 +0000 Subject: [gnutls-devel] GnuTLS | GNUTLS_CPUID_OVERRIDE does not have any impact on performance (#566) In-Reply-To: References: Message-ID: HI Nikos , --benchmark-tls-kx Testing key exchanges (RSA/DH bits: 3072, EC bits: 256) DHE_RSA_AES_128_CBC_SHA1 1.47 transactions/sec (avg. handshake time: 681.38 ms, sample variance: 2.55) ECDHE_RSA_AES_128_CBC_SHA1 3.78 transactions/sec (avg. handshake time: 264.11 ms, sample variance: 0.32) ECDHE_ECDSA_AES_128_CBC_SHA1 28.95 transactions/sec (avg. handshake time: 34.44 ms, sample variance: 0.25) RSA_AES_128_CBC_SHA1 4.09 transactions/sec (avg. handshake time: 244.67 ms, sample variance: 0.23) --------------------------------------------------------------------------------------------------------------- --benchmark-tls-ciphers Testing throughput in cipher/MAC combinations (payload: 1400 bytes) RSA_ARCFOUR_128_SHA1 18.37 MB/sec RSA_ARCFOUR_128_MD5 21.85 MB/sec RSA_AES_128_GCM_SHA256 6.97 MB/sec RSA_AES_128_CCM 7.27 MB/sec ECDHE_RSA_CHACHA20_POLY1305 10.66 MB/sec RSA_AES_128_CBC_SHA1 9.77 MB/sec RSA_CAMELLIA_128_CBC_SHA1 7.43 MB/sec Testing throughput in cipher/MAC combinations (payload: 15360 bytes) RSA_ARCFOUR_128_SHA1 21.04 MB/sec RSA_ARCFOUR_128_MD5 24.88 MB/sec RSA_AES_128_GCM_SHA256 7.30 MB/sec RSA_AES_128_CCM 7.62 MB/sec ECDHE_RSA_CHACHA20_POLY1305 11.62 MB/sec RSA_AES_128_CBC_SHA1 10.74 MB/sec RSA_CAMELLIA_128_CBC_SHA1 8.00 MB/sec -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/566#note_105444884 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Oct 1 11:20:52 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 01 Oct 2018 09:20:52 +0000 Subject: [gnutls-devel] GnuTLS | 3.6.4 - build from source fails - errors "redefinition of typedef" (#576) In-Reply-To: References: Message-ID: Issue was closed by Nikos Mavrogiannopoulos Issue #576: https://gitlab.com/gnutls/gnutls/issues/576 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/576 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Oct 1 11:23:41 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 01 Oct 2018 09:23:41 +0000 Subject: [gnutls-devel] GnuTLS | Service Desk (from contactsuryac@gmail.com): gnutls_x509_privkey_generate doesnot return (#430) In-Reply-To: References: Message-ID: Issue was closed by Nikos Mavrogiannopoulos Issue #430: https://gitlab.com/gnutls/gnutls/issues/430 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/430 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Oct 1 11:23:56 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 01 Oct 2018 09:23:56 +0000 Subject: [gnutls-devel] GnuTLS | Service Desk (from contactsuryac@gmail.com): gnutls_x509_privkey_generate doesnot return (#430) In-Reply-To: References: Message-ID: Closing due to inactivity. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/430#note_105463991 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Oct 1 11:24:14 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 01 Oct 2018 09:24:14 +0000 Subject: [gnutls-devel] GnuTLS | Service Desk (from samuel.wilson507@gmail.com): make check test suite log (#374) In-Reply-To: References: Message-ID: Issue was closed by Nikos Mavrogiannopoulos Issue #374: https://gitlab.com/gnutls/gnutls/issues/374 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/374 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Oct 1 11:24:57 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 01 Oct 2018 09:24:57 +0000 Subject: [gnutls-devel] GnuTLS | Service Desk (from p.mittermayer@gmail.com): OCSP Tests failing (#358) In-Reply-To: References: Message-ID: Closing due to inactivity. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/358#note_105464250 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Oct 1 11:24:58 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 01 Oct 2018 09:24:58 +0000 Subject: [gnutls-devel] GnuTLS | Service Desk (from p.mittermayer@gmail.com): OCSP Tests failing (#358) In-Reply-To: References: Message-ID: Issue was closed by Nikos Mavrogiannopoulos Issue #358: https://gitlab.com/gnutls/gnutls/issues/358 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/358 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Oct 1 11:31:53 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 01 Oct 2018 09:31:53 +0000 Subject: [gnutls-devel] GnuTLS | transparent client re-authentication (#571) In-Reply-To: References: Message-ID: Reassigned Issue 571 https://gitlab.com/gnutls/gnutls/issues/571 Assignee changed to Nikos Mavrogiannopoulos -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/571 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Oct 1 14:15:17 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 01 Oct 2018 12:15:17 +0000 Subject: [gnutls-devel] GnuTLS | add support for AES-CFB8 (#357) In-Reply-To: References: Message-ID: This is already supported by nettle master branch. In order to bring it to gnutls, we may have to bundle the code conditionally to keep supporting nettle 3.4. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/357#note_105522937 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Oct 1 14:15:29 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 01 Oct 2018 12:15:29 +0000 Subject: [gnutls-devel] GnuTLS | add support for AES-CMAC (#351) In-Reply-To: References: Message-ID: This is already supported by nettle master branch. In order to bring it to gnutls, we may have to bundle the code conditionally to keep supporting nettle 3.4. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/351#note_105523056 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Oct 1 15:14:25 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 01 Oct 2018 13:14:25 +0000 Subject: [gnutls-devel] GnuTLS | WIP: gnutls_init: added flag for automatic re-authentication (!766) References: Message-ID: New Merge Request !766 https://gitlab.com/gnutls/gnutls/merge_requests/766 Branches: tmp-auto-reauth to master Author: Nikos Mavrogiannopoulos Assignee: Approvers: Simon Josefsson, Dmitry Eremin-Solenikov, Hubert Kario, Tim R?hsen, Andreas Metzler, Daiki Ueno, Tom, Ander Juaristi, Tom?? Mr?z, Anderson Sasaki and GnuTLS devel mailing list This introduces the GNUTLS_AUTO_REAUTH gnutls_init() flag and makes re-authentication under TLS simpler to enable and use. ## Checklist * [x] Code modified for feature * [x] Test suite updated with functionality tests * [x] Documentation updated * [ ] Verify that new code is working in non-blocking mode ## Reviewer's checklist: * [ ] Any issues marked for closing are addressed * [ ] There is a test suite reasonably covering new functionality or modifications * [ ] Function naming, parameters, return values, types, etc., are consistent and according to `CONTRIBUTION.md` * [ ] This feature/change has adequate documentation added * [ ] No obvious mistakes in the code -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/766 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Oct 1 17:26:45 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 01 Oct 2018 15:26:45 +0000 Subject: [gnutls-devel] GnuTLS | lucky13-type of attack for SHA384 and SHA256 (#456) In-Reply-To: References: Message-ID: I'm evaluating the vulnerabilities discussed in the paper titled ["Pseudo Constant Time Implementations of TLS Are Only Pseudo Secure"](http://ia.cr/2018/747). I'm working on backporting security fixes to the Debian LTS security suite which currently shipped a patched version of GnuTLS 3.3.8. In that paper, the authors claim that: > However, we believe that the GnuTLS code is still vulnerable to > variants of the attacks presented in our paper due to its > padding-dependent memory accesses. We notified the GnuTLS team of our > concerns about this on June 13th 2018. Our understanding is that the > GnuTLS team does not plan to address the issues, but prefers to > promote the use of Encrypt-then-MAC (as specified in RFC 7366) when > legacy cipher suites are required. In the Debian security tracker, all three issues are marked as fixed in 3.5.19 or 3.6.3: * https://security-tracker.debian.org/tracker/CVE-2018-10844 * https://security-tracker.debian.org/tracker/CVE-2018-10845 * https://security-tracker.debian.org/tracker/CVE-2018-10846 Yet the above claim makes me wonder if our characterization is correct. On top of the concerns outlined by the researchers, one concern specific to LTS is we are hesitant in breaking backwards compatibility with older clients. In that respect, Encrypt-then-MAC (EtM) might not be an acceptable solution as, again according to the authors: > The ?Encrypt-then-MAC? countermeasure from RFC 7366 is supported in > mbed TLS and GnuTLS, but requires client-side support and has seen > little uptake elsewhere (e.g. neither Firefox nor Chrome supports the > EtM extension). Considering that at least 10% of TLS traffic still uses CBC, it seems a little premature to enforce those new algorithms. Removing some SHA implementations might also be a problem for us. What should be the course of action for LTS developers? Do you agree with the researcher's characterization of the solutions deployed by the GnuTLS project? Are those CVEs really completely fixed in GnuTLS? Thanks for any feedback. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/456#note_105579686 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Oct 1 19:54:13 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 01 Oct 2018 17:54:13 +0000 Subject: [gnutls-devel] GnuTLS | lucky13-type of attack for SHA384 and SHA256 (#456) In-Reply-To: References: Message-ID: The solution applied in gnutls 3.3.30 is a mitigation against the attack published by the authors. As such these CVEs are addressed. What the authors claim is that these mitigations may not be sufficient for a future attack. So backporting these mitigations (or preferably by updating to 3.3.30) is sufficient to address that vulnerability. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/456#note_105621260 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Oct 1 20:03:03 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 01 Oct 2018 18:03:03 +0000 Subject: [gnutls-devel] GnuTLS | Please document session ticket key rotation (#581) In-Reply-To: References: Message-ID: Reassigned Issue 581 https://gitlab.com/gnutls/gnutls/issues/581 Assignee changed to Ander Juaristi -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/581 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Oct 1 21:01:20 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 01 Oct 2018 19:01:20 +0000 Subject: [gnutls-devel] GnuTLS | gnutls_priority_set in post client hello function breaks handshake for clients with TLS versions < 1.3 (#580) In-Reply-To: References: Message-ID: Looks good to me, and I've confirmed that the fix works with mod_gnutls as well. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/580#note_105634512 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Oct 2 10:42:55 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 02 Oct 2018 08:42:55 +0000 Subject: [gnutls-devel] GnuTLS | gnutls_priority_set in post client hello function breaks handshake for clients with TLS versions < 1.3 (#580) In-Reply-To: References: Message-ID: Note that the more I think about it, the more I think that what I mentioned as a work-around, may be a better solution for `mod_gnutls`. The reason is that the post-client-hello is quite late (few parameters are already selected) to allow a significant change in the priorities, and if you set the priority string there you always risk for particular priority strings breaking sessions. We can with the new test guarantee that specific use-cases work, though it will never be a fail-proof way. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/580#note_105745891 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Oct 2 11:59:44 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 02 Oct 2018 09:59:44 +0000 Subject: [gnutls-devel] GnuTLS | encrypt_packet_tls13: added explicit check on iv_size bounds (!767) References: Message-ID: New Merge Request !767 https://gitlab.com/gnutls/gnutls/merge_requests/767 Branches: tmp-check-iv-size to master Author: Nikos Mavrogiannopoulos Assignee: Approvers: Simon Josefsson, Dmitry Eremin-Solenikov, Hubert Kario, Tim R?hsen, Andreas Metzler, Daiki Ueno, Tom, Ander Juaristi, Tom?? Mr?z, Anderson Sasaki and GnuTLS devel mailing list Although there are no ciphers defined for TLS1.3 which would overflow the assumed bound, an explicit check is necessary to avoid that code be a liability in future updates. ## Checklist * [x] Code modified for feature ## Reviewer's checklist: * [ ] Any issues marked for closing are addressed * [ ] There is a test suite reasonably covering new functionality or modifications * [ ] Function naming, parameters, return values, types, etc., are consistent and according to `CONTRIBUTION.md` * [ ] This feature/change has adequate documentation added * [ ] No obvious mistakes in the code -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/767 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Oct 2 12:01:21 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 02 Oct 2018 10:01:21 +0000 Subject: [gnutls-devel] GnuTLS | WIP: gnutls_init: added flag for automatic re-authentication (!766) In-Reply-To: References: Message-ID: @rockdaboot what do you think of such a flag? What is my concern is that it makes `gnutls_record_recv` also send instead of only receiving, and thus may break some select-based state machines. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/766#note_105769060 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Oct 3 10:05:32 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 03 Oct 2018 08:05:32 +0000 Subject: [gnutls-devel] GnuTLS | encrypt_packet_tls13: added explicit check on iv_size bounds (!767) In-Reply-To: References: Message-ID: Merge Request !767 was approved by Jakub Jelen Merge Request url: https://gitlab.com/gnutls/gnutls/merge_requests/767 Branches: tmp-check-iv-size to master Author: Nikos Mavrogiannopoulos Assignee: -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/767 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Oct 3 11:13:27 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 03 Oct 2018 09:13:27 +0000 Subject: [gnutls-devel] GnuTLS | encrypt_packet_tls13: added explicit check on iv_size bounds (!767) In-Reply-To: References: Message-ID: Merge Request !767 was merged Merge Request url: https://gitlab.com/gnutls/gnutls/merge_requests/767 Branches: tmp-check-iv-size to master Author: Nikos Mavrogiannopoulos Assignee: -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/767 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Oct 3 11:13:42 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 03 Oct 2018 09:13:42 +0000 Subject: [gnutls-devel] GnuTLS | encrypt_packet_tls13: added explicit check on iv_size bounds (!767) In-Reply-To: References: Message-ID: Thank you -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/767#note_106068430 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Oct 3 14:18:07 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 03 Oct 2018 12:18:07 +0000 Subject: [gnutls-devel] GnuTLS | gnutls_priority_set: do not override version on handshake (!765) In-Reply-To: References: Message-ID: Jakub Jelen started a new discussion on lib/handshake.c: > return ret; > } > > - vers = get_version(session); > - if (!vers->tls13_sem) { > - /* Here we need to renegotiate the version since the callee might > - * have disabled some TLS versions. We only do it for TLS1.2 or > - * earlier, as TLS1.3 uses a different set of ciphersuites, and > - * thus we cannot fallback. > - */ > - ret = _gnutls_negotiate_version(session, major, minor, 0); > - if (ret < 0) { > - gnutls_assert(); > - return ret; > + /* to catch any changes in the TLS protocol negotiation */ > + if (session->internals.resumed != RESUME_TRUE) { This line would deserve some comments why this does not apply for the session resumption. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/765#note_106119649 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Oct 3 14:21:05 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 03 Oct 2018 12:21:05 +0000 Subject: [gnutls-devel] GnuTLS | gnutls_priority_set: do not override version on handshake (!765) In-Reply-To: References: Message-ID: Jakub Jelen started a new discussion on lib/handshake.c: > - * earlier, as TLS1.3 uses a different set of ciphersuites, and > - * thus we cannot fallback. > - */ > - ret = _gnutls_negotiate_version(session, major, minor, 0); > - if (ret < 0) { > - gnutls_assert(); > - return ret; > + /* to catch any changes in the TLS protocol negotiation */ > + if (session->internals.resumed != RESUME_TRUE) { > + new_max = _gnutls_version_max(session); > + old_vers = get_version(session); > + > + if (!old_vers->tls13_sem || (new_max && !new_max->tls13_sem)) { > + /* Here we need to renegotiate the version since the callee might > + * have disabled some TLS versions. This will not work for protocols > + * > TLS1.3. This should say `>= TLS1.3` if I read it right. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/765#note_106120334 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Oct 3 14:22:36 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 03 Oct 2018 12:22:36 +0000 Subject: [gnutls-devel] GnuTLS | gnutls_priority_set: do not override version on handshake (!765) In-Reply-To: References: Message-ID: Jakub Jelen started a new discussion on lib/handshake.c: > + > + if (!old_vers->tls13_sem || (new_max && !new_max->tls13_sem)) { > + /* Here we need to renegotiate the version since the callee might > + * have disabled some TLS versions. This will not work for protocols > + * > TLS1.3. > + */ > + ret = _gnutls_negotiate_version(session, major, minor, 0); > + if (ret < 0) > + return gnutls_assert_val(ret); > + > + vers = get_version(session); > + if (old_vers != vers) { > + /* at this point we need to regenerate the random value to > + * avoid the peer detecting this session as a rollback > + * attempt. */ > + ret = _gnutls_gen_server_random(session, get_version(session)->id); The `get_version(session)->id` could be simplified to `vers->id`. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/765#note_106120731 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Oct 3 14:46:53 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 03 Oct 2018 12:46:53 +0000 Subject: [gnutls-devel] GnuTLS | gnutls_priority_set: do not override version on handshake (!765) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos commented on a discussion on lib/handshake.c: > + > + if (!old_vers->tls13_sem || (new_max && !new_max->tls13_sem)) { > + /* Here we need to renegotiate the version since the callee might > + * have disabled some TLS versions. This will not work for protocols > + * > TLS1.3. > + */ > + ret = _gnutls_negotiate_version(session, major, minor, 0); > + if (ret < 0) > + return gnutls_assert_val(ret); > + > + vers = get_version(session); > + if (old_vers != vers) { > + /* at this point we need to regenerate the random value to > + * avoid the peer detecting this session as a rollback > + * attempt. */ > + ret = _gnutls_gen_server_random(session, get_version(session)->id); Done -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/765#note_106126844 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Oct 3 14:47:23 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 03 Oct 2018 12:47:23 +0000 Subject: [gnutls-devel] GnuTLS | gnutls_priority_set: do not override version on handshake (!765) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos commented on a discussion on lib/handshake.c: > - * earlier, as TLS1.3 uses a different set of ciphersuites, and > - * thus we cannot fallback. > - */ > - ret = _gnutls_negotiate_version(session, major, minor, 0); > - if (ret < 0) { > - gnutls_assert(); > - return ret; > + /* to catch any changes in the TLS protocol negotiation */ > + if (session->internals.resumed != RESUME_TRUE) { > + new_max = _gnutls_version_max(session); > + old_vers = get_version(session); > + > + if (!old_vers->tls13_sem || (new_max && !new_max->tls13_sem)) { > + /* Here we need to renegotiate the version since the callee might > + * have disabled some TLS versions. This will not work for protocols > + * > TLS1.3. It is for future protocols to TLS1.3. I've updated the text for more clarity. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/765#note_106127453 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Oct 3 14:47:39 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 03 Oct 2018 12:47:39 +0000 Subject: [gnutls-devel] GnuTLS | gnutls_priority_set: do not override version on handshake (!765) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos commented on a discussion on lib/handshake.c: > return ret; > } > > - vers = get_version(session); > - if (!vers->tls13_sem) { > - /* Here we need to renegotiate the version since the callee might > - * have disabled some TLS versions. We only do it for TLS1.2 or > - * earlier, as TLS1.3 uses a different set of ciphersuites, and > - * thus we cannot fallback. > - */ > - ret = _gnutls_negotiate_version(session, major, minor, 0); > - if (ret < 0) { > - gnutls_assert(); > - return ret; > + /* to catch any changes in the TLS protocol negotiation */ > + if (session->internals.resumed != RESUME_TRUE) { Indeed. Added more text. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/765#note_106127522 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Oct 3 14:47:40 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 03 Oct 2018 12:47:40 +0000 Subject: [gnutls-devel] GnuTLS | gnutls_priority_set: do not override version on handshake (!765) In-Reply-To: References: Message-ID: All discussions on Merge Request !765 were resolved by Nikos Mavrogiannopoulos https://gitlab.com/gnutls/gnutls/merge_requests/765 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/765 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Oct 3 14:47:50 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 03 Oct 2018 12:47:50 +0000 Subject: [gnutls-devel] GnuTLS | gnutls_priority_set: do not override version on handshake (!765) In-Reply-To: References: Message-ID: Reassigned Merge Request 765 https://gitlab.com/gnutls/gnutls/merge_requests/765 Assignee changed to Jakub Jelen -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/765 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Oct 3 15:04:42 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 03 Oct 2018 13:04:42 +0000 Subject: [gnutls-devel] GnuTLS | gnutls_priority_set: do not override version on handshake (!765) In-Reply-To: References: Message-ID: Merge Request !765 was approved by Jakub Jelen Merge Request url: https://gitlab.com/gnutls/gnutls/merge_requests/765 Branches: tmp-fix-priority-set-call to master Author: Nikos Mavrogiannopoulos Assignee: Jakub Jelen -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/765 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Oct 3 15:58:16 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 03 Oct 2018 13:58:16 +0000 Subject: [gnutls-devel] GnuTLS | WIP: AF_ALG support for GnuTLS (!555) In-Reply-To: References: Message-ID: Dmitry Eremin-Solenikov started a new discussion on lib/accelerated/afalg.c: > + [GNUTLS_CIPHER_AES_192_CBC] = "cbc(aes)", > + [GNUTLS_CIPHER_AES_256_CBC] = "cbc(aes)", > + [GNUTLS_CIPHER_3DES_CBC] = "cbc(des3_ede)", > + [GNUTLS_CIPHER_CAMELLIA_128_CBC] = "cbc(camellia)", > + [GNUTLS_CIPHER_CAMELLIA_192_CBC] = "cbc(camellia)", > + [GNUTLS_CIPHER_CAMELLIA_256_CBC] = "cbc(camellia)", > + [GNUTLS_CIPHER_SALSA20_256] = "salsa20", > +}; > + > +static int > +afalg_cipher_init(gnutls_cipher_algorithm_t algorithm, void **_ctx, int enc) > +{ > + struct kcapi_handle *handle = NULL; > + struct kcapi_ctx *ctx; > + > + if (kcapi_cipher_init(&handle, gnutls_cipher_map[algorithm], 0) < 0) { A check is needed that `algorithm < ARRAY_SIZE(gnutls_cipher_map)` -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/555#note_106147368 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Oct 3 16:01:20 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 03 Oct 2018 14:01:20 +0000 Subject: [gnutls-devel] GnuTLS | WIP: AF_ALG support for GnuTLS (!555) In-Reply-To: References: Message-ID: @smuellerDD do you still plan to work on this MR? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/555#note_106148230 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Oct 3 19:40:23 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 03 Oct 2018 17:40:23 +0000 Subject: [gnutls-devel] GnuTLS | Configure does not chek if gperf is installed (#582) References: Message-ID: New Issue was created. Issue 582: https://gitlab.com/gnutls/gnutls/issues/582 Author: Simo Sorce Assignee: Causes compiler failure later with supported_exts.h file not found -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/582 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Oct 3 19:54:57 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 03 Oct 2018 17:54:57 +0000 Subject: [gnutls-devel] GnuTLS | WIP: AF_ALG support for GnuTLS (!555) In-Reply-To: References: Message-ID: Hi Dmitry, > @smuellerDD do you still plan to work on this MR? Yes, I do. Over the last months, however, I was distracted by another larger development work that I needed to complete. I should be able to get back to this MR shortly. Ciao Stephan -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/555#note_106221185 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Thu Oct 4 08:09:10 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 04 Oct 2018 06:09:10 +0000 Subject: [gnutls-devel] GnuTLS | gnutls_priority_set in post client hello function breaks handshake for clients with TLS versions < 1.3 (#580) In-Reply-To: References: Message-ID: Issue was closed by Nikos Mavrogiannopoulos Issue #580: https://gitlab.com/gnutls/gnutls/issues/580 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/580 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Thu Oct 4 08:09:11 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 04 Oct 2018 06:09:11 +0000 Subject: [gnutls-devel] GnuTLS | gnutls_priority_set: do not override version on handshake (!765) In-Reply-To: References: Message-ID: Merge Request !765 was merged Merge Request url: https://gitlab.com/gnutls/gnutls/merge_requests/765 Branches: tmp-fix-priority-set-call to master Author: Nikos Mavrogiannopoulos Assignee: Jakub Jelen -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/765 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Thu Oct 4 08:41:08 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 04 Oct 2018 06:41:08 +0000 Subject: [gnutls-devel] GnuTLS | Configure does not chek if gperf is installed (#582) In-Reply-To: References: Message-ID: On a release build that shouldn't be a problem as the `supported_exts.h` file should be present. However that affects building from git. Maybe instead of enforcing that in configure.ac which will affect released builds we can require mandatory/recommended software for building from git at bootstrap time as: ``` diff --git a/bootstrap.conf b/bootstrap.conf index 3c9618b21..a382391dd 100644 --- a/bootstrap.conf +++ b/bootstrap.conf @@ -82,3 +82,25 @@ bootstrap_post_import_hook () # Automake requires that ChangeLog exist. touch ChangeLog || return 1 } + +bootstrap_epilogue () +{ + GPERF=$(which gperf) + AUTOGEN=$(which autogen) + SOFTHSM2=$(which softhsm2-util) + + if test -z "${GPERF}";then + echo "error: 'gperf' is not installed; see README.md for required software" + return 1 + fi + + if test -z "${AUTOGEN}";then + echo "error: 'autogen' is not installed; see README.md for required software" + return 1 + fi + + if test -z "${SOFTHSM2}";then + echo "error: 'softhsm' (2.0.0 or later) is not installed; see README.md for required software" + return 1 + fi +} ``` @rockdaboot what do you think? Is that the "right way" to use bootstrap? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/582#note_106298246 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Thu Oct 4 08:43:41 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 04 Oct 2018 06:43:41 +0000 Subject: [gnutls-devel] GnuTLS | transparent client re-authentication (#571) In-Reply-To: References: Message-ID: > The blocker in the past was the fact that `gnutls_record_send` and `gnutls_record_recv` would only do whatever they were asked (read and write). Currently however that's not the case, and `gnutls_record_recv` has internal logic which allows it to do more than just receiving data (e.g., already handles rekey). I was wrong on the above. There was not such logic, and as such the introduction of such a simplification will bring that in. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/571#note_106298604 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Thu Oct 4 13:07:10 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 04 Oct 2018 11:07:10 +0000 Subject: [gnutls-devel] GnuTLS | transparent client re-authentication (#571) In-Reply-To: References: Message-ID: I don't think that is a problem as long as you update the docs to say that `gnutls_record_recv` *might* also send data if needed. Since this will not be default behavior (will only happen when certain flags are provided) it won't break existing code, and those who use these flags know what they're up to. For instance, if I'm working with non-blocking sockets and calling `gnutls_record_recv` I know I need to check the socket's ready for both reading & writing. If my application is compiled against an older version of GnuTLS that doesn't support this, the code would still work. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/571#note_106440627 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Thu Oct 4 17:25:53 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 04 Oct 2018 15:25:53 +0000 Subject: [gnutls-devel] GnuTLS | Update docs for session ticket key rotation (!768) References: Message-ID: New Merge Request !768 https://gitlab.com/gnutls/gnutls/merge_requests/768 Branches: ajuaristi-update-docs to master Author: Ander Juaristi Assignee: Approvers: Simon Josefsson, Nikos Mavrogiannopoulos, Dmitry Eremin-Solenikov, Hubert Kario, Tim R?hsen, Andreas Metzler, Daiki Ueno, Tom, Tom?? Mr?z, Anderson Sasaki and GnuTLS devel mailing list Add a description of the new feature/bug fix. Reference any relevant bugs. ## Checklist * [ ] Documentation updated ## Reviewer's checklist: * [ ] Any issues marked for closing are addressed * [ ] This feature/change has adequate documentation added * [ ] No obvious mistakes -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/768 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Thu Oct 4 17:27:50 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 04 Oct 2018 15:27:50 +0000 Subject: [gnutls-devel] GnuTLS | Please document session ticket key rotation (#581) In-Reply-To: References: Message-ID: > master key would be shared across forks as before You're right. `gnutls_session_ticket_key_generate` does not modify internal state (I think it doesn't even take a `gnutls_session` as an argument) so it should be perfectly fine across forks. I've just opened MR !768. Please review it when you have some time. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/581#note_106569977 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Thu Oct 4 18:36:31 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 04 Oct 2018 16:36:31 +0000 Subject: [gnutls-devel] GnuTLS | Configure does not chek if gperf is installed (#582) In-Reply-To: References: Message-ID: bootstrap provides a mechanism for checking prerequisites. Pleae have a look into bootstrap.conf and add it to the 'buildreq' var. I am just in a hurry right now (always most of the time :-() -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/582#note_106587494 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Oct 5 02:04:18 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 05 Oct 2018 00:04:18 +0000 Subject: [gnutls-devel] GnuTLS | WIP: AF_ALG support for GnuTLS (!555) In-Reply-To: References: Message-ID: Stephan, thank you! I'm looking forward to seeing this MR updated. I'd like to use it to actively test in-kernel algs implementation. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/555#note_106660059 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Oct 5 08:17:30 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 05 Oct 2018 06:17:30 +0000 Subject: [gnutls-devel] GnuTLS | WIP: AF_ALG support for GnuTLS (!555) In-Reply-To: References: Message-ID: Hi Dimitri -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/555#note_106695730 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Oct 5 08:21:04 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 05 Oct 2018 06:21:04 +0000 Subject: [gnutls-devel] GnuTLS | Getting error "Please insert token 'TEE_TOKEN' in slot and press enter" on searching private objects. (#583) References: Message-ID: New Issue was created. Issue 583: https://gitlab.com/gnutls/gnutls/issues/583 Author: Sahil Malhotra Assignee: Hi Met following issue when trying to list down the private objects. root at localhost:/greengrass# p11tool --login --list-all-privkeys pkcs11:model=PKCS11-OP-TEE;manufacturer=NXP;serial=1;token=TEE_TOKEN Token 'TEE_TOKEN' with URL 'pkcs11:model=PKCS11-OP-TEE;manufacturer=NXP;serial=1;token=TEE_TOKEN' requires user PIN Enter PIN: Object 0: URL: pkcs11:model=PKCS11-OP-TEE;manufacturer=NXP;serial=1;token=TEE_TOKEN;id=%00%00;object=iotkey;type=private Please insert token 'TEE_TOKEN' in slot and press enter On analyzing the code I found at https://gitlab.com/gnutls/gnutls/blob/master/lib/pkcs11_privkey.c#L217 we are checking if (count == 1) for success, I was not able to understand why this check was added, because if no object matches with template C_FindObjects will write 0 in count. Please check this and let me know if I am missing something. Thanks Sahil -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/583 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Oct 5 12:22:24 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 05 Oct 2018 10:22:24 +0000 Subject: [gnutls-devel] GnuTLS | Update docs for session ticket key rotation (!768) In-Reply-To: References: Message-ID: Airtower started a new discussion on doc/cha-gtls-app.texi: > A server supporting session tickets must generate ticket encryption > and authentication keys using @funcref{gnutls_session_ticket_key_generate}. > Those keys should be associated with the GnuTLS session using > - at funcref{gnutls_session_ticket_enable_server}, and should be rotated regularly > -(e.g., every few hours), to prevent them from becoming long-term keys which > -if revealed could be used to decrypt all previous sessions. > + at funcref{gnutls_session_ticket_enable_server}. > + > +GnuTLS will rotate these keys regularly. The key rotation interval can be specified with > + at funcref{gnutls_db_set_cache_expiration}. Every such interval, new keys will be generated from the initial keys > +that were first established using @funcref{gnutls_session_ticket_enable_server}. This is > +a necessary mechanism to prevent the keys from becoming long-term keys and as such preserve > +forward-secrecy in the issued session tickets. > + > +The key generated with @funcref{gnutls_session_ticket_key_generate} will survive across forks. I'm not sure what you mean by this paragraph. Does that mean that sessions won't stay the same across forks, or may the master keys start to diverge after forks as the processes call `gnutls_session_ticket_enable_server()`? The former is no problem from my point of view. In the latter case, multi-process servers like Apache with mod_gnutls would need some way to synchronize keys (which would also be useful for server clusters anyway). -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/768#note_106767939 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Oct 5 12:29:52 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 05 Oct 2018 10:29:52 +0000 Subject: [gnutls-devel] GnuTLS | gnutls_priority_set in post client hello function breaks handshake for clients with TLS versions < 1.3 (#580) In-Reply-To: References: Message-ID: Parsing the SNI extension in mod_gnutls would mean basically re-implementing SNI parsing that GnuTLS does anyway, though, and as you noted it would break with encrypted SNI. Is there another hook that would be more suitable, i.e. at a point when GnuTLS has parsed the client hello, but before further parameters have been selected? I'm facing a similar issue regarding ALPN, but that probably warrants a separate ticket and isn't a regression. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/580#note_106769571 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Oct 5 15:52:36 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 05 Oct 2018 13:52:36 +0000 Subject: [gnutls-devel] GnuTLS | Update docs for session ticket key rotation (!768) In-Reply-To: References: Message-ID: > Does that mean that sessions won't stay the same across forks, or may the master keys start to diverge after forks No, it doesn't mean that. You were right in your initial assumptions: assuming the time is the same in all forked processes (which it should) then rotated keys should all be the same. I should have said something in the lines of "the whole key rotation mechanism is safe across forks", right? I'll update the description.... -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/768#note_106814843 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Oct 5 17:39:47 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 05 Oct 2018 15:39:47 +0000 Subject: [gnutls-devel] GnuTLS | Update docs for session ticket key rotation (!768) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos started a new discussion on doc/cha-gtls-app.texi: > and authentication keys using @funcref{gnutls_session_ticket_key_generate}. > Those keys should be associated with the GnuTLS session using > - at funcref{gnutls_session_ticket_enable_server}, and should be rotated regularly > -(e.g., every few hours), to prevent them from becoming long-term keys which > -if revealed could be used to decrypt all previous sessions. > + at funcref{gnutls_session_ticket_enable_server}. > + > +GnuTLS will rotate these keys regularly. The key rotation interval can be specified with > + at funcref{gnutls_db_set_cache_expiration}. Every such interval, new keys will be generated from the initial keys > +that were first established using @funcref{gnutls_session_ticket_enable_server}. This is > +a necessary mechanism to prevent the keys from becoming long-term keys and as such preserve > +forward-secrecy in the issued session tickets. > + > +The master key and the rotation key mechanism will both survive across forks. Forked processes > +should rotate the key all at the same time and should generate exactly the same new keys. > +This of course assumes all processes have the same time, which should be true. What about a simpler variant: "Assuming all processes share the same time, the same keys will be generated across" -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/768#note_106851278 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Oct 5 17:40:41 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 05 Oct 2018 15:40:41 +0000 Subject: [gnutls-devel] GnuTLS | Update docs for session ticket key rotation (!768) In-Reply-To: References: Message-ID: Other than the nit above it looks good to me. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/768#note_106851504 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Oct 5 17:40:45 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 05 Oct 2018 15:40:45 +0000 Subject: [gnutls-devel] GnuTLS | Update docs for session ticket key rotation (!768) In-Reply-To: References: Message-ID: Merge Request !768 was approved by Nikos Mavrogiannopoulos Merge Request url: https://gitlab.com/gnutls/gnutls/merge_requests/768 Branches: ajuaristi-update-docs to master Author: Ander Juaristi Assignee: -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/768 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Oct 5 17:46:15 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 05 Oct 2018 15:46:15 +0000 Subject: [gnutls-devel] GnuTLS | Update docs for session ticket key rotation (!768) In-Reply-To: References: Message-ID: Airtower started a new discussion on doc/cha-gtls-app.texi: > A server supporting session tickets must generate ticket encryption > and authentication keys using @funcref{gnutls_session_ticket_key_generate}. > Those keys should be associated with the GnuTLS session using > - at funcref{gnutls_session_ticket_enable_server}, and should be rotated regularly > -(e.g., every few hours), to prevent them from becoming long-term keys which > -if revealed could be used to decrypt all previous sessions. > + at funcref{gnutls_session_ticket_enable_server}. > + > +GnuTLS will rotate these keys regularly. The key rotation interval can be specified with > + at funcref{gnutls_db_set_cache_expiration}. Every such interval, new keys will be generated from the initial keys > +that were first established using @funcref{gnutls_session_ticket_enable_server}. This is Shouldn't this be `gnutls_session_ticket_key_generate` instead of `gnutls_session_ticket_enable_server`? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/768#note_106852851 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Oct 5 18:19:36 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 05 Oct 2018 16:19:36 +0000 Subject: [gnutls-devel] GnuTLS | Configure does not chek if gperf is installed (#582) In-Reply-To: References: Message-ID: What else do we want to check for ? makeinfo (docs), autopoint (internationalization, a separate package from gettext on some systems), rsync (for getting .po files), tar (make dist), xz (make dist), ... ? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/582#note_106859572 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Oct 5 19:33:51 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 05 Oct 2018 17:33:51 +0000 Subject: [gnutls-devel] GnuTLS | Configure does not chek if gperf is installed (#582) In-Reply-To: References: Message-ID: I guess, everything that would make normal compilation fail from git if missing. We can ignore the `make dist` target as it is not that common. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/582#note_106871888 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Oct 5 19:35:57 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 05 Oct 2018 17:35:57 +0000 Subject: [gnutls-devel] GnuTLS | Configure does not chek if gperf is installed (#582) In-Reply-To: References: Message-ID: I think for rsync there is a fallback in bootstrap. So just makeinfo and autopoint -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/582#note_106872119 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Oct 5 19:36:10 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 05 Oct 2018 17:36:10 +0000 Subject: [gnutls-devel] GnuTLS | Configure does not chek if gperf is installed (#582) In-Reply-To: References: Message-ID: Reassigned Issue 582 https://gitlab.com/gnutls/gnutls/issues/582 Assignee changed to Tim R?hsen -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/582 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Oct 5 19:43:38 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 05 Oct 2018 17:43:38 +0000 Subject: [gnutls-devel] GnuTLS | Let bootstrap check for gperf, makeinfo, rsync, autopoint (!769) References: Message-ID: New Merge Request !769 https://gitlab.com/gnutls/gnutls/merge_requests/769 Branches: tmp-check-prereqs to master Author: Tim R?hsen Assignee: Approvers: Simon Josefsson, Nikos Mavrogiannopoulos, Dmitry Eremin-Solenikov, Hubert Kario, Andreas Metzler, Daiki Ueno, Tom, Ander Juaristi, Tom?? Mr?z, Anderson Sasaki and GnuTLS devel mailing list Fixes #582 ## Reviewer's checklist: * [ ] Any issues marked for closing are addressed * [ ] No obvious mistakes in the code -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/769 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Oct 5 21:51:09 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 05 Oct 2018 19:51:09 +0000 Subject: [gnutls-devel] GnuTLS | Configure does not chek if gperf is installed (#582) In-Reply-To: References: Message-ID: Reassigned Issue 582 https://gitlab.com/gnutls/gnutls/issues/582 Assignee changed from Tim R?hsen to Unassigned -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/582 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Oct 5 22:05:59 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 05 Oct 2018 20:05:59 +0000 Subject: [gnutls-devel] GnuTLS | Update docs for session ticket key rotation (!768) In-Reply-To: References: Message-ID: Airtower commented on a discussion on doc/cha-gtls-app.texi: > and authentication keys using @funcref{gnutls_session_ticket_key_generate}. > Those keys should be associated with the GnuTLS session using > - at funcref{gnutls_session_ticket_enable_server}, and should be rotated regularly > -(e.g., every few hours), to prevent them from becoming long-term keys which > -if revealed could be used to decrypt all previous sessions. > + at funcref{gnutls_session_ticket_enable_server}. > + > +GnuTLS will rotate these keys regularly. The key rotation interval can be specified with > + at funcref{gnutls_db_set_cache_expiration}. Every such interval, new keys will be generated from the initial keys > +that were first established using @funcref{gnutls_session_ticket_enable_server}. This is > +a necessary mechanism to prevent the keys from becoming long-term keys and as such preserve > +forward-secrecy in the issued session tickets. > + > +The master key and the rotation key mechanism will both survive across forks. Forked processes > +should rotate the key all at the same time and should generate exactly the same new keys. > +This of course assumes all processes have the same time, which should be true. Follow-up question that might become relevant: Would it be possible to share the master key across machines in a server cluster, assuming good clock synchronization? With TLS versions before 1.3 the cluster could use a shared session cache, but with ticket-based resumption only that's not going to work. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/768#note_106902959 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Oct 5 22:57:12 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 05 Oct 2018 20:57:12 +0000 Subject: [gnutls-devel] GnuTLS | tls13/prf fails with hardening LDFLAGS (#584) References: Message-ID: New Issue was created. Issue 584: https://gitlab.com/gnutls/gnutls/issues/584 Author: Dimitri John Ledkov Assignee: ## Description of problem: ./tls13/prf fails with hardened LDFLAGS I'm not sure if the testcase, or library, or both get miss-build. And ideally, things would build and test suite correctly (or like strip/warn against incompatible LDFLAGS). ## Version of gnutls used: git master, 3.6.4 ## Distributor of gnutls (e.g., Ubuntu, Fedora, RHEL) Ubuntu ## How reproducible: ` ./configure LDFLAGS='-Wl,-Bsymbolic-functions -Wl,-z,relro -Wl,-z,now' make -j8 make -C tests tls13/prf $ ./tests/tls13/prf ` ## Actual results: ` $ ./tests/tls13/prf gnutls_prf: output doesn't match for 'key expansion' got \x86\xdb\x26\xde\x6a\x57\x04\x5e\xa1\xc0\x13\x8c\x88\x85\xc4\xb0\xf9\x44\x38\x71\x4d\x34\xa4\x14\x21\x89\xb2\xda\x78\xc3\x6f\xd9\x79\xd5 expected \xfb\xcb\x96\x87\x8c\x64\x8b\x60\xef\xdc\x76\xb0\x7c\x3b\xd1\x50\x1e\xb1\x3f\x39\xb2\x20\x74\x2c\xb2\x76\x12\x9f\xfc\xad\xb9\xce\x1d\x9a _check_wait_status:157: Child died with status 1 ` ## Expected results: ` # no output, exit code 0 ` -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/584 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Sat Oct 6 08:49:27 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sat, 06 Oct 2018 06:49:27 +0000 Subject: [gnutls-devel] GnuTLS | gnutls_session_set_id() has a unit test and prohibits the client from going through the resumption path (#585) References: Message-ID: New Issue was created. Issue 585: https://gitlab.com/gnutls/gnutls/issues/585 Author: Nikos Mavrogiannopoulos Assignee: -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/585 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Sat Oct 6 08:49:31 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sat, 06 Oct 2018 06:49:31 +0000 Subject: [gnutls-devel] GnuTLS | gnutls_session_set_id() has a unit test and prohibits the client from going through the resumption path (#585) In-Reply-To: References: Message-ID: Reassigned Issue 585 https://gitlab.com/gnutls/gnutls/issues/585 Assignee changed to Nikos Mavrogiannopoulos -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/585 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Sat Oct 6 11:00:06 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sat, 06 Oct 2018 09:00:06 +0000 Subject: [gnutls-devel] GnuTLS | Let bootstrap check for gperf, makeinfo, rsync, autopoint (!769) In-Reply-To: References: Message-ID: Some CI runners don't have `makeinfo` installed. I put it into the checklist since people asked for it on other projects I maintain. Because docs are built by default (./configure without options) and errors building docs don't make it obvious what's missing. @nmav You should decide whether to update the CI images or to remove `makeinfo` from `bootstrap.conf`. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/769#note_106949062 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Sat Oct 6 16:43:06 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sat, 06 Oct 2018 14:43:06 +0000 Subject: [gnutls-devel] GnuTLS | Let bootstrap check for gperf, makeinfo, rsync, autopoint (!769) In-Reply-To: References: Message-ID: If it works now without makeinfo let's not make it required. There are few occasions where one may not care about building documentation but may want to test interoperation of gnutls or so, and it makes sense to simplify them. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/769#note_106967749 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Sat Oct 6 17:18:19 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sat, 06 Oct 2018 15:18:19 +0000 Subject: [gnutls-devel] GnuTLS | Update docs for session ticket key rotation (!768) In-Reply-To: References: Message-ID: Ander Juaristi commented on a discussion on doc/cha-gtls-app.texi: > and authentication keys using @funcref{gnutls_session_ticket_key_generate}. > Those keys should be associated with the GnuTLS session using > - at funcref{gnutls_session_ticket_enable_server}, and should be rotated regularly > -(e.g., every few hours), to prevent them from becoming long-term keys which > -if revealed could be used to decrypt all previous sessions. > + at funcref{gnutls_session_ticket_enable_server}. > + > +GnuTLS will rotate these keys regularly. The key rotation interval can be specified with > + at funcref{gnutls_db_set_cache_expiration}. Every such interval, new keys will be generated from the initial keys > +that were first established using @funcref{gnutls_session_ticket_enable_server}. This is > +a necessary mechanism to prevent the keys from becoming long-term keys and as such preserve > +forward-secrecy in the issued session tickets. > + > +The master key and the rotation key mechanism will both survive across forks. Forked processes > +should rotate the key all at the same time and should generate exactly the same new keys. > +This of course assumes all processes have the same time, which should be true. I think it should be possible using memcached or something similar (I remember having this exact conversation with @nmav some time ago). In any case, I believe this is out of the scope of GnuTLS and should be done by an external piece of software. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/768#note_106969533 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Sat Oct 6 17:54:12 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sat, 06 Oct 2018 15:54:12 +0000 Subject: [gnutls-devel] GnuTLS | gnutls_session_set_id() has a unit test and prohibits the client from going through the resumption path (#585) In-Reply-To: References: Message-ID: Issue was closed by Nikos Mavrogiannopoulos Issue #585: https://gitlab.com/gnutls/gnutls/issues/585 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/585 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Sat Oct 6 21:40:02 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sat, 06 Oct 2018 19:40:02 +0000 Subject: [gnutls-devel] GnuTLS | Update docs for session ticket key rotation (!768) In-Reply-To: References: Message-ID: Airtower commented on a discussion on doc/cha-gtls-app.texi: > and authentication keys using @funcref{gnutls_session_ticket_key_generate}. > Those keys should be associated with the GnuTLS session using > - at funcref{gnutls_session_ticket_enable_server}, and should be rotated regularly > -(e.g., every few hours), to prevent them from becoming long-term keys which > -if revealed could be used to decrypt all previous sessions. > + at funcref{gnutls_session_ticket_enable_server}. > + > +GnuTLS will rotate these keys regularly. The key rotation interval can be specified with > + at funcref{gnutls_db_set_cache_expiration}. Every such interval, new keys will be generated from the initial keys > +that were first established using @funcref{gnutls_session_ticket_enable_server}. This is > +a necessary mechanism to prevent the keys from becoming long-term keys and as such preserve > +forward-secrecy in the issued session tickets. > + > +The master key and the rotation key mechanism will both survive across forks. Forked processes > +should rotate the key all at the same time and should generate exactly the same new keys. > +This of course assumes all processes have the same time, which should be true. I agree that the transfer should be done by the application. However, to implement that the application developer needs to know whether transferring the content of the `gnutls_datum_t` filled by `gnutls_session_ticket_key_generate` will work across machines that may have different architectures. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/768#note_106989051 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Sun Oct 7 08:17:50 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sun, 07 Oct 2018 06:17:50 +0000 Subject: [gnutls-devel] GnuTLS | Let bootstrap check for gperf, makeinfo, rsync, autopoint (!769) In-Reply-To: References: Message-ID: Hmm, it seems freebsd doesn't have rsync, but rsync is also not listed in README.md. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/769#note_107008145 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Sun Oct 7 08:56:46 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sun, 07 Oct 2018 06:56:46 +0000 Subject: [gnutls-devel] GnuTLS | gnutls_priority_set in post client hello function breaks handshake for clients with TLS versions < 1.3 (#580) In-Reply-To: References: Message-ID: Unfortunately not; processing happens while parsing, so there is no other possible hook. Note that re-implementing the extension/SNI parsing, is not really an issue as you can re-use the same functions use to parse the extensions by gnutls. The drawback as you say could be encrypted SNI (when supported by gnutls), but we can export the required functionality to ease that task. The disadvantage is that such support will not be transparent, but anyway I doubt that the deployment of encrypted SNI can come without any changes as the proposed protocol is now. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/580#note_107009145 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Sun Oct 7 09:19:14 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sun, 07 Oct 2018 07:19:14 +0000 Subject: [gnutls-devel] GnuTLS | gnutls-cli - incomplete DANE support (#557) In-Reply-To: References: Message-ID: > I personally _think_ gnutls-cli dane support is not very useful as it is, i.e. this is not a documentation issue but an incomplete feature. I agree, but this was an intentional design decision. DANE was implemented as an additional certificate validation mechanism, rather than as the primary validation mechanism which will trigger PKIX validation if it says so. > Let's assume I want to use gnutls-cli to check whether I have set up DANE correctly. ... > However I think we agree that it does not make sense to implement these arcane (possibly changing) policies in gnutls-cli. > I do think though that the above 1/2abc should not be necessary, assuming the TLS-A choice is correct gnutls-cli should be able to verify trust , taking DANE correctly into account. I would not be against such an improvement. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/557#note_107010123 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Sun Oct 7 10:45:31 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sun, 07 Oct 2018 08:45:31 +0000 Subject: [gnutls-devel] GnuTLS | Let bootstrap check for gperf, makeinfo, rsync, autopoint (!769) In-Reply-To: References: Message-ID: As with makeinfo, the question is who are the target people for building from git and who is tarball building for ? Building from git requires a fully installed+configured development environment. So I don't see a problem for rsync and makeinfo being prerequisites. Building from tarball doesn't require a development system and thus not makeinfo, rsync, autotools, gperf, ... so why not building+testing from tarball in systems like FreeBSD, MinGW, ... ? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/769#note_107017366 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Sun Oct 7 11:28:24 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sun, 07 Oct 2018 09:28:24 +0000 Subject: [gnutls-devel] GnuTLS | Let bootstrap check for gperf, makeinfo, rsync, autopoint (!769) In-Reply-To: References: Message-ID: I think the target for this change is to require everything that will break the build. The target group should be developers compiling the gnutls lib and apps (not necessarily doing a release or generating documentation). Given that the freebsd works without rsync, I do not think we should require it. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/769#note_107025994 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Sun Oct 7 17:28:37 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sun, 07 Oct 2018 15:28:37 +0000 Subject: [gnutls-devel] GnuTLS | Allow non ASCII usernames for psk (#586) References: Message-ID: New Issue was created. Issue 586: https://gitlab.com/gnutls/gnutls/issues/586 Author: Nikos Mavrogiannopoulos Assignee: The available APIs for psk usernames assume strings which can be null terminated. This prohibits the use of randomly generated ids or uuids as usernames. We should provide new APIs which can handle that. Potential user is the dtls psk authentication in openconnect protocol -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/586 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Sun Oct 7 17:31:26 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sun, 07 Oct 2018 15:31:26 +0000 Subject: [gnutls-devel] GnuTLS | optional: consider: client API to save and re-use state per server (#222) In-Reply-To: References: Message-ID: I am no longer sure that we need that feature. It looks like something niche with no practical advantages. Closing. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/222#note_107048330 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Sun Oct 7 18:09:37 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sun, 07 Oct 2018 16:09:37 +0000 Subject: [gnutls-devel] GnuTLS | tls13/prf fails with hardening LDFLAGS (#584) In-Reply-To: References: Message-ID: I do not believe the LDFLAGS cause that. Fedora uses these and 3.6.4 test suite runs fine. This may be an unrelated issue you are seeing. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/584#note_107050629 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Oct 8 08:20:17 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 08 Oct 2018 06:20:17 +0000 Subject: [gnutls-devel] GnuTLS | Update docs for session ticket key rotation (!768) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos commented on a discussion on doc/cha-gtls-app.texi: > and authentication keys using @funcref{gnutls_session_ticket_key_generate}. > Those keys should be associated with the GnuTLS session using > - at funcref{gnutls_session_ticket_enable_server}, and should be rotated regularly > -(e.g., every few hours), to prevent them from becoming long-term keys which > -if revealed could be used to decrypt all previous sessions. > + at funcref{gnutls_session_ticket_enable_server}. > + > +GnuTLS will rotate these keys regularly. The key rotation interval can be specified with > + at funcref{gnutls_db_set_cache_expiration}. Every such interval, new keys will be generated from the initial keys > +that were first established using @funcref{gnutls_session_ticket_enable_server}. This is > +a necessary mechanism to prevent the keys from becoming long-term keys and as such preserve > +forward-secrecy in the issued session tickets. > + > +The master key and the rotation key mechanism will both survive across forks. Forked processes > +should rotate the key all at the same time and should generate exactly the same new keys. > +This of course assumes all processes have the same time, which should be true. What about replacing ``` The master key and the rotation key mechanism will both survive across forks. Forked processes should rotate the key all at the same time and should generate exactly the same new keys. This of course assumes all processes have the same time, which should be true. ``` with: ``` The master key can be shared between processes or between systems. Processes which share the same master key will generate the same rotate subkeys, assuming they share the same time. ``` -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/768#note_107114650 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Oct 8 10:07:02 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 08 Oct 2018 08:07:02 +0000 Subject: [gnutls-devel] GnuTLS | Provide a configuration file (#587) References: Message-ID: New Issue was created. Issue 587: https://gitlab.com/gnutls/gnutls/issues/587 Author: Nikos Mavrogiannopoulos Assignee: The approach of gnutls is to deprecate deprecate algorithms like SHA1 in the library, and change TLS settings on various versions which improve the security. However there are cases which these items are handled on the operating system level (e.g., fedora crypto-policies), and as such it would be beneficial to allow such settings to switch system-wide. Currently we only provide a way to create application-specific or system-specific priority strings and modify the default priority string set with `gnutls_set_default_priority`; this only affects a subset of applications that use gnutls (i.e., not the ones that specifically set a priority string). We should enhance the currently provided configuration file (system priority file), to be able to configure: * Set/Unset deprecated hashes for signature algorithms * Set global TLS options which no application could override; this should include - disallowed TLS versions - disallowed signature algorithms - disallowed ciphers - disallowed macs c.f., [inih](https://github.com/benhoyt/inih) -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/587 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Oct 8 10:15:49 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 08 Oct 2018 08:15:49 +0000 Subject: [gnutls-devel] GnuTLS | Provide a configuration file (#587) In-Reply-To: References: Message-ID: > Set global TLS options which no application could override IMHO a bad idea. An application should be able to connect to old servers, if the user explicitly requests it. E.g. Wget has an option to enable SSL since there are many older IOT systems, e.g. in your local network. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/587#note_107136663 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Oct 8 10:25:00 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 08 Oct 2018 08:25:00 +0000 Subject: [gnutls-devel] GnuTLS | tls13/prf fails with hardening LDFLAGS (#584) In-Reply-To: References: Message-ID: At least it's reproducible on Debian unstable. I'll investigate when having more time. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/584#note_107138707 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Oct 8 10:34:34 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 08 Oct 2018 08:34:34 +0000 Subject: [gnutls-devel] GnuTLS | tls13/prf fails with hardening LDFLAGS (#584) In-Reply-To: References: Message-ID: `./configure LDFLAGS='-Wl,-Bsymbolic-functions'` is enough to reproduce. Wild guess: Maybe it does interfere with `__attribute__ ((visibility ("protected")))` in prf.c. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/584#note_107140963 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Oct 8 11:29:01 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 08 Oct 2018 09:29:01 +0000 Subject: [gnutls-devel] GnuTLS | Skip tests/tls13/prf.c if visibility 'protected' doesn't work (!770) References: Message-ID: New Merge Request !770 https://gitlab.com/gnutls/gnutls/merge_requests/770 Branches: tmp-fix-584 to master Author: Tim R?hsen Assignee: Approvers: Simon Josefsson, Nikos Mavrogiannopoulos, Dmitry Eremin-Solenikov, Hubert Kario, Andreas Metzler, Daiki Ueno, Tom, Ander Juaristi, Tom?? Mr?z, Anderson Sasaki and GnuTLS devel mailing list Overriding gnutls_rnd() with visibility 'protected' doesn't always work. E.g. LDFLAGS="-Wl,-Bsymbolic-functions" seems to have priority on Debian derived systems. Fixes #584 ## Checklist * [*] Code modified for feature * [*] Test suite updated with functionality tests ## Reviewer's checklist: * [ ] Any issues marked for closing are addressed * [ ] There is a test suite reasonably covering new functionality or modifications * [ ] Function naming, parameters, return values, types, etc., are consistent and according to `CONTRIBUTION.md` * [ ] This feature/change has adequate documentation added * [ ] No obvious mistakes in the code -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/770 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Oct 8 11:31:16 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 08 Oct 2018 09:31:16 +0000 Subject: [gnutls-devel] GnuTLS | tls13/prf fails with hardening LDFLAGS (#584) In-Reply-To: References: Message-ID: !770 should fix this (it does for me) by SKIPping the test if visibility 'protected' is not functional. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/584#note_107156360 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Oct 8 11:45:29 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 08 Oct 2018 09:45:29 +0000 Subject: [gnutls-devel] GnuTLS | Update docs for session ticket key rotation (!768) In-Reply-To: References: Message-ID: Airtower commented on a discussion on doc/cha-gtls-app.texi: > and authentication keys using @funcref{gnutls_session_ticket_key_generate}. > Those keys should be associated with the GnuTLS session using > - at funcref{gnutls_session_ticket_enable_server}, and should be rotated regularly > -(e.g., every few hours), to prevent them from becoming long-term keys which > -if revealed could be used to decrypt all previous sessions. > + at funcref{gnutls_session_ticket_enable_server}. > + > +GnuTLS will rotate these keys regularly. The key rotation interval can be specified with > + at funcref{gnutls_db_set_cache_expiration}. Every such interval, new keys will be generated from the initial keys > +that were first established using @funcref{gnutls_session_ticket_enable_server}. This is > +a necessary mechanism to prevent the keys from becoming long-term keys and as such preserve > +forward-secrecy in the issued session tickets. > + > +The master key and the rotation key mechanism will both survive across forks. Forked processes > +should rotate the key all at the same time and should generate exactly the same new keys. > +This of course assumes all processes have the same time, which should be true. That'd be great, if that behavior is going to be stable. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/768#note_107160082 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Oct 8 13:28:49 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 08 Oct 2018 11:28:49 +0000 Subject: [gnutls-devel] GnuTLS | Clarify our supported releases meaning (#588) References: Message-ID: New Issue was created. Issue 588: https://gitlab.com/gnutls/gnutls/issues/588 Author: Nikos Mavrogiannopoulos Assignee: In [gnutls download page](https://www.gnutls.org/download.html) we have three active releases, the "previous stable", "stable", and "next". It is implied that there is an active release per ABI version except for older than 3.3.x releases. It is unclear however, how long these releases will be supported and whether it is fine to switch from 3.5.x to 3.6.x when the latter becomes stable. We should try to simplify and clarify that message, and maybe introduce LTS releases which are supported for longer time. That would require in practice a sponsor/maintainer taking that commitment. Thoughts? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/588 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Oct 8 14:51:45 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 08 Oct 2018 12:51:45 +0000 Subject: [gnutls-devel] GnuTLS | Skip tests/tls13/prf.c if visibility 'protected' doesn't work (!770) In-Reply-To: References: Message-ID: :lgtm: Should we make a build that uses the ld flags that fail now? (e.g., the Debian.x86_64 build?). -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/770#note_107205180 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Oct 8 15:04:21 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 08 Oct 2018 13:04:21 +0000 Subject: [gnutls-devel] GnuTLS | Provide a configuration file (#587) In-Reply-To: References: Message-ID: What is the intention, is to allow an operating system to say something like this: "by default applications should not be able to negotiate ssl3.0". The problem comes from the fact that very few applications use `gnutls_set_default_priority()` because for example they needed to add a parameter (e.g., enable PSK ciphersuites with `+PSK`, or enable compatibility mode with `%COMPAT`. In gnutls 3.6.3 `gnutls_set_default_priority_append()` was added to address that thing, but I'm pretty sure it is going to take years for applications to switch. As such any system wide enforcement of settings will be restricted to some applications only. The options are: 1. Discourage applications from setting their own priority string and move them to use `gnutls_set_default_priority_append()` or `gnutls_set_default_priority()`; the question is how to do that? 2. The "Set global TLS options which no application could override; this should include" above -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/587#note_107211054 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Oct 8 15:20:11 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 08 Oct 2018 13:20:11 +0000 Subject: [gnutls-devel] GnuTLS | Skip tests/tls13/prf.c if visibility 'protected' doesn't work (!770) In-Reply-To: References: Message-ID: AFAICS, we don't lose anything, so I amended the Debian.x86_64 runner. The question still is why does this happen on Debian/Ubuntu but not on Fedora ? `ld` links here to `/usr/bin/x86_64-linux-gnu-ld.bfd`. Maybe on Fedora the `gold` linker is used ? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/770#note_107217848 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Oct 8 15:22:41 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 08 Oct 2018 13:22:41 +0000 Subject: [gnutls-devel] GnuTLS | Skip tests/tls13/prf.c if visibility 'protected' doesn't work (!770) In-Reply-To: References: Message-ID: Also, `tests/rng-no-onload.c` should be reviewed... uses the same 'protected' visibility on gnutls_rnd(). -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/770#note_107218449 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Oct 8 20:35:13 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 08 Oct 2018 18:35:13 +0000 Subject: [gnutls-devel] GnuTLS | tests: ensure that tests which override library functions run (#589) References: Message-ID: New Issue was created. Issue 589: https://gitlab.com/gnutls/gnutls/issues/589 Author: Nikos Mavrogiannopoulos Assignee: The following tests: * `tests/rng-no-onload.c` * `tests/tls13/prf.c` rely on replacing gnutls function calls; something that works on ELF systems, but may not be available if certain flags are provided to the linker (see #584). We should make sure that these tests are run in at least one CI run, and any incidental disabling of them (e.g., compiler/linker defaults changing) will be detected. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/589 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Oct 8 20:35:41 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 08 Oct 2018 18:35:41 +0000 Subject: [gnutls-devel] GnuTLS | Skip tests/tls13/prf.c if visibility 'protected' doesn't work (!770) In-Reply-To: References: Message-ID: Hmmm, indeed. However it fails safe. It checks whether no calls to `gnutls_rnd()` are made during startup. On a scenario like this it will report success because the override didn't work. The dangerous part in these two tests is that they may end-up being skipped or report success accidentally and no-one would notice. I've opened #589 for it. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/770#note_107300454 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Oct 8 20:35:50 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 08 Oct 2018 18:35:50 +0000 Subject: [gnutls-devel] GnuTLS | Skip tests/tls13/prf.c if visibility 'protected' doesn't work (!770) In-Reply-To: References: Message-ID: Merge Request !770 was approved by Nikos Mavrogiannopoulos Merge Request url: https://gitlab.com/gnutls/gnutls/merge_requests/770 Branches: tmp-fix-584 to master Author: Tim R?hsen Assignee: -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/770 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Oct 8 20:35:53 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 08 Oct 2018 18:35:53 +0000 Subject: [gnutls-devel] GnuTLS | Skip tests/tls13/prf.c if visibility 'protected' doesn't work (!770) In-Reply-To: References: Message-ID: Merge Request !770 was merged Merge Request url: https://gitlab.com/gnutls/gnutls/merge_requests/770 Branches: tmp-fix-584 to master Author: Tim R?hsen Assignee: -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/770 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Oct 8 20:35:53 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 08 Oct 2018 18:35:53 +0000 Subject: [gnutls-devel] GnuTLS | tls13/prf fails with hardening LDFLAGS (#584) In-Reply-To: References: Message-ID: Issue was closed by Nikos Mavrogiannopoulos Issue #584: https://gitlab.com/gnutls/gnutls/issues/584 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/584 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Oct 8 20:36:35 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 08 Oct 2018 18:36:35 +0000 Subject: [gnutls-devel] GnuTLS | Let bootstrap check for gperf, makeinfo, rsync, autopoint (!769) In-Reply-To: References: Message-ID: Merge Request !769 was approved by Nikos Mavrogiannopoulos Merge Request url: https://gitlab.com/gnutls/gnutls/merge_requests/769 Branches: tmp-check-prereqs to master Author: Tim R?hsen Assignee: -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/769 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Oct 8 20:36:43 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 08 Oct 2018 18:36:43 +0000 Subject: [gnutls-devel] GnuTLS | Configure does not chek if gperf is installed (#582) In-Reply-To: References: Message-ID: Issue was closed by Nikos Mavrogiannopoulos Issue #582: https://gitlab.com/gnutls/gnutls/issues/582 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/582 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Oct 8 20:36:43 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 08 Oct 2018 18:36:43 +0000 Subject: [gnutls-devel] GnuTLS | Let bootstrap check for gperf, makeinfo, rsync, autopoint (!769) In-Reply-To: References: Message-ID: Merge Request !769 was merged Merge Request url: https://gitlab.com/gnutls/gnutls/merge_requests/769 Branches: tmp-check-prereqs to master Author: Tim R?hsen Assignee: -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/769 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Oct 8 20:37:05 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 08 Oct 2018 18:37:05 +0000 Subject: [gnutls-devel] GnuTLS | Let bootstrap check for gperf, makeinfo, rsync, autopoint (!769) In-Reply-To: References: Message-ID: Thank you! -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/769#note_107300670 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Oct 8 20:49:04 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 08 Oct 2018 18:49:04 +0000 Subject: [gnutls-devel] GnuTLS | Skip tests/tls13/prf.c if visibility 'protected' doesn't work (!770) In-Reply-To: References: Message-ID: > The question still is why does this happen on Debian/Ubuntu but not on Fedora ? `ld` links here to `/usr/bin/x86_64-linux-gnu-ld.bfd`. Maybe on Fedora the `gold` linker is used ? I was actually wrong. In redhat-rpm-config there is no `-Bsymbolic-functions`, which as I understand this caused the issue. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/770#note_107302150 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Oct 9 12:38:55 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 09 Oct 2018 10:38:55 +0000 Subject: [gnutls-devel] GnuTLS | Fix gen-mech-list.sh on Solaris / Bourne Shell (!771) References: Message-ID: New Merge Request !771 https://gitlab.com/gnutls/gnutls/merge_requests/771 Branches: tmp-fix-gen-mech-list-on-solaris to master Author: Tim R?hsen Assignee: Approvers: Simon Josefsson, Nikos Mavrogiannopoulos, Dmitry Eremin-Solenikov, Hubert Kario, Andreas Metzler, Daiki Ueno, Tom, Ander Juaristi, Tom?? Mr?z, Anderson Sasaki and GnuTLS devel mailing list `cmd` is more compatible than $(cmd). The shell is "sh (Schily Bourne Shell) version 2013/01/14 a+ (i386-pc-solaris2.9)" ## Checklist * [*] Code modified for feature ## Reviewer's checklist: * [ ] Any issues marked for closing are addressed * [ ] There is a test suite reasonably covering new functionality or modifications * [ ] Function naming, parameters, return values, types, etc., are consistent and according to `CONTRIBUTION.md` * [ ] This feature/change has adequate documentation added * [ ] No obvious mistakes in the code -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/771 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Oct 9 12:48:41 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 09 Oct 2018 10:48:41 +0000 Subject: [gnutls-devel] GnuTLS | Fix check for GNU C compiler in eina_cpu.c (!772) References: Message-ID: New Merge Request !772 https://gitlab.com/gnutls/gnutls/merge_requests/772 Branches: tmp-fix-eina-cpu-on-solaris to master Author: Tim R?hsen Assignee: Approvers: Simon Josefsson, Nikos Mavrogiannopoulos, Dmitry Eremin-Solenikov, Hubert Kario, Andreas Metzler, Daiki Ueno, Tom, Ander Juaristi, Tom?? Mr?z, Anderson Sasaki and GnuTLS devel mailing list On the OpenCSW Solaris platform, the test for the GNU C compiler fails. IMO, the test should be __GNUC__ instead of __GNU__. ## Checklist * [*] Code modified for feature ## Reviewer's checklist: * [ ] Any issues marked for closing are addressed * [ ] There is a test suite reasonably covering new functionality or modifications * [ ] Function naming, parameters, return values, types, etc., are consistent and according to `CONTRIBUTION.md` * [ ] This feature/change has adequate documentation added * [ ] No obvious mistakes in the code -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/772 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Oct 9 13:23:40 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 09 Oct 2018 11:23:40 +0000 Subject: [gnutls-devel] GnuTLS | Fix linking of libecore.a on Solaris (!773) References: Message-ID: New Merge Request !773 https://gitlab.com/gnutls/gnutls/merge_requests/773 Branches: fix-makefile-on-solaris to master Author: Tim R?hsen Assignee: Approvers: Simon Josefsson, Nikos Mavrogiannopoulos, Dmitry Eremin-Solenikov, Hubert Kario, Andreas Metzler, Daiki Ueno, Tom, Ander Juaristi, Tom?? Mr?z, Anderson Sasaki and GnuTLS devel mailing list Add $(LTLIBICONV) $(LTLIBINTL) to LDADD in tests/suite/Makefile.am to allow linking on Solaris. ## Checklist * [ ] Code modified for feature * [ ] Test suite updated with functionality tests * [ ] Test suite updated with negative tests * [ ] Documentation updated ## Reviewer's checklist: * [ ] Any issues marked for closing are addressed * [ ] There is a test suite reasonably covering new functionality or modifications * [ ] Function naming, parameters, return values, types, etc., are consistent and according to `CONTRIBUTION.md` * [ ] This feature/change has adequate documentation added * [ ] No obvious mistakes in the code -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/773 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Oct 9 14:27:32 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 09 Oct 2018 12:27:32 +0000 Subject: [gnutls-devel] GnuTLS | Fix gen-mech-list.sh on Solaris / Bourne Shell (!771) In-Reply-To: References: Message-ID: Is that the only script affected? The `$()` way is the posix way and used quite consistently in the test suite (at least in the newer tests). Do we need to support this platform with that shell or should we require bash for testing? In freebsd we do that already as several scripts fail to run. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/771#note_107460817 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Oct 9 15:21:24 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 09 Oct 2018 13:21:24 +0000 Subject: [gnutls-devel] GnuTLS | Fix gen-mech-list.sh on Solaris / Bourne Shell (!771) In-Reply-To: References: Message-ID: It the only script affected for ``` ./configure --enable-shared --with-included-libtasn1 --without-p11-kit --disable-guile make ``` I didn't try a 'make check' yet. The configure script falls back to bash or zsh when detecting a non-POSIX shell, but gen-mech-list.sh doesn't. It uses /bin/sh which I can't link to any other shell due to missing admin rights. Of course I can use bash for all manually executed scripts (e.g. as in `bash ./bootstrap`), but not for automated scripting. At least not without some hacks. While \`cmd\` works on non-POSIX *and* POSIX shells, $(cmd) is POSIX-only as you said. I personally like the compatible form, but that's a matter of taste, I guess. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/771#note_107476070 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Oct 9 15:50:48 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 09 Oct 2018 13:50:48 +0000 Subject: [gnutls-devel] GnuTLS | Fix gen-mech-list.sh on Solaris / Bourne Shell (!771) In-Reply-To: References: Message-ID: Merge Request !771 was approved by Nikos Mavrogiannopoulos Merge Request url: https://gitlab.com/gnutls/gnutls/merge_requests/771 Branches: tmp-fix-gen-mech-list-on-solaris to master Author: Tim R?hsen Assignee: -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/771 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Oct 9 15:51:47 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 09 Oct 2018 13:51:47 +0000 Subject: [gnutls-devel] GnuTLS | Fix gen-mech-list.sh on Solaris / Bourne Shell (!771) In-Reply-To: References: Message-ID: Ok, if that's the only thing needed to make it run on that system, it is fine with me. Without a CI including solaris however, we may not be able to keep it running. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/771#note_107488346 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Oct 9 15:52:02 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 09 Oct 2018 13:52:02 +0000 Subject: [gnutls-devel] GnuTLS | Fix gen-mech-list.sh on Solaris / Bourne Shell (!771) In-Reply-To: References: Message-ID: Reassigned Merge Request 771 https://gitlab.com/gnutls/gnutls/merge_requests/771 Assignee changed to Tim R?hsen -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/771 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Oct 9 16:10:24 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 09 Oct 2018 14:10:24 +0000 Subject: [gnutls-devel] GnuTLS | Fix gen-mech-list.sh on Solaris / Bourne Shell (!771) In-Reply-To: References: Message-ID: Merge Request !771 was merged Merge Request url: https://gitlab.com/gnutls/gnutls/merge_requests/771 Branches: tmp-fix-gen-mech-list-on-solaris to master Author: Tim R?hsen Assignee: Tim R?hsen -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/771 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Oct 9 16:18:15 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 09 Oct 2018 14:18:15 +0000 Subject: [gnutls-devel] GnuTLS | Fix gen-mech-list.sh on Solaris / Bourne Shell (!771) In-Reply-To: References: Message-ID: The change is nothing Solaris specific, but yeah, a Solaris CI would be great. Maybe a user crontab entry, so we could build GnuTLS daily or weekly. Just successfully sent an email from there, so we can use that for status reports and/or artifacts. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/771#note_107500552 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Oct 9 19:08:51 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 09 Oct 2018 17:08:51 +0000 Subject: [gnutls-devel] GnuTLS | Update docs for session ticket key rotation (!768) In-Reply-To: References: Message-ID: Reassigned Merge Request 768 https://gitlab.com/gnutls/gnutls/merge_requests/768 Assignee changed to Ander Juaristi -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/768 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Oct 10 06:59:26 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 10 Oct 2018 04:59:26 +0000 Subject: [gnutls-devel] GnuTLS | Fix check for GNU C compiler in eina_cpu.c (!772) In-Reply-To: References: Message-ID: Merge Request !772 was approved by Nikos Mavrogiannopoulos Merge Request url: https://gitlab.com/gnutls/gnutls/merge_requests/772 Branches: tmp-fix-eina-cpu-on-solaris to master Author: Tim R?hsen Assignee: -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/772 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Oct 10 06:59:29 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 10 Oct 2018 04:59:29 +0000 Subject: [gnutls-devel] GnuTLS | Fix check for GNU C compiler in eina_cpu.c (!772) In-Reply-To: References: Message-ID: Merge Request !772 was merged Merge Request url: https://gitlab.com/gnutls/gnutls/merge_requests/772 Branches: tmp-fix-eina-cpu-on-solaris to master Author: Tim R?hsen Assignee: -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/772 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Oct 10 07:04:12 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 10 Oct 2018 05:04:12 +0000 Subject: [gnutls-devel] GnuTLS | Fix linking of libecore.a on Solaris (!773) In-Reply-To: References: Message-ID: I do not think we should re-introduce the gnulib iconv module. Apart from the fact that the library doesn't depend on iconv, it caused problems in windows in the past by preventing the native code being used. An alternative could be to disable that test in solaris. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/773#note_107632835 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Oct 10 10:03:53 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 10 Oct 2018 08:03:53 +0000 Subject: [gnutls-devel] GnuTLS | Fix linking of libecore.a on Solaris (!773) In-Reply-To: References: Message-ID: *If* the iconv module still has an issue with Windows, then I would see details and fix it on the gnulib side. But I doubt it, we use the iconv module at wget, wget2, libidn, libidn2 and have no issues on Windows. Besides that, if the iconv functions are provided by any library (normally libc or -liconv), then no extra code will be put into libgnu.a. If you find a case where this doesn't work as expected, let me know the details or give me a reproducer and I'll try to fix that (preferred at gnulib level). If needed I can access a bare metal Win10 system and would be allowed to install a dev system on it. I really believe that it's wiser to have the iconv module than to live without it. E.g. on MacOS / OSX you'll likely experience issues without it. The alternative, of course, is to enable that test *only* on defined systems like (a recent enough) Linux, FreeBSD. So only on systems we regularly test. Another (general) point would be to have an AppVeyor CI for testing on Windows. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/773#note_107669287 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Oct 10 19:31:23 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 10 Oct 2018 17:31:23 +0000 Subject: [gnutls-devel] GnuTLS | Fix linking of libecore.a on Solaris (!773) In-Reply-To: References: Message-ID: The issue was that it was overriding the native windows code. That may not be the case any more, but I'm not sure what is the issue there and I would like to avoid bringing modules which we do not know why they are pulled. We do not use iconv in the library or in the tests. If there is an issue in libecore.a and requires iconv for some reason on solaris we should try to fix that. (btw. on MacOSX we don't have that issue and the testsuite compiles as expected) -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/773#note_107843483 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Oct 10 19:32:49 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 10 Oct 2018 17:32:49 +0000 Subject: [gnutls-devel] GnuTLS | Fix linking of libecore.a on Solaris (!773) In-Reply-To: References: Message-ID: The appveyor CI would certainly be nice. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/773#note_107843688 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Thu Oct 11 17:40:07 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 11 Oct 2018 15:40:07 +0000 Subject: [gnutls-devel] GnuTLS | Update docs for session ticket key rotation (!768) In-Reply-To: References: Message-ID: Ander Juaristi commented on a discussion on doc/cha-gtls-app.texi: > A server supporting session tickets must generate ticket encryption > and authentication keys using @funcref{gnutls_session_ticket_key_generate}. > Those keys should be associated with the GnuTLS session using > - at funcref{gnutls_session_ticket_enable_server}, and should be rotated regularly > -(e.g., every few hours), to prevent them from becoming long-term keys which > -if revealed could be used to decrypt all previous sessions. > + at funcref{gnutls_session_ticket_enable_server}. > + > +GnuTLS will rotate these keys regularly. The key rotation interval can be specified with > + at funcref{gnutls_db_set_cache_expiration}. Every such interval, new keys will be generated from the initial keys > +that were first established using @funcref{gnutls_session_ticket_enable_server}. This is I've rephrased it. I think it's clearer now. ``` A server supporting session tickets must generate ticket encryption and authentication keys using @funcref{gnutls_session_ticket_key_generate}. Those keys should be associated with the GnuTLS session using @funcref{gnutls_session_ticket_enable_server}. Those will be the initial keys, but GnuTLS will rotate them regularly. The key rotation interval can be specified with @funcref{gnutls_db_set_cache_expiration}. Every such interval, new keys will be generated from those initial keys. This is a necessary mechanism to prevent the keys from becoming long-term keys and as such preserve forward-secrecy in the issued session tickets. If no explicit key rotation interval is provided, GnuTLS will rotate them every 18 hours by default. ``` -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/768#note_108145999 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Thu Oct 11 17:45:13 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 11 Oct 2018 15:45:13 +0000 Subject: [gnutls-devel] GnuTLS | Update docs for session ticket key rotation (!768) In-Reply-To: References: Message-ID: Ander Juaristi commented on a discussion on doc/cha-gtls-app.texi: > A server supporting session tickets must generate ticket encryption > and authentication keys using @funcref{gnutls_session_ticket_key_generate}. > Those keys should be associated with the GnuTLS session using > - at funcref{gnutls_session_ticket_enable_server}, and should be rotated regularly > -(e.g., every few hours), to prevent them from becoming long-term keys which > -if revealed could be used to decrypt all previous sessions. > + at funcref{gnutls_session_ticket_enable_server}. > + > +GnuTLS will rotate these keys regularly. The key rotation interval can be specified with > + at funcref{gnutls_db_set_cache_expiration}. Every such interval, new keys will be generated from the initial keys > +that were first established using @funcref{gnutls_session_ticket_enable_server}. This is Forget the previous message. This should be the good one. ``` Those will be the initial keys, but GnuTLS will rotate them regularly. The key rotation interval can be changed with @funcref{gnutls_db_set_cache_expiration}. The key rotation interval will be three times the ticket expiration time (ie. three times the value given in that function). Every such interval, new keys will be generated from those initial keys. This is a necessary mechanism to prevent the keys from becoming long-term keys and as such preserve forward-secrecy in the issued session tickets. If no explicit key rotation interval is provided, GnuTLS will rotate them every 18 hours by default. ``` -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/768#note_108147312 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Thu Oct 11 21:31:56 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 11 Oct 2018 19:31:56 +0000 Subject: [gnutls-devel] GnuTLS | Update docs for session ticket key rotation (!768) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos commented on a discussion on doc/cha-gtls-app.texi: > A server supporting session tickets must generate ticket encryption > and authentication keys using @funcref{gnutls_session_ticket_key_generate}. > Those keys should be associated with the GnuTLS session using > - at funcref{gnutls_session_ticket_enable_server}, and should be rotated regularly > -(e.g., every few hours), to prevent them from becoming long-term keys which > -if revealed could be used to decrypt all previous sessions. > + at funcref{gnutls_session_ticket_enable_server}. > + > +GnuTLS will rotate these keys regularly. The key rotation interval can be specified with > + at funcref{gnutls_db_set_cache_expiration}. Every such interval, new keys will be generated from the initial keys > +that were first established using @funcref{gnutls_session_ticket_enable_server}. This is LGTM. I'd avoid saying twice the `The key rotation interval` in the 2nd and third sentence, and connect them instead. E.g ``` The key rotation interval can be changed with @funcref{gnutls_db_set_cache_expiration} and will be three times the ticket expiration time (ie. three times the value given in that function). ``` -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/768#note_108195271 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Thu Oct 11 21:38:00 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 11 Oct 2018 19:38:00 +0000 Subject: [gnutls-devel] GnuTLS | Update docs for session ticket key rotation (!768) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos started a new discussion on doc/cha-gtls-app.texi: > Those keys should be associated with the GnuTLS session using > - at funcref{gnutls_session_ticket_enable_server}, and should be rotated regularly > -(e.g., every few hours), to prevent them from becoming long-term keys which > -if revealed could be used to decrypt all previous sessions. > + at funcref{gnutls_session_ticket_enable_server}. > + > +Those will be the initial keys, but GnuTLS will rotate them regularly. The key rotation interval > +can be changed with @funcref{gnutls_db_set_cache_expiration}. The key rotation interval will be > +three times the ticket expiration time (ie. three times the value given in that function). > +Every such interval, new keys will be generated from those initial keys. This is a necessary mechanism > +to prevent the keys from becoming long-term keys > +and as such preserve forward-secrecy in the issued session tickets. If no explicit key rotation interval > +is provided, GnuTLS will rotate them every 18 hours by default. > + > +The master key can be shared between processes or between systems. Processes which share the same master key > +will generate the same rotated subkeys, assuming they share the same time. Maybe a clarification here: ``` assuming they share the same time (irrespective of timezone differences). ``` To underline that the generated keys do not depend on timezones and thus you can use the same key in differently located servers. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/768#note_108196466 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Thu Oct 11 21:43:59 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 11 Oct 2018 19:43:59 +0000 Subject: [gnutls-devel] GnuTLS | uris: should be tests in a case insensitive way (#590) References: Message-ID: New Issue was created. Issue 590: https://gitlab.com/gnutls/gnutls/issues/590 Author: Nikos Mavrogiannopoulos Assignee: We provide an API for URIs, but we handled them in a case sensitive way. However URI schemes are case insensitive and we should handled them as such. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/590 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Thu Oct 11 21:49:33 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 11 Oct 2018 19:49:33 +0000 Subject: [gnutls-devel] GnuTLS | uris: should be tests in a case insensitive way (#590) In-Reply-To: References: Message-ID: Reassigned Issue 590 https://gitlab.com/gnutls/gnutls/issues/590 Assignee changed to Nikos Mavrogiannopoulos -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/590 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Oct 12 14:53:53 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 12 Oct 2018 12:53:53 +0000 Subject: [gnutls-devel] GnuTLS | tlsfuzzer: include latest tests (#591) References: Message-ID: New Issue was created. Issue 591: https://gitlab.com/gnutls/gnutls/issues/591 Author: Nikos Mavrogiannopoulos Assignee: We should update to the current master branch and include any new tests that were added, e.g. ``` test-dhe-key-share-random.py test-dhe-no-shared-secret-padding.py test-ecdhe-padded-shared-secret.py test-ecdhe-rsa-key-share-random.py test-serverhello-random.py test-tls13-crfg-curves.py test-tls13-dhe-shared-secret-padding.py test-tls13-ffdhe-sanity.py test-tls13-invalid-ciphers.py test-tls13-keyshare-omitted.py test-tls13-serverhello-random.py test-tls13-unrecognised-groups.py ``` -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/591 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Oct 12 15:40:39 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 12 Oct 2018 13:40:39 +0000 Subject: [gnutls-devel] GnuTLS | uris: should be tests in a case insensitive way (#590) In-Reply-To: References: Message-ID: GnuTLS uses the terms URI and URL when in real only the scheme is meant. Or is there more to it ? If yes, the domain part is also case insensitive. If no, the API and variable names are pretty confusing :-) -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/590#note_108391195 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Oct 12 15:50:56 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 12 Oct 2018 13:50:56 +0000 Subject: [gnutls-devel] GnuTLS | uris schemes: should be tested in a case insensitive way (#590) In-Reply-To: References: Message-ID: You are right :) I've updated the text to refer to URI schemes instead. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/590#note_108396860 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Oct 12 17:15:50 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 12 Oct 2018 15:15:50 +0000 Subject: [gnutls-devel] GnuTLS | tlsfuzzer: include latest tests (#591) In-Reply-To: References: Message-ID: Reassigned Issue 591 https://gitlab.com/gnutls/gnutls/issues/591 Assignee changed to Nikos Mavrogiannopoulos -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/591 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Oct 12 17:17:11 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 12 Oct 2018 15:17:11 +0000 Subject: [gnutls-devel] GnuTLS | WIP: update tlsfuzzer scripts to latest version (!774) References: Message-ID: New Merge Request !774 https://gitlab.com/gnutls/gnutls/merge_requests/774 Branches: tmp-update-tlsfuzzer to master Author: Nikos Mavrogiannopoulos Assignee: Approvers: Simon Josefsson, Dmitry Eremin-Solenikov, Hubert Kario, Tim R?hsen, Andreas Metzler, Daiki Ueno, Tom, Ander Juaristi, Tom?? Mr?z, Anderson Sasaki and GnuTLS devel mailing list This updates the tlsfuzzer scripts to latest version. ## Checklist * [ ] Code modified for feature * [ ] Test suite updated with functionality tests * [ ] Test suite updated with negative tests * [ ] Documentation updated ## Reviewer's checklist: * [ ] Any issues marked for closing are addressed * [ ] There is a test suite reasonably covering new functionality or modifications * [ ] Function naming, parameters, return values, types, etc., are consistent and according to `CONTRIBUTION.md` * [ ] This feature/change has adequate documentation added * [ ] No obvious mistakes in the code -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/774 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Sat Oct 13 13:04:14 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sat, 13 Oct 2018 11:04:14 +0000 Subject: [gnutls-devel] GnuTLS | Clarify or improve our supported releases meaning (#588) In-Reply-To: References: Message-ID: @ametzler any thoughts on that? The situation we have now is that at any ABI breakage the previous release (e.g., 2.12.x, 3.3.x) became a de-facto LTS release as distributions like debian/rhel rely on it cannot move forward. So first question is, would you as debian maintainer be interested in a collaborative maintainership of a similar LTS branch in the future? Ie. bring the debian patches if any and thus also have a say on what other patches go in and on how long would that be open? (and such offer would be open to other distributions) Would that make sense from your perspective? The second (related) question is that if we keep ABI fixed to the one in 3.4.x, would it make sense to create a similar LTS release in the future after 3.3.x is considered out of support? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/588#note_108522993 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Sat Oct 13 19:38:20 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sat, 13 Oct 2018 17:38:20 +0000 Subject: [gnutls-devel] GnuTLS | Something wrong with CI? (#592) References: Message-ID: New Issue was created. Issue 592: https://gitlab.com/gnutls/gnutls/issues/592 Author: Tom Assignee: I think there might be something wrong with the CI environment. After committing some work I found that the `global-init-override` test is failing (see https://gitlab.com/Vrancken/gnutls-kdh/-/jobs/107279631). While debugging on a local docker image I found that the current master is also failing the same test. After inspecting the Gitlab pipeline that "passes" the latest master I found that one of the images is not running tests but passes anyway (see https://gitlab.com/gnutls/gnutls/-/jobs/106443058). This is occurring on the Debian_x86_64 image. Is this expected behaviour? Is the CI updated? Or is something wrong here? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/592 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Sat Oct 13 19:47:30 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sat, 13 Oct 2018 17:47:30 +0000 Subject: [gnutls-devel] GnuTLS | Something wrong with CI? (#592) In-Reply-To: References: Message-ID: Yes, a change being introduced by commit 7095d5577ff25bb41ca3171903ac03809cea9f35. The CI should error, but simply continues. Thanks for reporting. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/592#note_108549537 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Sat Oct 13 20:12:46 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sat, 13 Oct 2018 18:12:46 +0000 Subject: [gnutls-devel] GnuTLS | Something wrong with CI? (#592) In-Reply-To: References: Message-ID: @nmav Same code sequence locally (here: Debian unstable) set $? to 1 while in the Debian.x86_64 CI the return status is 0. And thus the CI continues on error and exits with 'success'. It could be a bash/dash bug that meanwhile is fixed. A fast work-around would be to reset/update the CI cache... -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/592#note_108550820 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Sun Oct 14 15:59:26 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sun, 14 Oct 2018 13:59:26 +0000 Subject: [gnutls-devel] GnuTLS | WIP: RFC7250 Raw public keys (!650) In-Reply-To: References: Message-ID: Tom commented on a discussion on lib/includes/gnutls/gnutls.h.in: > unsigned idx, > gnutls_datum_t * response); > > +/* RAW public key functions (RFC7250) */ > +#ifdef ENABLE_RAWPK > +int gnutls_certificate_set_rawpk_keypair(gnutls_certificate_credentials_t cred, I've been thinking about this and I think you are right. We can use `gnutls_certificate_set_key` for both x509 and rawpk. The names can be useful for vhosts. I will therefore remove my `gnutls_certificate_set_rawpk_key` function. However, I would like to propose some improvements on `gnutls_certificate_set_key`. Furthermore, I would suggest to relocate it to `cert-cred.c` instead of `cert-cred-x509.c` because the function does not apply to x509 alone anymore. What do you think? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/650#note_108597215 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Sun Oct 14 17:13:09 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sun, 14 Oct 2018 15:13:09 +0000 Subject: [gnutls-devel] GnuTLS | WIP: RFC7250 Raw public keys (!650) In-Reply-To: References: Message-ID: Tom commented on a discussion on doc/cha-gtls-app.texi: > (i.e. different for the client than for the server). > > Currently supported types are: > -CTYPE-X509 or CTYPE-X.509. Catch all is CTYPE-ALL. > +CTYPE-X509 or CTYPE-X.509, CTYPE-RAWPK or CTYPE-RAWPUBKEY. Catch all is CTYPE-ALL. I've been thinking about this and come to the following conclusion. First of all, > However, about certificate types, I cannot really write code which will work with any certificate type available, Yes you can. We do it in our TLS Pool project (https://github.com/arpa2/tlspool). Secondly, I understand your concern about giving users the power to enable features that the application was not developed for. With that in mind we can introduce a flag to be able to enable/disable rawpk functionality via an init flag. On the other hand, I don't see how a user can mess things up by setting certificate priorities? The system will only use credential types that are actually available and an application developer should check what type it receives and act accordingly. Do you have a specific scenario in mind which will break? Whether we use an init flag or not, we still need certificate type priorities. Imagine for example that a user enables an RSA key exchange. We then have two possibilities to transmit the key material; 1) via a regular x509 certificate, 2) as raw public-key. We must be able to distinguish between these certificate types and negotiate which one we are going to use (via our cert type negotiation extensions). Therefore we must also be able to set our priority preferences. Do you agree? In the end I think we should make a decision about whether or not to use an extra init flag. If we do, I need to figure out how to incorporate it into the code. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/650#note_108603214 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Oct 15 13:44:06 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 15 Oct 2018 11:44:06 +0000 Subject: [gnutls-devel] GnuTLS | WIP: add support for 0-RTT (!775) References: Message-ID: New Merge Request !775 https://gitlab.com/gnutls/gnutls/merge_requests/775 Branches: tmp-0rtt to master Author: Daiki Ueno Assignee: Approvers: Simon Josefsson, Nikos Mavrogiannopoulos, Dmitry Eremin-Solenikov, Hubert Kario, Tim R?hsen, Andreas Metzler, Tom, Ander Juaristi, Tom?? Mr?z, Anderson Sasaki and GnuTLS devel mailing list This is an initial attempt to implement 0-RTT mode. Note that it is not secure enough, because there is no anti-replay measure. I guess one way to implement it would be to make session ticket single use, by recording the identifier of the tickets in the database. ## Checklist * [x] Code modified for feature * [x] Test suite updated with functionality tests * [x] Test suite updated with negative tests * [x] Documentation updated ## Reviewer's checklist: * [ ] Any issues marked for closing are addressed * [ ] There is a test suite reasonably covering new functionality or modifications * [ ] Function naming, parameters, return values, types, etc., are consistent and according to `CONTRIBUTION.md` * [ ] This feature/change has adequate documentation added * [ ] No obvious mistakes in the code -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/775 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Oct 15 16:04:18 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 15 Oct 2018 14:04:18 +0000 Subject: [gnutls-devel] GnuTLS | p11tool: fix admin user PIN initialization (!776) References: Message-ID: New Merge Request !776 https://gitlab.com/gnutls/gnutls/merge_requests/776 Branches: tmp-initialize-so-pin-fix to master Author: Nikos Mavrogiannopoulos Assignee: Approvers: Simon Josefsson, Dmitry Eremin-Solenikov, Hubert Kario, Tim R?hsen, Andreas Metzler, Daiki Ueno, Tom, Ander Juaristi, Tom?? Mr?z, Anderson Sasaki and GnuTLS devel mailing list Previously we would call gnutls_pkcs11_token_set_pin() without an old PIN provided, which will result to the use of C_InitPIN() on the underlying module. The C_InitPIN() in contrast with C_SetPIN() will only work for the user and not for the administrator. As such, we always provide the oldpin for when we change the admin's PIN. ## Checklist * [x] Code modified for feature * [ ] Test suite updated with functionality tests * [ ] Test suite updated with negative tests * [ ] Documentation updated ## Reviewer's checklist: * [ ] Any issues marked for closing are addressed * [ ] There is a test suite reasonably covering new functionality or modifications * [ ] Function naming, parameters, return values, types, etc., are consistent and according to `CONTRIBUTION.md` * [ ] This feature/change has adequate documentation added * [ ] No obvious mistakes in the code -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/776 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Oct 15 16:04:27 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 15 Oct 2018 14:04:27 +0000 Subject: [gnutls-devel] GnuTLS | p11tool --initialize-so-pin does not change so pin but initializes user pin (#561) In-Reply-To: References: Message-ID: Reassigned Issue 561 https://gitlab.com/gnutls/gnutls/issues/561 Assignee changed to Nikos Mavrogiannopoulos -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/561 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Oct 15 16:26:13 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 15 Oct 2018 14:26:13 +0000 Subject: [gnutls-devel] GnuTLS | gnutls_init: added flag for automatic re-authentication (!766) In-Reply-To: References: Message-ID: Daiki Ueno started a new discussion on lib/auth/cert.c: > * use it and leave. We make sure that this is called once. > */ > if (cred->get_cert_callback3) { > - > if (session->internals.selected_cert_list_length == 0) { > ret = call_get_cert_callback(session, NULL, 0, NULL, 0); > if (ret < 0) > return gnutls_assert_val(ret); > > + if (session->internals.selected_cert_list_length == 0) > + return gnutls_assert_val(GNUTLS_E_INSUFFICIENT_CREDENTIALS); > + r+, except that the commit message has a typo in the first line (s/an/and/). -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/766#note_108862114 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Oct 15 16:27:33 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 15 Oct 2018 14:27:33 +0000 Subject: [gnutls-devel] GnuTLS | gnutls_init: added flag for automatic re-authentication (!766) In-Reply-To: References: Message-ID: Daiki Ueno started a new discussion on tests/tls12-rehandshake-cert-auto.c: > + > + close(fd); > + gnutls_deinit(session); > + > + gnutls_anon_free_server_credentials(anoncred); > + gnutls_certificate_free_credentials(x509_cred); > + > + gnutls_global_deinit(); > + > + if (debug) > + success("server: finished\n"); > +} > + > +static void ch_handler(int sig) > +{ > + return; nit: can't it be SIG_IGN? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/766#note_108862528 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Oct 15 16:32:39 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 15 Oct 2018 14:32:39 +0000 Subject: [gnutls-devel] GnuTLS | gnutls_init: added flag for automatic re-authentication (!766) In-Reply-To: References: Message-ID: Daiki Ueno started a new discussion on lib/handshake-tls13.c: > > /* Application is expected to handle re-authentication > * explicitly. */ I would suggest to move this comment to the `else` branch. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/766#note_108863917 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Oct 15 16:40:11 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 15 Oct 2018 14:40:11 +0000 Subject: [gnutls-devel] GnuTLS | gnutls_init: added flag for automatic re-authentication (!766) In-Reply-To: References: Message-ID: Other than the nits, this looks good to me. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/766#note_108866330 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Oct 15 16:40:17 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 15 Oct 2018 14:40:17 +0000 Subject: [gnutls-devel] GnuTLS | gnutls_init: added flag for automatic re-authentication (!766) In-Reply-To: References: Message-ID: Merge Request !766 was approved by Daiki Ueno Merge Request url: https://gitlab.com/gnutls/gnutls/merge_requests/766 Branches: tmp-auto-reauth to master Author: Nikos Mavrogiannopoulos Assignee: -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/766 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Oct 15 21:10:58 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 15 Oct 2018 19:10:58 +0000 Subject: [gnutls-devel] GnuTLS | gnutls_init: added flag for automatic re-authentication (!766) In-Reply-To: References: Message-ID: Tom started a new discussion on lib/handshake.c: > return 0; > } > > -int > -_gnutls_recv_hello_request(gnutls_session_t session, void *data, Why are you removing this function? I am relying on it in some of my work. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/766#note_108935725 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Oct 16 09:01:45 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 16 Oct 2018 07:01:45 +0000 Subject: [gnutls-devel] GnuTLS | gnutls_init: added flag for automatic re-authentication (!766) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos commented on a discussion on tests/tls12-rehandshake-cert-auto.c: > + > + close(fd); > + gnutls_deinit(session); > + > + gnutls_anon_free_server_credentials(anoncred); > + gnutls_certificate_free_credentials(x509_cred); > + > + gnutls_global_deinit(); > + > + if (debug) > + success("server: finished\n"); > +} > + > +static void ch_handler(int sig) > +{ > + return; Indeed. I don't know why I handled it like that. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/766#note_109025438 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Oct 16 09:02:41 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 16 Oct 2018 07:02:41 +0000 Subject: [gnutls-devel] GnuTLS | gnutls_init: added flag for automatic re-authentication (!766) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos commented on a discussion on lib/handshake-tls13.c: > > /* Application is expected to handle re-authentication > * explicitly. */ Right, thanks. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/766#note_109025606 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Oct 16 09:04:14 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 16 Oct 2018 07:04:14 +0000 Subject: [gnutls-devel] GnuTLS | gnutls_init: added flag for automatic re-authentication (!766) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos commented on a discussion on lib/handshake.c: > return 0; > } > > -int > -_gnutls_recv_hello_request(gnutls_session_t session, void *data, There was no use of it in `handshake.c` so it was made a static and moved to the only caller file in `record.c`. The rationale was that if it was not needed until today, most likely it will never be because that's a tls1.2 feature that got removed from tls1.3. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/766#note_109025872 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Oct 16 09:05:33 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 16 Oct 2018 07:05:33 +0000 Subject: [gnutls-devel] GnuTLS | gnutls_init: added flag for automatic re-authentication (!766) In-Reply-To: References: Message-ID: Reassigned Merge Request 766 https://gitlab.com/gnutls/gnutls/merge_requests/766 Assignee changed to Nikos Mavrogiannopoulos -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/766 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Oct 16 09:05:42 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 16 Oct 2018 07:05:42 +0000 Subject: [gnutls-devel] GnuTLS | gnutls_init: added flag for automatic re-authentication (!766) In-Reply-To: References: Message-ID: All discussions on Merge Request !766 were resolved by Nikos Mavrogiannopoulos https://gitlab.com/gnutls/gnutls/merge_requests/766 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/766 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Oct 16 09:05:42 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 16 Oct 2018 07:05:42 +0000 Subject: [gnutls-devel] GnuTLS | gnutls_init: added flag for automatic re-authentication (!766) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos commented on a discussion on lib/auth/cert.c: > * use it and leave. We make sure that this is called once. > */ > if (cred->get_cert_callback3) { > - > if (session->internals.selected_cert_list_length == 0) { > ret = call_get_cert_callback(session, NULL, 0, NULL, 0); > if (ret < 0) > return gnutls_assert_val(ret); > > + if (session->internals.selected_cert_list_length == 0) > + return gnutls_assert_val(GNUTLS_E_INSUFFICIENT_CREDENTIALS); > + Nice catch. Fixed. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/766#note_109026233 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Oct 16 09:17:27 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 16 Oct 2018 07:17:27 +0000 Subject: [gnutls-devel] GnuTLS | WIP: p11tool: fix admin user PIN initialization (!776) In-Reply-To: References: Message-ID: @p-steuer and @sahilnxp could you verify that this MR addresses the issue #561? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/776#note_109028537 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Oct 16 11:21:13 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 16 Oct 2018 09:21:13 +0000 Subject: [gnutls-devel] GnuTLS | gnutls_init: added flag for automatic re-authentication (!766) In-Reply-To: References: Message-ID: Tom commented on a discussion on lib/handshake.c: > return 0; > } > > -int > -_gnutls_recv_hello_request(gnutls_session_t session, void *data, Within ARPA2 we've drafted a spec for peer-to-peer TLS connection setup. Here we make use of the fact that you can use a hello request message to initiate a handshake. Therefore I use this function in one of the protocol flows. Is this message completely removed in TLS 1.3? That would suck. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/766#note_109077631 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Oct 16 11:30:52 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 16 Oct 2018 09:30:52 +0000 Subject: [gnutls-devel] GnuTLS | update tlsfuzzer scripts to latest version (!774) In-Reply-To: References: Message-ID: Tom started a new discussion on lib/errors.c: > GNUTLS_E_INAPPROPRIATE_FALLBACK), > ERROR_ENTRY(N_("An illegal TLS extension was received."), > GNUTLS_E_RECEIVED_ILLEGAL_EXTENSION), > - ERROR_ENTRY(N_("A TLS fatal alert has been received."), > + ERROR_ENTRY(N_("An illegal TLS extension was received."), I think the error messages do not match the error constants here. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/774#note_109081481 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Oct 16 11:42:18 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 16 Oct 2018 09:42:18 +0000 Subject: [gnutls-devel] GnuTLS | update tlsfuzzer scripts to latest version (!774) In-Reply-To: References: Message-ID: Tom started a new discussion on lib/handshake.c: > - /* if we are resuming then the KX seen doesn't match the original */ > + /* sanity check: > + * we see TLS1.3 negotiated but no key share was sent */ > + if (ver->tls13_sem) { > + if (unlikely(!(session->internals.hsk_flags & HSK_PSK_KE_MODE_PSK) && > + !(session->internals.hsk_flags & HSK_KEY_SHARE_RECEIVED))) { > + return gnutls_assert_val(GNUTLS_E_MISSING_EXTENSION); > + } > + > + /* Under TLS1.3 this returns a KX which matches the negotiated > + * groups from the key shares; if we are resuming then the KX seen > + * here doesn't match the original session. */ > if (session->internals.resumed == RESUME_FALSE) > kx = gnutls_kx_get(session); > + else > + kx = 0; `gnutls_kx_get()` returns a `gnutls_kx_algorithm_t` type. I think it would be more readable to use constants from this type instead of constant literals. In this case `GNUTLS_KX_UNKNOWN` instead of `0`. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/774#note_109084651 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Oct 16 11:46:21 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 16 Oct 2018 09:46:21 +0000 Subject: [gnutls-devel] GnuTLS | update tlsfuzzer scripts to latest version (!774) In-Reply-To: References: Message-ID: Tom started a new discussion on lib/handshake.c: > + /* TLS1.2 or earlier, kx is associated with ciphersuite */ > + kx = session->security_parameters.cs->kx_algorithm; > } > > if (kx) { > session->security_parameters.server_auth_type = _gnutls_map_kx_get_cred(kx, 1); > session->security_parameters.client_auth_type = _gnutls_map_kx_get_cred(kx, 0); > - } else if (session->internals.resumed == RESUME_FALSE) { > - return gnutls_assert_val(GNUTLS_E_INTERNAL_ERROR); > + } else if (unlikely(session->internals.resumed == RESUME_FALSE)) { > + /* Here we can only arrive if something we received > + * prevented the session from completing. */ > + return gnutls_assert_val(GNUTLS_E_ILLEGAL_PARAMETER); > } > > return 0; Why not use `GNUTLS_E_SUCCESS` here as return value? Makes code more readable. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/774#note_109085859 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Oct 16 11:49:43 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 16 Oct 2018 09:49:43 +0000 Subject: [gnutls-devel] GnuTLS | update tlsfuzzer scripts to latest version (!774) In-Reply-To: References: Message-ID: Tom started a new discussion on lib/includes/gnutls/gnutls.h.in: > GNUTLS_A_INAPPROPRIATE_FALLBACK = 86, > GNUTLS_A_USER_CANCELED = 90, > GNUTLS_A_NO_RENEGOTIATION = 100, > + GNUTLS_A_MISSING_EXTENSION = 109, The order in the enumeration does not match the order in the comment header. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/774#note_109087067 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Oct 16 11:58:10 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 16 Oct 2018 09:58:10 +0000 Subject: [gnutls-devel] GnuTLS | update tlsfuzzer scripts to latest version (!774) In-Reply-To: References: Message-ID: This MR addresses more than only the fuzzer. Shouldn't this be two separate MRs? The fuzzing stuff looks okay at first glance. I don't know much about the fuzzing system that we use so somebody else should take a look also. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/774#note_109091576 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Oct 16 12:50:07 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 16 Oct 2018 10:50:07 +0000 Subject: [gnutls-devel] GnuTLS | gnutls_init: added flag for automatic re-authentication (!766) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos commented on a discussion on lib/handshake.c: > return 0; > } > > -int > -_gnutls_recv_hello_request(gnutls_session_t session, void *data, Yes. There is no way to initiate a handshake within an existing session under TLS1.3. It has been replaced by post-handshake authentication, or re-key. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/766#note_109117179 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Oct 16 12:50:20 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 16 Oct 2018 10:50:20 +0000 Subject: [gnutls-devel] GnuTLS | gnutls_init: added flag for automatic re-authentication (!766) In-Reply-To: References: Message-ID: Merge Request !766 was merged Merge Request url: https://gitlab.com/gnutls/gnutls/merge_requests/766 Branches: tmp-auto-reauth to master Author: Nikos Mavrogiannopoulos Assignee: Nikos Mavrogiannopoulos -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/766 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Oct 16 14:48:51 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 16 Oct 2018 12:48:51 +0000 Subject: [gnutls-devel] GnuTLS | update tlsfuzzer scripts to latest version (!774) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos commented on a discussion on lib/errors.c: > GNUTLS_E_INAPPROPRIATE_FALLBACK), > ERROR_ENTRY(N_("An illegal TLS extension was received."), > GNUTLS_E_RECEIVED_ILLEGAL_EXTENSION), > - ERROR_ENTRY(N_("A TLS fatal alert has been received."), > + ERROR_ENTRY(N_("An illegal TLS extension was received."), Nice catch! -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/774#note_109169718 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Oct 16 14:49:53 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 16 Oct 2018 12:49:53 +0000 Subject: [gnutls-devel] GnuTLS | update tlsfuzzer scripts to latest version (!774) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos commented on a discussion on lib/handshake.c: > - /* if we are resuming then the KX seen doesn't match the original */ > + /* sanity check: > + * we see TLS1.3 negotiated but no key share was sent */ > + if (ver->tls13_sem) { > + if (unlikely(!(session->internals.hsk_flags & HSK_PSK_KE_MODE_PSK) && > + !(session->internals.hsk_flags & HSK_KEY_SHARE_RECEIVED))) { > + return gnutls_assert_val(GNUTLS_E_MISSING_EXTENSION); > + } > + > + /* Under TLS1.3 this returns a KX which matches the negotiated > + * groups from the key shares; if we are resuming then the KX seen > + * here doesn't match the original session. */ > if (session->internals.resumed == RESUME_FALSE) > kx = gnutls_kx_get(session); > + else > + kx = 0; Makes sense; updated. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/774#note_109169986 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Oct 16 14:51:33 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 16 Oct 2018 12:51:33 +0000 Subject: [gnutls-devel] GnuTLS | update tlsfuzzer scripts to latest version (!774) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos commented on a discussion on lib/handshake.c: > + /* TLS1.2 or earlier, kx is associated with ciphersuite */ > + kx = session->security_parameters.cs->kx_algorithm; > } > > if (kx) { > session->security_parameters.server_auth_type = _gnutls_map_kx_get_cred(kx, 1); > session->security_parameters.client_auth_type = _gnutls_map_kx_get_cred(kx, 0); > - } else if (session->internals.resumed == RESUME_FALSE) { > - return gnutls_assert_val(GNUTLS_E_INTERNAL_ERROR); > + } else if (unlikely(session->internals.resumed == RESUME_FALSE)) { > + /* Here we can only arrive if something we received > + * prevented the session from completing. */ > + return gnutls_assert_val(GNUTLS_E_ILLEGAL_PARAMETER); > } > > return 0; Hmmm, it could be. However the `return 0` is a convention followed all over the code in `lib/`. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/774#note_109170478 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Oct 16 14:54:56 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 16 Oct 2018 12:54:56 +0000 Subject: [gnutls-devel] GnuTLS | update tlsfuzzer scripts to latest version (!774) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos commented on a discussion on lib/includes/gnutls/gnutls.h.in: > GNUTLS_A_INAPPROPRIATE_FALLBACK = 86, > GNUTLS_A_USER_CANCELED = 90, > GNUTLS_A_NO_RENEGOTIATION = 100, > + GNUTLS_A_MISSING_EXTENSION = 109, Hmmm, there was quite some mess there in the last ones. Re-ordered. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/774#note_109171507 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Oct 16 15:02:43 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 16 Oct 2018 13:02:43 +0000 Subject: [gnutls-devel] GnuTLS | update tlsfuzzer scripts to latest version (!774) In-Reply-To: References: Message-ID: > This MR addresses more than only the fuzzer. Shouldn't this be two separate MRs? They are dependable as the modification for the error code is needed to make the tlsfuzzer tests pass. > The fuzzing stuff looks okay at first glance. I don't know much about the fuzzing system that we use so somebody else should take a look also. If that helps, the goal is to enable as many tests as possible from that system, while keeping any disabled tests documented (as of why we disable). -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/774#note_109177250 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Oct 17 08:26:39 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 17 Oct 2018 06:26:39 +0000 Subject: [gnutls-devel] GnuTLS | update tlsfuzzer scripts to latest version (!774) In-Reply-To: References: Message-ID: So @Vrancken is that enough info to complete the review or would you like to skip? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/774#note_109393274 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Oct 17 08:31:19 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 17 Oct 2018 06:31:19 +0000 Subject: [gnutls-devel] GnuTLS | WIP: add support for 0-RTT (!775) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos started a new discussion on doc/cha-gtls-app.texi: > @funcref{gnutls_init}, and the @funcref{gnutls_handshake} function will > return early, allowing the server to send data earlier. > I think that deserves its own subsection, e.g., something like `Zero-roundtrip mode` or `Eliminating roundtrips`. What do you think? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/775#note_109393928 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Oct 17 08:32:16 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 17 Oct 2018 06:32:16 +0000 Subject: [gnutls-devel] GnuTLS | WIP: add support for 0-RTT (!775) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos started a new discussion on doc/cha-gtls-app.texi: > @funcref{gnutls_init}, and the @funcref{gnutls_handshake} function will > return early, allowing the server to send data earlier. > > +Under TLS 1.3, when the server and client share a @acronym{PSK}, the > +client side can start transmitting application data during handshake. > +This is called zero round-trip time (0-RTT) mode, and the application > +data sent in this mode is called early data. > + > +Note, however, that early data has weaker security properties than > +normal application data sent after handshake, such as lack of forward > +secrecy, no guarantees of non-replay between connections. Thus it is > +disabled on the server side by default. To enable it, set > + at acronym{GNUTLS_ENABLE_EARLY_DATA} on @funcref{gnutls_init}. Then the is that needed on both client and server? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/775#note_109394173 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Oct 17 08:34:48 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 17 Oct 2018 06:34:48 +0000 Subject: [gnutls-devel] GnuTLS | WIP: add support for 0-RTT (!775) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos started a new discussion on doc/cha-gtls-app.texi: > return early, allowing the server to send data earlier. > > +Under TLS 1.3, when the server and client share a @acronym{PSK}, the > +client side can start transmitting application data during handshake. > +This is called zero round-trip time (0-RTT) mode, and the application > +data sent in this mode is called early data. > + > +Note, however, that early data has weaker security properties than > +normal application data sent after handshake, such as lack of forward > +secrecy, no guarantees of non-replay between connections. Thus it is > +disabled on the server side by default. To enable it, set > + at acronym{GNUTLS_ENABLE_EARLY_DATA} on @funcref{gnutls_init}. Then the > +client can send early data with @funcref{gnutls_record_send_early_data} > +and the server can receive it with > + at funcref{gnutls_record_recv_early_data}. > + Two questions that arise after reading it, is what happens if the server does not read that data? and when should a server call the `gnutls_record_recv_early_data`? That is, is the server expected to call this function during the handshake or after it, or it can be both? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/775#note_109394561 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Oct 17 08:36:30 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 17 Oct 2018 06:36:30 +0000 Subject: [gnutls-devel] GnuTLS | WIP: add support for 0-RTT (!775) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos started a new discussion on doc/cha-gtls-app.texi: > @funcref{gnutls_init}, and the @funcref{gnutls_handshake} function will > return early, allowing the server to send data earlier. > > +Under TLS 1.3, when the server and client share a @acronym{PSK}, the This is accurate but maybe it can be confused with the PSK ciphersuites. What if described as: `when the client has already connected to the server and is resuming a session`? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/775#note_109394823 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Oct 17 12:43:39 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 17 Oct 2018 10:43:39 +0000 Subject: [gnutls-devel] GnuTLS | Something wrong with CI? (#592) In-Reply-To: References: Message-ID: @nmav @rockdaboot I think that it is wise to solve this issue first before we start merging new MRs into master. The CI is saying pass while it in fact is breaking on one of the tests on the Debian.x86_64 image. We currently have a false sense of OK. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/592#note_109470945 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Oct 17 12:51:34 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 17 Oct 2018 10:51:34 +0000 Subject: [gnutls-devel] GnuTLS | update tlsfuzzer scripts to latest version (!774) In-Reply-To: References: Message-ID: Tom commented on a discussion on lib/handshake.c: > + /* TLS1.2 or earlier, kx is associated with ciphersuite */ > + kx = session->security_parameters.cs->kx_algorithm; > } > > if (kx) { > session->security_parameters.server_auth_type = _gnutls_map_kx_get_cred(kx, 1); > session->security_parameters.client_auth_type = _gnutls_map_kx_get_cred(kx, 0); > - } else if (session->internals.resumed == RESUME_FALSE) { > - return gnutls_assert_val(GNUTLS_E_INTERNAL_ERROR); > + } else if (unlikely(session->internals.resumed == RESUME_FALSE)) { > + /* Here we can only arrive if something we received > + * prevented the session from completing. */ > + return gnutls_assert_val(GNUTLS_E_ILLEGAL_PARAMETER); > } > > return 0; That might be the case but I think it is not bad to change this convention then. It makes reading much clearer and we don't have this enum entry for nothing right? Once in a while it is good to upgrade to a better / nicer solution just as was the case with `gnutls_assert_val()` function. Anyway, in my contributions I return `GNUTLS_E_SUCCESS` in cases where I need to return an OK status code and use literals only where I need to return e.g. the number of bytes sent. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/774#note_109472790 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Oct 17 12:54:44 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 17 Oct 2018 10:54:44 +0000 Subject: [gnutls-devel] GnuTLS | update tlsfuzzer scripts to latest version (!774) In-Reply-To: References: Message-ID: I'll take a look but have to study the fuzzing system to get to know "that system". -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/774#note_109473502 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Oct 17 13:42:31 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 17 Oct 2018 11:42:31 +0000 Subject: [gnutls-devel] GnuTLS | WIP: add support for 0-RTT (!775) In-Reply-To: References: Message-ID: Daiki Ueno commented on a discussion on doc/cha-gtls-app.texi: > return early, allowing the server to send data earlier. > > +Under TLS 1.3, when the server and client share a @acronym{PSK}, the > +client side can start transmitting application data during handshake. > +This is called zero round-trip time (0-RTT) mode, and the application > +data sent in this mode is called early data. > + > +Note, however, that early data has weaker security properties than > +normal application data sent after handshake, such as lack of forward > +secrecy, no guarantees of non-replay between connections. Thus it is > +disabled on the server side by default. To enable it, set > + at acronym{GNUTLS_ENABLE_EARLY_DATA} on @funcref{gnutls_init}. Then the > +client can send early data with @funcref{gnutls_record_send_early_data} > +and the server can receive it with > + at funcref{gnutls_record_recv_early_data}. > + Currently, the data is kept until the server calls `gnutls_record_recv_early_data` so the answer is both. I think it makes more sense to keep it only during handshake and let the server retrieve it through a handshake callback. Let me try that. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/775#note_109485057 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Oct 17 13:48:58 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 17 Oct 2018 11:48:58 +0000 Subject: [gnutls-devel] GnuTLS | Something wrong with CI? (#592) In-Reply-To: References: Message-ID: Right. @nmav Could you increase the cache version in .gitlab-ci-yml and test it ? I am not sure when I find time to do it, sorry for that. ``` cache: key: "$CI_JOB_NAME-ver6" ``` -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/592#note_109486698 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Oct 17 14:56:05 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 17 Oct 2018 12:56:05 +0000 Subject: [gnutls-devel] GnuTLS | gnutls_priority_set: do not override the priority after handshake is complete (!777) References: Message-ID: New Merge Request !777 https://gitlab.com/gnutls/gnutls/merge_requests/777 Branches: tmp-fix-priority-set to master Author: Nikos Mavrogiannopoulos Assignee: Approvers: Simon Josefsson, Dmitry Eremin-Solenikov, Hubert Kario, Tim R?hsen, Andreas Metzler, Daiki Ueno, Tom, Ander Juaristi, Tom?? Mr?z, Anderson Sasaki and GnuTLS devel mailing list When an application would re-set priorities prior to a rehandshake we would override the negotiated version with the highest supported, something which may lead to issues. See: https://bugzilla.redhat.com/show_bug.cgi?id=1634736 ## Checklist * [x] Code modified for feature * [ ] Test suite updated with functionality tests (test rehandshake over TLS1.2 when priorities are set with TLS1.3) ## Reviewer's checklist: * [ ] Any issues marked for closing are addressed * [ ] There is a test suite reasonably covering new functionality or modifications * [ ] Function naming, parameters, return values, types, etc., are consistent and according to `CONTRIBUTION.md` * [ ] This feature/change has adequate documentation added * [ ] No obvious mistakes in the code -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/777 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Oct 17 17:09:15 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 17 Oct 2018 15:09:15 +0000 Subject: [gnutls-devel] GnuTLS | Service Desk (from p.mittermayer@gmail.com): OCSP Tests failing (#358) In-Reply-To: References: Message-ID: I got the same error , building gnutls-3.4.17-2.fc24.src.rpm on centos 7 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/358#note_109584650 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Oct 17 17:09:43 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 17 Oct 2018 15:09:43 +0000 Subject: [gnutls-devel] GnuTLS | Service Desk (from p.mittermayer@gmail.com): OCSP Tests failing (#358) In-Reply-To: References: Message-ID: S?rgio Basto started a new discussion: I got the same error , building gnutls-3.4.17-2.fc24.src.rpm on centos 7 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/358#note_109584754 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Oct 17 20:33:52 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 17 Oct 2018 18:33:52 +0000 Subject: [gnutls-devel] GnuTLS | Something wrong with CI? (#592) In-Reply-To: References: Message-ID: I have cleaned the CI caches and re-run the debian build in master branch. Is there anything else I should do? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/592#note_109643607 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Oct 17 23:01:36 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 17 Oct 2018 21:01:36 +0000 Subject: [gnutls-devel] GnuTLS | Something wrong with CI? (#592) In-Reply-To: References: Message-ID: Thanks for doing that. As you can see the test will actually run now and fail. Next step is to fix the bug that causes the fail ;-). I had a quick look at it but could not directly pinpoint the problem. This part of the code is still quite unknown to me. Could you guys have a look? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/592#note_109666477 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Oct 17 23:33:33 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 17 Oct 2018 21:33:33 +0000 Subject: [gnutls-devel] GnuTLS | p11tool: fix admin user PIN initialization (!776) In-Reply-To: References: Message-ID: The static buffer problem with getpass still persists. You also need to copy the buffer pointed to by pin which is returned by getpass in pkcs11_set_token_pin, so its not overwritten by pin_callback's getpass: ``` # p11tool --initialize-so-pin Setting admin's PIN... Enter Administrator's old PIN: 87654321 "oldpin=getpass, copied to _oldpin" Enter Administrators's new PIN: 76543210 "pin=getpass, not copied" Token 'swtok' with URL '' requires security officer PIN Enter PIN: 87654321 "password=getpass, pin overwritten" Error in pkcs11_set_token_pin:1516: Error in provided PIN. "C_SetPIN fails since oldpin=newpin" ``` It would possibly be the best option to substitute all getpass occurences by something like the following wrapper (which still lacks thread-safety): ``` int getpass_copy(char *pass, size_t passlen, const char *prompt) { char tmp; tmp = getpass(prompt); if (tmp == NULL) return SOME_ERROR; if (strlen(tmp) >= passlen) return SOME_ERROR; strcpy(pass, tmp); OPENSSL_cleanse(tmp, strlen(tmp)); return SUCCESS; } ``` -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/776#note_109670727 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Thu Oct 18 10:37:46 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 18 Oct 2018 08:37:46 +0000 Subject: [gnutls-devel] GnuTLS | pkcs11 uris: the scheme is case insensitive (!616) In-Reply-To: References: Message-ID: Stanislav ?idek started a new discussion on .gitlab-ci.yml: > - cd .. > tags: > - shared > + - docker This is probably unrelated, right? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/616#note_109820154 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Thu Oct 18 10:37:46 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 18 Oct 2018 08:37:46 +0000 Subject: [gnutls-devel] GnuTLS | pkcs11 uris: the scheme is case insensitive (!616) In-Reply-To: References: Message-ID: Stanislav ?idek started a new discussion on configure.ac: > fi > fi > > -AM_CONDITIONAL(P11KIT_0_23_10_API, ! $PKG_CONFIG --atleast-version=2.23.10 p11-kit) > +AM_CONDITIONAL(P11KIT_0_23_11_API, $PKG_CONFIG --atleast-version=0.23.11 p11-kit-1) I am not familiar much with autotools and stuff, but this seems weird. Why did the condition change (if exclamation mark is negation)? Is the change from `p11-kit` to `p11-kit-1` intended? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/616#note_109820152 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Thu Oct 18 11:10:48 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 18 Oct 2018 09:10:48 +0000 Subject: [gnutls-devel] GnuTLS | SKIP tests/global-init-override if weak symbols don't work (!778) References: Message-ID: New Merge Request !778 https://gitlab.com/gnutls/gnutls/merge_requests/778 Branches: tmp-fix-global-init-override to master Author: Tim R?hsen Assignee: Approvers: Simon Josefsson, Nikos Mavrogiannopoulos, Dmitry Eremin-Solenikov, Hubert Kario, Andreas Metzler, Daiki Ueno, Tom, Ander Juaristi, Tom?? Mr?z, Anderson Sasaki and GnuTLS devel mailing list Fixes #592 ## Checklist * [ ] Code modified for feature * [ ] Test suite updated with functionality tests * [ ] Test suite updated with negative tests * [ ] Documentation updated ## Reviewer's checklist: * [ ] Any issues marked for closing are addressed * [ ] There is a test suite reasonably covering new functionality or modifications * [ ] Function naming, parameters, return values, types, etc., are consistent and according to `CONTRIBUTION.md` * [ ] This feature/change has adequate documentation added * [ ] No obvious mistakes in the code -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/778 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Thu Oct 18 11:12:35 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 18 Oct 2018 09:12:35 +0000 Subject: [gnutls-devel] GnuTLS | Something wrong with CI? (#592) In-Reply-To: References: Message-ID: It's missing support for weak symbols (that -Wl,-Bsymbolic-functions option). !778 works locally here, but please review. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/592#note_109840078 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Thu Oct 18 14:38:50 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 18 Oct 2018 12:38:50 +0000 Subject: [gnutls-devel] GnuTLS | WIP: add support for 0-RTT (!775) In-Reply-To: References: Message-ID: Daiki Ueno commented on a discussion on doc/cha-gtls-app.texi: > @funcref{gnutls_init}, and the @funcref{gnutls_handshake} function will > return early, allowing the server to send data earlier. > I agree, added a new section under "Reducing round-trips". -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/775#note_109914829 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Thu Oct 18 14:39:41 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 18 Oct 2018 12:39:41 +0000 Subject: [gnutls-devel] GnuTLS | WIP: add support for 0-RTT (!775) In-Reply-To: References: Message-ID: Daiki Ueno commented on a discussion on doc/cha-gtls-app.texi: > @funcref{gnutls_init}, and the @funcref{gnutls_handshake} function will > return early, allowing the server to send data earlier. > > +Under TLS 1.3, when the server and client share a @acronym{PSK}, the > +client side can start transmitting application data during handshake. > +This is called zero round-trip time (0-RTT) mode, and the application > +data sent in this mode is called early data. > + > +Note, however, that early data has weaker security properties than > +normal application data sent after handshake, such as lack of forward > +secrecy, no guarantees of non-replay between connections. Thus it is > +disabled on the server side by default. To enable it, set > + at acronym{GNUTLS_ENABLE_EARLY_DATA} on @funcref{gnutls_init}. Then the It's only needed on server; rephrased it to be a bit clearer. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/775#note_109915049 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Thu Oct 18 14:40:01 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 18 Oct 2018 12:40:01 +0000 Subject: [gnutls-devel] GnuTLS | WIP: add support for 0-RTT (!775) In-Reply-To: References: Message-ID: Daiki Ueno commented on a discussion on doc/cha-gtls-app.texi: > @funcref{gnutls_init}, and the @funcref{gnutls_handshake} function will > return early, allowing the server to send data earlier. > > +Under TLS 1.3, when the server and client share a @acronym{PSK}, the Thank you for the suggestion; used that sentence. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/775#note_109915151 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Thu Oct 18 14:40:00 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 18 Oct 2018 12:40:00 +0000 Subject: [gnutls-devel] GnuTLS | WIP: add support for 0-RTT (!775) In-Reply-To: References: Message-ID: All discussions on Merge Request !775 were resolved by Daiki Ueno https://gitlab.com/gnutls/gnutls/merge_requests/775 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/775 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Thu Oct 18 14:45:19 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 18 Oct 2018 12:45:19 +0000 Subject: [gnutls-devel] GnuTLS | SKIP tests/global-init-override if weak symbols don't work (!778) In-Reply-To: References: Message-ID: Merge Request !778 was approved by Nikos Mavrogiannopoulos Merge Request url: https://gitlab.com/gnutls/gnutls/merge_requests/778 Branches: tmp-fix-global-init-override to master Author: Tim R?hsen Assignee: -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/778 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Thu Oct 18 14:45:40 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 18 Oct 2018 12:45:40 +0000 Subject: [gnutls-devel] GnuTLS | SKIP tests/global-init-override if weak symbols don't work (!778) In-Reply-To: References: Message-ID: Nice fix. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/778#note_109916678 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Thu Oct 18 14:45:51 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 18 Oct 2018 12:45:51 +0000 Subject: [gnutls-devel] GnuTLS | Something wrong with CI? (#592) In-Reply-To: References: Message-ID: Issue was closed by Nikos Mavrogiannopoulos Issue #592: https://gitlab.com/gnutls/gnutls/issues/592 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/592 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Thu Oct 18 14:45:54 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 18 Oct 2018 12:45:54 +0000 Subject: [gnutls-devel] GnuTLS | SKIP tests/global-init-override if weak symbols don't work (!778) In-Reply-To: References: Message-ID: Merge Request !778 was merged Merge Request url: https://gitlab.com/gnutls/gnutls/merge_requests/778 Branches: tmp-fix-global-init-override to master Author: Tim R?hsen Assignee: -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/778 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Thu Oct 18 14:46:44 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 18 Oct 2018 12:46:44 +0000 Subject: [gnutls-devel] GnuTLS | Something wrong with CI? (#592) In-Reply-To: References: Message-ID: It works on the CI as well. Approved. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/592#note_109916963 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Thu Oct 18 14:53:43 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 18 Oct 2018 12:53:43 +0000 Subject: [gnutls-devel] GnuTLS | pkcs11 uris: the scheme is case insensitive (!616) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos commented on a discussion on .gitlab-ci.yml: > - cd .. > tags: > - shared > + - docker Right. It is because these CI runs require a privileged container, and the "docker" flag marks these. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/616#note_109926983 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Thu Oct 18 14:55:32 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 18 Oct 2018 12:55:32 +0000 Subject: [gnutls-devel] GnuTLS | pkcs11 uris: the scheme is case insensitive (!616) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos commented on a discussion on configure.ac: > fi > fi > > -AM_CONDITIONAL(P11KIT_0_23_10_API, ! $PKG_CONFIG --atleast-version=2.23.10 p11-kit) > +AM_CONDITIONAL(P11KIT_0_23_11_API, $PKG_CONFIG --atleast-version=0.23.11 p11-kit-1) The condition was totally incorrect and didn't work. It was checking for incorrect version, and even incorrect name of the package (p11-kit is registered as p11-kit-1 in pkg-tools). You can test is locally as: ``` pkg-config --atleast-version=0.23.11 p11-kit-1 #(ok) pkg-config --atleast-version=2.23.11 p11-kit-1 #(should fail) -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/616#note_109927464 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Thu Oct 18 16:09:29 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 18 Oct 2018 14:09:29 +0000 Subject: [gnutls-devel] GnuTLS | p11tool: fix admin user PIN initialization (!776) In-Reply-To: References: Message-ID: Thanks, it seems the introduced test doesn't cover that path because it uses the non-interactive mode to set those PINs. I've updated the patch to address that. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/776#note_109952663 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Thu Oct 18 16:33:01 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 18 Oct 2018 14:33:01 +0000 Subject: [gnutls-devel] GnuTLS | WIP: add support for 0-RTT (!775) In-Reply-To: References: Message-ID: Daiki Ueno commented on a discussion on doc/cha-gtls-app.texi: > return early, allowing the server to send data earlier. > > +Under TLS 1.3, when the server and client share a @acronym{PSK}, the > +client side can start transmitting application data during handshake. > +This is called zero round-trip time (0-RTT) mode, and the application > +data sent in this mode is called early data. > + > +Note, however, that early data has weaker security properties than > +normal application data sent after handshake, such as lack of forward > +secrecy, no guarantees of non-replay between connections. Thus it is > +disabled on the server side by default. To enable it, set > + at acronym{GNUTLS_ENABLE_EARLY_DATA} on @funcref{gnutls_init}. Then the > +client can send early data with @funcref{gnutls_record_send_early_data} > +and the server can receive it with > + at funcref{gnutls_record_recv_early_data}. > + Thinking again, I realized that this makes it cumbersome to use. Since the server should be able to check whether it's accepted early data (with `gnutls_session_get_flags`), I would rather keep it while the session is active. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/775#note_109959750 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Thu Oct 18 16:47:45 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 18 Oct 2018 14:47:45 +0000 Subject: [gnutls-devel] GnuTLS | pkcs11 uris: the scheme is case insensitive (!616) In-Reply-To: References: Message-ID: Stanislav ?idek commented on a discussion on configure.ac: > fi > fi > > -AM_CONDITIONAL(P11KIT_0_23_10_API, ! $PKG_CONFIG --atleast-version=2.23.10 p11-kit) > +AM_CONDITIONAL(P11KIT_0_23_11_API, $PKG_CONFIG --atleast-version=0.23.11 p11-kit-1) Thanks for clarifying. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/616#note_109964151 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Thu Oct 18 16:49:31 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 18 Oct 2018 14:49:31 +0000 Subject: [gnutls-devel] GnuTLS | pkcs11 uris: the scheme is case insensitive (!616) In-Reply-To: References: Message-ID: Merge Request !616 was approved by Stanislav ?idek Merge Request url: https://gitlab.com/gnutls/gnutls/merge_requests/616 Branches: tmp-uris to master Author: Nikos Mavrogiannopoulos Assignee: -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/616 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Thu Oct 18 16:51:50 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 18 Oct 2018 14:51:50 +0000 Subject: [gnutls-devel] GnuTLS | p11tool: fix admin user PIN initialization (!776) In-Reply-To: References: Message-ID: Patrick Steuer started a new discussion on src/common.c: > + size_t len; > + > + tmp = getpass(prompt); > + if (tmp == NULL) { > + pass[0] = 0; > + return; > + } > + > + len = strlen(tmp); > + if (len >= max_pass_size) { > + pass[0] = 0; > + return; > + } > + > + strcpy(pass, tmp); > + gnutls_memset(pass, 0, len); Better zero tmp, not pass. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/776#note_109965208 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Thu Oct 18 17:24:25 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 18 Oct 2018 15:24:25 +0000 Subject: [gnutls-devel] GnuTLS | p11tool: fix admin user PIN initialization (!776) In-Reply-To: References: Message-ID: Patrick Steuer started a new discussion on src/pkcs11.c: > app_exit(1); > } > > - fprintf(stderr, "Setting token's user PIN...\n"); > + if (so) > + fprintf(stderr, "Setting admin's PIN...\n"); > + else > + fprintf(stderr, "Setting user's PIN...\n"); > > if (so) { > - if (info->so_pin != NULL) { > - pin = info->so_pin; > + if (info->batch == 0) { If i remember correctly, the tool works different with GNUTLS_SO_PIN env var i.e., if GNUTLS_SO_PIN is set the user is not asked to enter it even in non-batch mode. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/776#note_109973584 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Thu Oct 18 17:26:21 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 18 Oct 2018 15:26:21 +0000 Subject: [gnutls-devel] GnuTLS | p11tool: fix admin user PIN initialization (!776) In-Reply-To: References: Message-ID: Patrick Steuer started a new discussion on src/pkcs11.c: > - pin = getpass("Enter Administrators's new PIN: "); > - if (pin == NULL) > + getenv_copy(tmp, sizeof(tmp), "GNUTLS_OLD_SO_PIN"); > + if (tmp[0] == 0) { > + fprintf(stderr, "Use GNUTLS_OLD_SO_PIN in batch mode\n"); > app_exit(1); > + } > + } > + > + if (tmp[0] != 0) > + oldpin = tmp; > + > + if (info->so_pin != NULL) { > + snprintf(newpin, sizeof(newpin), "%s", info->so_pin); > + } else { > + getenv_copy(newpin, sizeof(newpin), "GNUTLS_NEW_SO_PIN"); E.g. here it works differently: only ask user to enter pin if env var is not set. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/776#note_109974042 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Thu Oct 18 17:30:41 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 18 Oct 2018 15:30:41 +0000 Subject: [gnutls-devel] GnuTLS | p11tool: fix admin user PIN initialization (!776) In-Reply-To: References: Message-ID: Everything works as expected if after fixing pass zeroization. Other comments just address env var pin vs user entered pin priorities. I even wondered about the sense of asking for old SO pin since you have to enter it later again, before doing an SO operation. Maybe it has to do how user and so pin (re)setting code paths are interleaved, dont know the codebase too well. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/776#note_109975209 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Thu Oct 18 21:14:45 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 18 Oct 2018 19:14:45 +0000 Subject: [gnutls-devel] GnuTLS | pkcs11 uris: the scheme is case insensitive (!616) In-Reply-To: References: Message-ID: All discussions on Merge Request !616 were resolved by Nikos Mavrogiannopoulos https://gitlab.com/gnutls/gnutls/merge_requests/616 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/616 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Thu Oct 18 21:14:50 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 18 Oct 2018 19:14:50 +0000 Subject: [gnutls-devel] GnuTLS | uris schemes: should be tested in a case insensitive way (#590) In-Reply-To: References: Message-ID: Issue was closed by Nikos Mavrogiannopoulos Issue #590: https://gitlab.com/gnutls/gnutls/issues/590 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/590 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Thu Oct 18 21:14:52 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 18 Oct 2018 19:14:52 +0000 Subject: [gnutls-devel] GnuTLS | pkcs11 uris: the scheme is case insensitive (!616) In-Reply-To: References: Message-ID: Merge Request !616 was merged Merge Request url: https://gitlab.com/gnutls/gnutls/merge_requests/616 Branches: tmp-uris to master Author: Nikos Mavrogiannopoulos Assignee: -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/616 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Thu Oct 18 21:14:57 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 18 Oct 2018 19:14:57 +0000 Subject: [gnutls-devel] GnuTLS | pkcs11 uris: the scheme is case insensitive (!616) In-Reply-To: References: Message-ID: Thank you for the review! -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/616#note_110026350 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Thu Oct 18 21:28:11 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 18 Oct 2018 19:28:11 +0000 Subject: [gnutls-devel] GnuTLS | p11tool: fix admin user PIN initialization (!776) In-Reply-To: References: Message-ID: > Everything works as expected after fixing pass zeroization. Thanks, I've addressed the comments. > I even wondered about the sense of asking for old SO pin since you have to enter it later again, before doing an SO operation. Maybe it has to do how user and so pin (re)setting code paths are interleaved, dont know the codebase too well. Hmm, indeed maybe we can optimize that path. Let me see it with clear mind later tomorrow. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/776#note_110028111 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Thu Oct 18 23:24:10 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 18 Oct 2018 21:24:10 +0000 Subject: [gnutls-devel] GnuTLS | Cleanup and fixes (!779) References: Message-ID: New Merge Request !779 https://gitlab.com/gnutls/gnutls/merge_requests/779 Project:Branches: Vrancken/gnutls-kdh:tmp_cleanup_and_fixes to gnutls/gnutls:master Author: Tom Assignee: These are all small fixes and changes that were asked to put in a separate patch in reviews of !498 and !650. ## Checklist * [ ] Code modified for feature * [ ] Test suite updated with functionality tests * [ ] Test suite updated with negative tests * [ ] Documentation updated ## Reviewer's checklist: * [ ] Any issues marked for closing are addressed * [ ] There is a test suite reasonably covering new functionality or modifications * [ ] Function naming, parameters, return values, types, etc., are consistent and according to `CONTRIBUTION.md` * [ ] This feature/change has adequate documentation added * [ ] No obvious mistakes in the code -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/779 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Thu Oct 18 23:27:19 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 18 Oct 2018 21:27:19 +0000 Subject: [gnutls-devel] GnuTLS | WIP: RFC7250 Raw public keys (!650) In-Reply-To: References: Message-ID: @nmav could you take a look at the remaining unresolved discussions? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/650#note_110082392 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Thu Oct 18 23:29:15 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 18 Oct 2018 21:29:15 +0000 Subject: [gnutls-devel] GnuTLS | WIP: RFC7250 Raw public keys (!650) In-Reply-To: References: Message-ID: Tom commented on a discussion on lib/includes/gnutls/gnutls.h.in: > unsigned idx, > gnutls_datum_t * response); > > +/* RAW public key functions (RFC7250) */ > +#ifdef ENABLE_RAWPK > +int gnutls_certificate_set_rawpk_keypair(gnutls_certificate_credentials_t cred, > + const gnutls_pubkey_t subjectPublicKeyInfo, > + const gnutls_privkey_t key); > + > +int gnutls_certificate_set_rawpk_keypair_raw(gnutls_certificate_credentials_t cred, Just a thought that came up. > Well, the other APIs are there for long and cannot be fixed any more. I see an advantage in being consistent. What do think about using the newly proposed naming convention and creating aliases for the old functions? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/650#note_110083365 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Oct 19 08:18:31 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 19 Oct 2018 06:18:31 +0000 Subject: [gnutls-devel] GnuTLS | WIP: p11tool: fix admin user PIN initialization (!776) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos commented on a discussion on src/common.c: > + size_t len; > + > + tmp = getpass(prompt); > + if (tmp == NULL) { > + pass[0] = 0; > + return; > + } > + > + len = strlen(tmp); > + if (len >= max_pass_size) { > + pass[0] = 0; > + return; > + } > + > + strcpy(pass, tmp); > + gnutls_memset(pass, 0, len); Fixed. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/776#note_110150039 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Oct 19 08:18:44 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 19 Oct 2018 06:18:44 +0000 Subject: [gnutls-devel] GnuTLS | WIP: p11tool: fix admin user PIN initialization (!776) In-Reply-To: References: Message-ID: All discussions on Merge Request !776 were resolved by Nikos Mavrogiannopoulos https://gitlab.com/gnutls/gnutls/merge_requests/776 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/776 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Oct 19 08:42:14 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 19 Oct 2018 06:42:14 +0000 Subject: [gnutls-devel] GnuTLS | p11tool: fix admin user PIN initialization (!776) In-Reply-To: References: Message-ID: Thank you for the suggestion, tried it and the interface is much more natural. I've tested it manually using softhsm2. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/776#note_110153353 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Oct 19 08:44:09 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 19 Oct 2018 06:44:09 +0000 Subject: [gnutls-devel] GnuTLS | Cleanup and fixes (!779) In-Reply-To: References: Message-ID: Thank you for doing that! I'll try to review the changes soon. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/779#note_110153629 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Oct 19 08:48:33 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 19 Oct 2018 06:48:33 +0000 Subject: [gnutls-devel] GnuTLS | WIP: add support for 0-RTT (!775) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos started a new discussion on doc/cha-gtls-app.texi: > @funcref{gnutls_init}, and the @funcref{gnutls_handshake} function will > return early, allowing the server to send data earlier. > > -Under TLS 1.3, when the server and client share a @acronym{PSK}, the > -client side can start transmitting application data during handshake. > -This is called zero round-trip time (0-RTT) mode, and the application > -data sent in this mode is called early data. > + > + at node Zero-roundtrip mode > + at subsection Zero-roundtrip mode > + > +Under TLS 1.3, when the client has already connected to the server and > +is resuming a session, it can start transmitting application data during > +handshake. This is called zero round-trip time (0-RTT) mode, and the > +application data sent in this mode is called early data. The client can > +send early data with @funcref{gnutls_record_send_early_data}. Thank you, that's much more clear. One more question that I think it should be clarified in the text, is when should a client call this function? For example (according to my current understanding): ``` the client should call this function before calling gnutls_handshake() and after calling gnutls_session_set_data() ``` -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/775#note_110154238 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Oct 19 08:52:13 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 19 Oct 2018 06:52:13 +0000 Subject: [gnutls-devel] GnuTLS | WIP: add support for 0-RTT (!775) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos started a new 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); > + ... LGTM. @airtower-luna what do you think of this API from the apache `mod_gnutls` perspective? Is it what you'd expect to handle 0RTT? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/775#note_110154756 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Oct 19 09:44:27 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 19 Oct 2018 07:44:27 +0000 Subject: [gnutls-devel] GnuTLS | gnutls_priority_set: do not override the version after handshake is complete (!777) In-Reply-To: References: Message-ID: Tom started a new discussion on lib/priority.c: > session->internals.priorities = priority; > gnutls_atomic_increment(&priority->usage_cnt); > > - /* set the current version to the first in the chain. > - * This will be overridden later. > - */ > + /* set the current version to the first in the chain, if that's > + * the call before the initial handshake. This will be overridden by > + * the handshake call. */ > if (session->internals.priorities->protocol.algorithms > 0 && > - !session->internals.handshake_in_progress) { > + !session->internals.handshake_in_progress && > + !session->internals.initial_negotiation_completed) { > if (_gnutls_set_current_version(session, What happens if a client wants to downgrade the protocol version during a rehandshake? That is not possible now right? Do we want to allow that? What happens when a client wants to upgrade the protocol version from 1.1 to 1.2 during a rehandshake? That won't work either right? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/777#note_110165114 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Oct 19 09:44:29 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 19 Oct 2018 07:44:29 +0000 Subject: [gnutls-devel] GnuTLS | gnutls_priority_set: do not override the version after handshake is complete (!777) In-Reply-To: References: Message-ID: Tom started a new discussion on lib/priority.c: > session->internals.priorities = priority; > gnutls_atomic_increment(&priority->usage_cnt); > > - /* set the current version to the first in the chain. > - * This will be overridden later. > - */ > + /* set the current version to the first in the chain, if that's > + * the call before the initial handshake. This will be overridden by > + * the handshake call. */ I don't understand what you mean with "This will be overridden by the handshake call."? Maybe you could comment this code like: > Set the current version to the first in the chain if this is the call before the initial handshake. During a rehandshake a potential new protocol version will be ignored. Also, why not move the check at line 612 all the way up and return early? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/777#note_110165118 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Oct 19 09:44:28 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 19 Oct 2018 07:44:28 +0000 Subject: [gnutls-devel] GnuTLS | gnutls_priority_set: do not override the version after handshake is complete (!777) In-Reply-To: References: Message-ID: Tom started a new discussion on tests/tls12-rehandshake-set-prio.c: > + gnutls_certificate_credentials_t serverx509cred; > + gnutls_session_t server; > + int sret = GNUTLS_E_AGAIN; > + /* Client stuff. */ > + gnutls_certificate_credentials_t clientx509cred; > + gnutls_session_t client; > + int cret = GNUTLS_E_AGAIN; > + unsigned i; > + > + /* General init. */ > + reset_buffers(); > + assert(gnutls_global_init()>=0); > + > + gnutls_global_set_log_function(tls_log_func); > + > + assert(gnutls_certificate_allocate_credentials(&serverx509cred)>=0); You might want to add a `/* Init server */` comment here to be consistent with the client part below. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/777#note_110165115 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Oct 19 10:07:39 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 19 Oct 2018 08:07:39 +0000 Subject: [gnutls-devel] GnuTLS | Constpkcs1rsa (!780) References: Message-ID: New Merge Request !780 https://gitlab.com/gnutls/gnutls/merge_requests/780 Project:Branches: nmav/gnutls:constpkcs1rsa to gnutls/gnutls:master Author: Nikos Mavrogiannopoulos Assignee: Approvers: Simon Josefsson, Dmitry Eremin-Solenikov, Hubert Kario, Tim R?hsen, Andreas Metzler, Daiki Ueno, Tom, Ander Juaristi, Tom?? Mr?z, Anderson Sasaki and GnuTLS devel mailing list Add a description of the new feature/bug fix. Reference any relevant bugs. ## Checklist * [ ] Code modified for feature * [ ] Test suite updated with functionality tests * [ ] Test suite updated with negative tests * [ ] Documentation updated ## Reviewer's checklist: * [ ] Any issues marked for closing are addressed * [ ] There is a test suite reasonably covering new functionality or modifications * [ ] Function naming, parameters, return values, types, etc., are consistent and according to `CONTRIBUTION.md` * [ ] This feature/change has adequate documentation added * [ ] No obvious mistakes in the code -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/780 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Oct 19 10:07:46 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 19 Oct 2018 08:07:46 +0000 Subject: [gnutls-devel] GnuTLS | Constpkcs1rsa (!780) In-Reply-To: References: Message-ID: Merge Request !780 was closed by Nikos Mavrogiannopoulos Merge Request url: https://gitlab.com/gnutls/gnutls/merge_requests/780 Project:Branches: nmav/gnutls:constpkcs1rsa to gnutls/gnutls:master Author: Nikos Mavrogiannopoulos Assignee: -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/780 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Oct 19 10:10:52 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 19 Oct 2018 08:10:52 +0000 Subject: [gnutls-devel] GnuTLS | p11tool: fix admin user PIN initialization (!776) In-Reply-To: References: Message-ID: Tim R?hsen commented on a discussion on src/common.c: > + size_t len; > + > + tmp = getpass(prompt); > + if (tmp == NULL) { > + pass[0] = 0; > + return; > + } > + > + len = strlen(tmp); > + if (len >= max_pass_size) { > + pass[0] = 0; > + return; > + } > + > + strcpy(pass, tmp); > + gnutls_memset(pass, 0, len); Maybe nitpicking, but why not zero out `tmp` when `if (len >= max_pass_size) {` ? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/776#note_110170955 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Oct 19 10:19:11 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 19 Oct 2018 08:19:11 +0000 Subject: [gnutls-devel] GnuTLS | update tlsfuzzer scripts to latest version (!774) In-Reply-To: References: Message-ID: Merge Request !774 was approved by Tom Merge Request url: https://gitlab.com/gnutls/gnutls/merge_requests/774 Branches: tmp-update-tlsfuzzer to master Author: Nikos Mavrogiannopoulos Assignee: -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/774 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Oct 19 10:32:37 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 19 Oct 2018 08:32:37 +0000 Subject: [gnutls-devel] GnuTLS | WIP: add support for 0-RTT (!775) In-Reply-To: References: Message-ID: Daiki Ueno commented on a discussion on doc/cha-gtls-app.texi: > @funcref{gnutls_init}, and the @funcref{gnutls_handshake} function will > return early, allowing the server to send data earlier. > > -Under TLS 1.3, when the server and client share a @acronym{PSK}, the > -client side can start transmitting application data during handshake. > -This is called zero round-trip time (0-RTT) mode, and the application > -data sent in this mode is called early data. > + > + at node Zero-roundtrip mode > + at subsection Zero-roundtrip mode > + > +Under TLS 1.3, when the client has already connected to the server and > +is resuming a session, it can start transmitting application data during > +handshake. This is called zero round-trip time (0-RTT) mode, and the > +application data sent in this mode is called early data. The client can > +send early data with @funcref{gnutls_record_send_early_data}. It is mentioned in the function documentation, but let me add it here as well. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/775#note_110176085 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Oct 19 10:36:21 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 19 Oct 2018 08:36:21 +0000 Subject: [gnutls-devel] GnuTLS | update tlsfuzzer scripts to latest version (!774) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos commented on a discussion on lib/handshake.c: > + /* TLS1.2 or earlier, kx is associated with ciphersuite */ > + kx = session->security_parameters.cs->kx_algorithm; > } > > if (kx) { > session->security_parameters.server_auth_type = _gnutls_map_kx_get_cred(kx, 1); > session->security_parameters.client_auth_type = _gnutls_map_kx_get_cred(kx, 0); > - } else if (session->internals.resumed == RESUME_FALSE) { > - return gnutls_assert_val(GNUTLS_E_INTERNAL_ERROR); > + } else if (unlikely(session->internals.resumed == RESUME_FALSE)) { > + /* Here we can only arrive if something we received > + * prevented the session from completing. */ > + return gnutls_assert_val(GNUTLS_E_ILLEGAL_PARAMETER); > } > > return 0; We should try to be consistent on way or another, but I find returning zero much simpler (less typing), and makes error checking more natural (checking `< 0` for error feels more natural when you return zero on success). `GNUTLS_E_SUCCESS` was introduced for users of the library to use it when they like it (e.g., because it may look cleaner as you mention). However, that proved to be an issue because then some applications were checking for error as `if (ret != GNUTLS_E_SUCCESS)` instead of `if (ret < 0)`.applications were checking for error as `if (ret != GNUTLS_E_SUCCESS)` instead of `if (ret < 0)`. I may be wrong but I feel that the use of a definition for zero prompted a different use than the originally intended, and caused problem when enhancing APIs to return more specific info (e.g., how many certs were loaded), on newer revisions of gnutls. That prompted the introduction of the ugly `GNUTLS_CERTIFICATE_API_V2` flag. So if I would change something would be to mark the use of `GNUTLS_E_SUCCESS` as deprecated :) Nevertheless, lets discuss this on a separate bug or cleanup MR. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/774#note_110177092 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Oct 19 10:37:20 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 19 Oct 2018 08:37:20 +0000 Subject: [gnutls-devel] GnuTLS | update tlsfuzzer scripts to latest version (!774) In-Reply-To: References: Message-ID: All discussions on Merge Request !774 were resolved by Nikos Mavrogiannopoulos https://gitlab.com/gnutls/gnutls/merge_requests/774 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/774 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Oct 19 10:37:26 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 19 Oct 2018 08:37:26 +0000 Subject: [gnutls-devel] GnuTLS | WIP: add support for 0-RTT (!775) In-Reply-To: References: Message-ID: Daiki Ueno 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); > + ... Not sure why you refer to the previous revision, but note that the latest revision doesn't require `gnutls_record_recv_early_data` to be called in a handshake hook; the data retains after handshake and the server can check whether early data arrived with `gnutls_session_get_flags`. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/775#note_110177451 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Oct 19 10:37:36 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 19 Oct 2018 08:37:36 +0000 Subject: [gnutls-devel] GnuTLS | tlsfuzzer: include latest tests (#591) In-Reply-To: References: Message-ID: Issue was closed by Nikos Mavrogiannopoulos Issue #591: https://gitlab.com/gnutls/gnutls/issues/591 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/591 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Oct 19 10:37:36 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 19 Oct 2018 08:37:36 +0000 Subject: [gnutls-devel] GnuTLS | update tlsfuzzer scripts to latest version (!774) In-Reply-To: References: Message-ID: Merge Request !774 was merged Merge Request url: https://gitlab.com/gnutls/gnutls/merge_requests/774 Branches: tmp-update-tlsfuzzer to master Author: Nikos Mavrogiannopoulos Assignee: -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/774 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Oct 19 10:37:57 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 19 Oct 2018 08:37:57 +0000 Subject: [gnutls-devel] GnuTLS | update tlsfuzzer scripts to latest version (!774) In-Reply-To: References: Message-ID: Reassigned Merge Request 774 https://gitlab.com/gnutls/gnutls/merge_requests/774 Assignee changed to Nikos Mavrogiannopoulos -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/774 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Oct 19 10:37:45 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 19 Oct 2018 08:37:45 +0000 Subject: [gnutls-devel] GnuTLS | update tlsfuzzer scripts to latest version (!774) In-Reply-To: References: Message-ID: Thank you for the review! -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/774#note_110177541 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Oct 19 11:53:23 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 19 Oct 2018 09:53:23 +0000 Subject: [gnutls-devel] GnuTLS | gnutls_priority_set: do not override the version after handshake is complete (!777) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos commented on a discussion on lib/priority.c: > session->internals.priorities = priority; > gnutls_atomic_increment(&priority->usage_cnt); > > - /* set the current version to the first in the chain. > - * This will be overridden later. > - */ > + /* set the current version to the first in the chain, if that's > + * the call before the initial handshake. This will be overridden by > + * the handshake call. */ > if (session->internals.priorities->protocol.algorithms > 0 && > - !session->internals.handshake_in_progress) { > + !session->internals.handshake_in_progress && > + !session->internals.initial_negotiation_completed) { > if (_gnutls_set_current_version(session, > What happens if a client wants to downgrade the protocol version during a rehandshake? That is not possible now right? Do we want to allow that? That's uncharted territory. I do not know if that's possible now, but certainly it shouldn't. There is no reason to do that (i.e., reduce the security level of a subsequent handshake) thus if happens it should be well prohibited. So no I do not think we should support something like that :) > What happens when a client wants to upgrade the protocol version from 1.1 to 1.2 during a rehandshake? That won't work either right? That shouldn't work either. Any rehandshake should result in the same protocol version or fail. Again I'm not sure whether we have tests for that. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/777#note_110198074 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Oct 19 11:55:34 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 19 Oct 2018 09:55:34 +0000 Subject: [gnutls-devel] GnuTLS | gnutls_priority_set: do not override the version after handshake is complete (!777) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos commented on a discussion on tests/tls12-rehandshake-set-prio.c: > + gnutls_certificate_credentials_t serverx509cred; > + gnutls_session_t server; > + int sret = GNUTLS_E_AGAIN; > + /* Client stuff. */ > + gnutls_certificate_credentials_t clientx509cred; > + gnutls_session_t client; > + int cret = GNUTLS_E_AGAIN; > + unsigned i; > + > + /* General init. */ > + reset_buffers(); > + assert(gnutls_global_init()>=0); > + > + gnutls_global_set_log_function(tls_log_func); > + > + assert(gnutls_certificate_allocate_credentials(&serverx509cred)>=0); Done -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/777#note_110198581 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Oct 19 12:06:44 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 19 Oct 2018 10:06:44 +0000 Subject: [gnutls-devel] GnuTLS | gnutls_priority_set: do not override the version after handshake is complete (!777) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos commented on a discussion on lib/priority.c: > session->internals.priorities = priority; > gnutls_atomic_increment(&priority->usage_cnt); > > - /* set the current version to the first in the chain. > - * This will be overridden later. > - */ > + /* set the current version to the first in the chain, if that's > + * the call before the initial handshake. This will be overridden by > + * the handshake call. */ Nice suggestion. That prompted me to do a re-organization of the function. Let's see if that works well. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/777#note_110201406 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Oct 19 17:00:29 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 19 Oct 2018 15:00:29 +0000 Subject: [gnutls-devel] GnuTLS | add support for AES-XTS mode (#354) In-Reply-To: References: Message-ID: Submitted nettle implementation here: https://lists.lysator.liu.se/pipermail/nettle-bugs/2018/007354.html -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/354#note_110286112 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Oct 19 17:23:00 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 19 Oct 2018 15:23:00 +0000 Subject: [gnutls-devel] GnuTLS | Cleanup and fixes (!779) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos started a new discussion on lib/ext/client_cert_type.c: > * i.e. have credentials for. Therefore we check this here and > * prune our original list. > */ > - for (i = 0; i < cert_priors->algorithms; i++) { > + for (i = 0; i < cert_priors->num_priorities; i++) { > if (_gnutls_session_cert_type_supported > - (session, cert_priors->priority[i], > + (session, cert_priors->priorities[i], `cert_priors->priorities` looks very awkward... Maybe we should use just one type of abbreviation or not. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/779#note_110291890 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Oct 19 17:23:02 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 19 Oct 2018 15:23:02 +0000 Subject: [gnutls-devel] GnuTLS | Cleanup and fixes (!779) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos started a new discussion on lib/cert-cred.c: > void > gnutls_certificate_free_credentials(gnutls_certificate_credentials_t sc) > { > - gnutls_x509_trust_list_deinit(sc->tlist, 1); > - gnutls_certificate_free_keys(sc); > - memset(sc->pin_tmp, 0, sizeof(sc->pin_tmp)); > + // Check for valid pointer and otherwise do nothing > + if (sc != NULL) { This is ok, but adding the check on top such as: ``` if (sc == NULL) return; ``` Would reduce the number of changes. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/779#note_110291891 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Oct 19 17:23:01 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 19 Oct 2018 15:23:01 +0000 Subject: [gnutls-devel] GnuTLS | Cleanup and fixes (!779) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos started a new discussion on lib/cert-cred-x509.c: > */ > > static int > -certificate_credential_append_crt_list(gnutls_certificate_credentials_t res, > +certificate_credential_append_keypair(gnutls_certificate_credentials_t res, That does append both a keypair and a certificate list. Both names seem right. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/779#note_110291892 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Oct 19 17:23:19 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 19 Oct 2018 15:23:19 +0000 Subject: [gnutls-devel] GnuTLS | Cleanup and fixes (!779) In-Reply-To: References: Message-ID: Apart from the items I raised for discussion LGTM! -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/779#note_110291958 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Oct 19 18:17:24 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 19 Oct 2018 16:17:24 +0000 Subject: [gnutls-devel] GnuTLS | WIP: add support for 0-RTT (!775) In-Reply-To: References: Message-ID: By the way, I am currently implementing ClientHello recording (RFC 8446 8.2), as anti-replay measure. That suggests that in some occasions (e.g. a ticket arrived out of time window), the server should reject 0-RTT but can continue with 1-RTT. In that case, the client may want to resend the early data as a normal application data after handshake. So rather than having a separate send function (`gnutls_record_send_early_data`), it might make more sense to reuse `gnutls_record_send2` and allow it to fallback from 0-RTT to 1-RTT. What do you think? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/775#note_110331340 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Oct 19 21:18:23 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 19 Oct 2018 19:18:23 +0000 Subject: [gnutls-devel] GnuTLS | WIP: add support for 0-RTT (!775) In-Reply-To: References: Message-ID: 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); > + ... Maybe my interface didn't update the text. The final text is: https://gitlab.com/gnutls/gnutls/merge_requests/775/diffs#04efa6908cdf650892ddc97766b5fadce0048fc0_919_920 though I liked the example with the callback because most likely that's what a server would use (so that early data are not only received but also processed early). -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/775#note_110383620 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Oct 19 21:20:23 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 19 Oct 2018 19:20:23 +0000 Subject: [gnutls-devel] GnuTLS | WIP: add support for 0-RTT (!775) In-Reply-To: References: Message-ID: > By the way, I am currently implementing ClientHello recording (RFC 8446 8.2), as anti-replay measure. That suggests that in some occasions (e.g. a ticket arrived out of time window), the server should reject 0-RTT but can continue with 1-RTT. In that case, the client may want to resend the early data as a normal application data after handshake. So rather than having a separate send function (`gnutls_record_send_early_data`), it might make more sense to reuse `gnutls_record_send2` and allow it to fallback from 0-RTT to 1-RTT. > What do you think? I looks easier to use, but could it be misused, e.g, to send early data when not intended? If not (e.g., because early data must be explicitly enabled), it looks better to me. One other comment when going through the API again, is that the `gnutls_record_recv_early_data` when used either with the callback or after the handshake, it assumes that all early data are cached. So maybe we make a note of that expectation in the documentation and refer to the function that can be used to adjust the value when the default may seem excessive to a server. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/775#note_110383881 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Oct 19 21:23:08 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 19 Oct 2018 19:23:08 +0000 Subject: [gnutls-devel] GnuTLS | WIP: add support for 0-RTT (!775) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos started a new discussion on lib/record.c: > + data_size); > + if (ret < 0) > + return gnutls_assert_val(ret); > + > + return ret; > +} > + > +/** > + * gnutls_record_recv_early_data: > + * @session: is a #gnutls_session_t type. > + * @data: the buffer that the data will be read into > + * @data_size: the number of requested bytes > + * > + * This function has the similar semantics with gnutls_record_recv(). > + * The only difference is that it returns the application data sent as > + * early data and thus it must be called in a handshake hook by the 's/in a handshake hook/in a handshake hook, or after the handshake is complete/g' -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/775#note_110384702 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Oct 19 21:24:07 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 19 Oct 2018 19:24:07 +0000 Subject: [gnutls-devel] GnuTLS | WIP: add support for 0-RTT (!775) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos started a new discussion on lib/record.c: > + > + return ret; > +} > + > +/** > + * gnutls_record_recv_early_data: > + * @session: is a #gnutls_session_t type. > + * @data: the buffer that the data will be read into > + * @data_size: the number of requested bytes > + * > + * This function has the similar semantics with gnutls_record_recv(). > + * The only difference is that it returns the application data sent as > + * early data and thus it must be called in a handshake hook by the > + * server. > + * > + * If %EINTR is returned by the internal pull function (the default Does EINTR or other interruptions apply here? I thought that this receives from a buffer only. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/775#note_110384900 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Oct 19 21:25:55 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 19 Oct 2018 19:25:55 +0000 Subject: [gnutls-devel] GnuTLS | WIP: add support for 0-RTT (!775) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos started a new discussion on lib/record.c: > + * @session: is a #gnutls_session_t type. > + * @data: the buffer that the data will be read into > + * @data_size: the number of requested bytes > + * > + * This function has the similar semantics with gnutls_record_recv(). > + * The only difference is that it returns the application data sent as > + * early data and thus it must be called in a handshake hook by the > + * server. > + * > + * If %EINTR is returned by the internal pull function (the default > + * is recv()) then %GNUTLS_E_INTERRUPTED will be returned. If > + * %GNUTLS_E_INTERRUPTED or %GNUTLS_E_AGAIN is returned, you must > + * call this function again to get the data. See also > + * gnutls_record_get_direction(). > + * > + * Returns: The number of bytes received and zero on EOF (for stream Maybe: `The number of bytes received and zero when early data reading is complete; A negative error code is returned in case of an error.` (Here the text also implies that one should read it in a loop until it returns zero, is that the intention?) -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/775#note_110387047 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Oct 19 21:28:45 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 19 Oct 2018 19:28:45 +0000 Subject: [gnutls-devel] GnuTLS | WIP: RFC7250 Raw public keys (!650) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos commented on a discussion on lib/includes/gnutls/gnutls.h.in: > unsigned idx, > gnutls_datum_t * response); > > +/* RAW public key functions (RFC7250) */ > +#ifdef ENABLE_RAWPK > +int gnutls_certificate_set_rawpk_keypair(gnutls_certificate_credentials_t cred, Certainly, it makes sense to me. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/650#note_110390099 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Oct 19 21:33:57 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 19 Oct 2018 19:33:57 +0000 Subject: [gnutls-devel] GnuTLS | WIP: RFC7250 Raw public keys (!650) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos commented on a discussion on doc/cha-gtls-app.texi: > (i.e. different for the client than for the server). > > Currently supported types are: > -CTYPE-X509 or CTYPE-X.509. Catch all is CTYPE-ALL. > +CTYPE-X509 or CTYPE-X.509, CTYPE-RAWPK or CTYPE-RAWPUBKEY. Catch all is CTYPE-ALL. > Yes you can. We do it in our TLS Pool project (https://github.com/arpa2/tlspool). I understand that some apps can do it. > Secondly, I understand your concern about giving users the power to enable features that the application was not developed for. With that in mind we can introduce a flag to be able to enable/disable rawpk functionality via an init flag. On the other hand, I don't see how a user can mess things up by setting certificate priorities? The system will only use credential types that are actually available and an application developer should check what type it receives and act accordingly. Do you have a specific scenario in mind which will break? As long as this is a no-op unless one enables raw public keys in the application explicitly, it could work. > In the end I think we should make a decision about whether or not to use an extra init flag. If we do, I need to figure out how to incorporate it into the code. I think we should to protect apps which may not be ready for it. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/650#note_110394865 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Sat Oct 20 13:45:31 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sat, 20 Oct 2018 11:45:31 +0000 Subject: [gnutls-devel] GnuTLS | CTYPE-OPENPGP priority no longer recognized (#593) References: Message-ID: New Issue was created. Issue 593: https://gitlab.com/gnutls/gnutls/issues/593 Author: Andreas Metzler Assignee: Hello, GnuTLS 3.6 has not only dropped support for OpenPGP keys but also for the CTYPE-OPENPGP priority-string. It would be nice if it was treated as a noop or if the negated variety (e.g. the priority "NORMAL:-CTYPE-OPENPGP") continued to work. TIA, cu Andreas -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/593 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Sun Oct 21 08:37:19 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sun, 21 Oct 2018 06:37:19 +0000 Subject: [gnutls-devel] GnuTLS | Clarify or improve our supported releases meaning (#588) In-Reply-To: References: Message-ID: > @ametzler any thoughts on that? The situation we have now is that at > any ABI breakage the previous release (e.g., 2.12.x, 3.3.x) became a > de-facto LTS release as distributions like debian/rhel rely on it > cannot move forward. So first question is, would you as debian > maintainer be interested in a collaborative maintainership of a > similar LTS branch in the future? Ie. bring the debian patches if any > and thus also have a say on what other patches go in and on how long > would that be open? (and such offer would be open to other > distributions) Would that make sense from your perspective? Hello, to be honest I do not think there is a lot *I* could contribute there. (Coding skills) Also we are quite limited in what changes are acceptable for Debian stable - just fixing security issue and important bugs. This simply does not match with how GnuTLS stable releases work, they include fixes for minor issues, too. Up until 3.6 cherry-picked new features from the development branch were also included, but with the new symbol-versioning policy [1] afaiui this has changed, new features only can appear in *one* set of releases. (Unless there is an ABI break). > The second (related) question is that if we keep ABI fixed to the one > in 3.4.x, would it make sense to create a similar LTS release in the > future after 3.3.x is considered out of support? For Debian we currently have 3.5.8 in stable and 3.3.8 in oldstable, due to the timing of the respective releases we have not shipped 3.4.x in a release. cu Andreas [1] https://gitlab.com/gnutls/gnutls/blob/master/CONTRIBUTING.md#symbol-and-library-versioning -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/588#note_110534148 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Oct 22 08:38:40 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 22 Oct 2018 06:38:40 +0000 Subject: [gnutls-devel] GnuTLS | WIP: add support for 0-RTT (!775) In-Reply-To: References: Message-ID: 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: From gnutls-devel at lists.gnutls.org Mon Oct 22 08:58:38 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 22 Oct 2018 06:58:38 +0000 Subject: [gnutls-devel] GnuTLS | Clarify or improve our supported releases meaning (#588) In-Reply-To: References: Message-ID: >> @ametzler any thoughts on that? The situation we have now is that at >> any ABI breakage the previous release (e.g., 2.12.x, 3.3.x) became a >> de-facto LTS release as distributions like debian/rhel rely on it >> cannot move forward. So first question is, would you as debian >> maintainer be interested in a collaborative maintainership of a >> similar LTS branch in the future? Ie. bring the debian patches if any >> and thus also have a say on what other patches go in and on how long >> would that be open? (and such offer would be open to other >> distributions) Would that make sense from your perspective? > > to be honest I do not think there is a lot _I_ could contribute there. > (Coding skills) I do not think that could be a problem; although backporting of the features is necessary, the main aspect of such releases is agreeing on the policy to follow for it, and enforcing it. > Also we are quite limited in what changes are acceptable for Debian > stable - just fixing security issue and important bugs. This simply does > not match with how GnuTLS stable releases work, they include fixes for > minor issues, too. Up until 3.6 cherry-picked new features from the > development branch were also included, but with the new symbol-versioning > policy [1] afaiui this has changed, new features only can appear in _one_ > set of releases. (Unless there is an ABI break). Yes, the rules were pretty lax in the past, but were getting finer as I was getting more accustomed with the needs of an OS. What are the current drivers for the stable 3.3.x branches are apart from security issues: * Changes which improve the longevity of the release such as: - Fixing compatibility problems caused by that release (i.e., not harming a moving ecosystem) - that was also one of the reasons for the last 2.12.24 release. That includes certificate validation issues (e.g., false negatives). - Hardening when possible to (e.g., the enforcing of DER rules in 3.3.x branch, raising crypto bar by removing HMAC-SHA384 and SHA256 in 3.5.x) * Important functionality problems in the existing code base (e.g., infinite loop when pin-value was used, fixes on `gnutls_certificate_set_*key()` relating to freeing of mem, ALPN fixes). * New functionality - To load or generate files in common use (e.g., PKCS#8 enhancements), or support some hardware in common use (via PKCS#11 or TPM) - To enable some important software to run with the older version (e.g, the addition of `gnutls_x509_crt_set_issuer_unique_id` was driven by samba's needs) So I'm not sure which would fall under the important definition for Debian, but we could certainly agree on a common ground so that a future LTS release is not only more widely useful but also followed more widely. What do you think? >> The second (related) question is that if we keep ABI fixed to the one >> in 3.4.x, would it make sense to create a similar LTS release in the >> future after 3.3.x is considered out of support? > For Debian we currently have 3.5.8 in stable and 3.3.8 in oldstable, due > to the timing of the respective releases we have not shipped 3.4.x in > a release. Does this mean that de facto 3.5.8.x became an LTS release in debian? Would declaring 3.6.x or some other future version and LTS release, help to select which version to ship on the next stable and follow it (assuming there is an agreed common set of rules), or would you always prefer to be on the latest branch? For example if we had declared 3.3.x an LTS, would the previous stable had stayed with it, or would it had shipped the 3.5 branch? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/588#note_110623596 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Oct 22 09:03:13 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 22 Oct 2018 07:03:13 +0000 Subject: [gnutls-devel] GnuTLS | CTYPE-OPENPGP priority no longer recognized (#593) In-Reply-To: References: Message-ID: That's certainly something we should fix in 3.6.5. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/593#note_110624518 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Oct 22 11:00:44 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 22 Oct 2018 09:00:44 +0000 Subject: [gnutls-devel] GnuTLS | Cleanup and fixes (!779) In-Reply-To: References: Message-ID: Tom commented on a discussion on lib/cert-cred-x509.c: > */ > > static int > -certificate_credential_append_crt_list(gnutls_certificate_credentials_t res, > +certificate_credential_append_keypair(gnutls_certificate_credentials_t res, My rationale is the following. At first, this function only added a certificate list and was named correctly. A private key had to be added via a different function. Later on this function was modified such that it adds a certificate list and private key at once (which is good IMHO). Therefore I found it confusing that it is named as if it only adds a certificate list. A certificate contains a public key. As this function now adds both a public key and a private key (i.e. a keypair) I found that ...append_keypair would be a better name. Also, because we are going to use this function for adding raw public-keys too I think the better name of the two options is `certificate_credential_append_keypair`. What is your opinion? Shall I update the name or not? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/779#note_110665110 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Oct 22 12:01:09 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 22 Oct 2018 10:01:09 +0000 Subject: [gnutls-devel] GnuTLS | WIP: add support for 0-RTT (!775) In-Reply-To: References: Message-ID: Daiki Ueno 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); > + ... Those points sound reasonable to me. To provide an easy to use API while giving the user an opportunity to control the behavior, I would propose something like: - keep the `gnutls_record_{send,recv}_early_data` functions for stricter use cases - add new flags to `gnutls_record_{send,recv}2` which indicate automatic use of 0-RTT, say `GNUTLS_RECORD_FLAGS_USE_EARLY_DATA` -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/775#note_110688652 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Oct 22 21:30:09 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 22 Oct 2018 19:30:09 +0000 Subject: [gnutls-devel] GnuTLS | WIP: add support for 0-RTT (!775) In-Reply-To: References: Message-ID: 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: From gnutls-devel at lists.gnutls.org Mon Oct 22 21:34:44 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 22 Oct 2018 19:34:44 +0000 Subject: [gnutls-devel] GnuTLS | Cleanup and fixes (!779) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos commented on a discussion on lib/cert-cred-x509.c: > */ > > static int > -certificate_credential_append_crt_list(gnutls_certificate_credentials_t res, > +certificate_credential_append_keypair(gnutls_certificate_credentials_t res, No objection! -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/779#note_110859606 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Oct 22 21:34:45 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 22 Oct 2018 19:34:45 +0000 Subject: [gnutls-devel] GnuTLS | Cleanup and fixes (!779) In-Reply-To: References: Message-ID: All discussions on Merge Request !779 were resolved by Nikos Mavrogiannopoulos https://gitlab.com/gnutls/gnutls/merge_requests/779 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/779 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Oct 22 23:35:13 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 22 Oct 2018 21:35:13 +0000 Subject: [gnutls-devel] GnuTLS | WIP: RFC7250 Raw public keys (!650) In-Reply-To: References: Message-ID: Tom commented on a discussion on doc/cha-gtls-app.texi: > (i.e. different for the client than for the server). > > Currently supported types are: > -CTYPE-X509 or CTYPE-X.509. Catch all is CTYPE-ALL. > +CTYPE-X509 or CTYPE-X.509, CTYPE-RAWPK or CTYPE-RAWPUBKEY. Catch all is CTYPE-ALL. I propose the following. RFC7250 dictates that the certificate type negotiation extensions will only be sent when non-trivial cert types are set. That means other cert types than the default x.509 type. So this ensure safe default behaviour. We have currently implemented an extra check that toggle these extensions explicitly. This is not necessary anymore when we toggle specific certificate type related functionality via dedicated flags. For example, we can introduce a `GNUTLS_ENABLE_RAWPK` init flag that toggles whether raw public keys are enabled or not. Even if a user sets the rawpk cert type via the priority strings they will simply be ignored if the init flag is not set. That way the cert type extensions function according to spec but we still have the power to enable/disable specific functionality as an application developer. Looking at my next patch that introduces kerberos authentication we can do the same with a `GNUTLS_ENABLE_KDH` flag for example. To summarize, I would propose to drop the `GNUTLS_ENABLE_CERT_TYPE_NEG` flag in favor of dedicated functionality specific flags such as `GNUTLS_ENABLE_RAWPK` and such. These latter flags will then toggle which cert types will be allowed and which should be ignored during the handshake. What do you think about this? Also, can we remove the `GNUTLS_ENABLE_CERT_TYPE_NEG` flag and remain ABI compatible? Or don't we really care since this flag is so new that it is probably not being used ATM? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/650#note_110877089 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Oct 22 23:37:25 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 22 Oct 2018 21:37:25 +0000 Subject: [gnutls-devel] GnuTLS | Cleanup and fixes (!779) In-Reply-To: References: Message-ID: All discussions on Merge Request !779 were resolved by Tom https://gitlab.com/gnutls/gnutls/merge_requests/779 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/779 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Oct 23 08:08:40 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 23 Oct 2018 06:08:40 +0000 Subject: [gnutls-devel] GnuTLS | Cleanup and fixes (!779) In-Reply-To: References: Message-ID: Reassigned Merge Request 779 https://gitlab.com/gnutls/gnutls/merge_requests/779 Assignee changed to Tom -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/779 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Oct 23 08:10:03 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 23 Oct 2018 06:10:03 +0000 Subject: [gnutls-devel] GnuTLS | Cleanup and fixes (!779) In-Reply-To: References: Message-ID: Merge Request !779 was approved by Nikos Mavrogiannopoulos Merge Request url: https://gitlab.com/gnutls/gnutls/merge_requests/779 Project:Branches: Vrancken/gnutls-kdh:tmp_cleanup_and_fixes to gnutls/gnutls:master Author: Tom Assignee: Tom -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/779 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Oct 23 08:10:06 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 23 Oct 2018 06:10:06 +0000 Subject: [gnutls-devel] GnuTLS | Improve code readability by renaming struct fields of priority_st (#453) In-Reply-To: References: Message-ID: Issue was closed by Nikos Mavrogiannopoulos Issue #453: https://gitlab.com/gnutls/gnutls/issues/453 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/453 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Oct 23 08:10:07 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 23 Oct 2018 06:10:07 +0000 Subject: [gnutls-devel] GnuTLS | Cleanup and fixes (!779) In-Reply-To: References: Message-ID: Merge Request !779 was merged Merge Request url: https://gitlab.com/gnutls/gnutls/merge_requests/779 Project:Branches: Vrancken/gnutls-kdh:tmp_cleanup_and_fixes to gnutls/gnutls:master Author: Tom Assignee: Tom -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/779 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Oct 23 08:10:20 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 23 Oct 2018 06:10:20 +0000 Subject: [gnutls-devel] GnuTLS | Cleanup and fixes (!779) In-Reply-To: References: Message-ID: Thank you -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/779#note_110958732 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Oct 23 08:12:51 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 23 Oct 2018 06:12:51 +0000 Subject: [gnutls-devel] GnuTLS | p11tool: fix admin user PIN initialization (!776) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos commented on a discussion on src/common.c: > + size_t len; > + > + tmp = getpass(prompt); > + if (tmp == NULL) { > + pass[0] = 0; > + return; > + } > + > + len = strlen(tmp); > + if (len >= max_pass_size) { > + pass[0] = 0; > + return; > + } > + > + strcpy(pass, tmp); > + gnutls_memset(pass, 0, len); Just an omission. Fixed. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/776#note_110959305 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Oct 23 08:12:53 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 23 Oct 2018 06:12:53 +0000 Subject: [gnutls-devel] GnuTLS | p11tool: fix admin user PIN initialization (!776) In-Reply-To: References: Message-ID: All discussions on Merge Request !776 were resolved by Nikos Mavrogiannopoulos https://gitlab.com/gnutls/gnutls/merge_requests/776 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/776 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Oct 23 08:15:34 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 23 Oct 2018 06:15:34 +0000 Subject: [gnutls-devel] GnuTLS | WIP: RFC7250 Raw public keys (!650) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos commented on a discussion on doc/cha-gtls-app.texi: > (i.e. different for the client than for the server). > > Currently supported types are: > -CTYPE-X509 or CTYPE-X.509. Catch all is CTYPE-ALL. > +CTYPE-X509 or CTYPE-X.509, CTYPE-RAWPK or CTYPE-RAWPUBKEY. Catch all is CTYPE-ALL. It makes sense to me. Yes, the ABI is unaffected by this flag so we can remove it safely. To be 100% sure we can keep it defined but to zero (no-op). -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/650#note_110959918 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Oct 23 08:17:49 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 23 Oct 2018 06:17:49 +0000 Subject: [gnutls-devel] GnuTLS | WIP: RFC7250 Raw public keys (!650) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos commented on a discussion on lib/includes/gnutls/gnutls.h.in: > unsigned idx, > gnutls_datum_t * response); > > +/* RAW public key functions (RFC7250) */ > +#ifdef ENABLE_RAWPK > +int gnutls_certificate_set_rawpk_keypair(gnutls_certificate_credentials_t cred, > + const gnutls_pubkey_t subjectPublicKeyInfo, > + const gnutls_privkey_t key); > + > +int gnutls_certificate_set_rawpk_keypair_raw(gnutls_certificate_credentials_t cred, Which ones do you mean specifically? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/650#note_110960781 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Oct 23 15:22:10 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 23 Oct 2018 13:22:10 +0000 Subject: [gnutls-devel] GnuTLS | fips140: aligned code with documentation (!781) References: Message-ID: New Merge Request !781 https://gitlab.com/gnutls/gnutls/merge_requests/781 Branches: tmp-fix-fips-mode to master Author: Nikos Mavrogiannopoulos Assignee: Approvers: Simon Josefsson, Dmitry Eremin-Solenikov, Hubert Kario, Tim R?hsen, Andreas Metzler, Daiki Ueno, Tom, Ander Juaristi, Tom?? Mr?z, Anderson Sasaki and GnuTLS devel mailing list That is introduced the documented but unimplemented macros GNUTLS_FIPS140_SET_RELAX_MODE() and GNUTLS_FIPS140_SET_STRICT_MODE(). ## Checklist * [x] Code modified for feature * [x] Test suite updated with functionality tests * [x] Documentation updated ## Reviewer's checklist: * [ ] Any issues marked for closing are addressed * [ ] There is a test suite reasonably covering new functionality or modifications * [ ] Function naming, parameters, return values, types, etc., are consistent and according to `CONTRIBUTION.md` * [ ] This feature/change has adequate documentation added * [ ] No obvious mistakes in the code -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/781 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Oct 23 15:25:30 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 23 Oct 2018 13:25:30 +0000 Subject: [gnutls-devel] GnuTLS | fips140: aligned code with documentation (!781) In-Reply-To: References: Message-ID: LGTM! -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/781#note_111133029 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Oct 23 16:31:28 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 23 Oct 2018 14:31:28 +0000 Subject: [gnutls-devel] GnuTLS | WIP: implement anti-replay mechanism (!782) References: Message-ID: New Merge Request !782 https://gitlab.com/gnutls/gnutls/merge_requests/782 Branches: tmp-anti-replay to tmp-0rtt Author: Daiki Ueno Assignee: Approvers: Simon Josefsson, Nikos Mavrogiannopoulos, Dmitry Eremin-Solenikov, Hubert Kario, Tim R?hsen, Andreas Metzler, Tom, Ander Juaristi, Tom?? Mr?z, Anderson Sasaki and GnuTLS devel mailing list This implements anti-replay protection using ClientHello recording described in [RFC8446](https://tools.ietf.org/html/rfc8446#section-8.2). ## Checklist * [x] Code modified for feature * [x] Test suite updated with functionality tests * [x] Test suite updated with negative tests * [x] Documentation updated ## Reviewer's checklist: * [ ] Any issues marked for closing are addressed * [ ] There is a test suite reasonably covering new functionality or modifications * [ ] Function naming, parameters, return values, types, etc., are consistent and according to `CONTRIBUTION.md` * [ ] This feature/change has adequate documentation added * [ ] No obvious mistakes in the code -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/782 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Oct 23 20:06:27 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 23 Oct 2018 18:06:27 +0000 Subject: [gnutls-devel] GnuTLS | gnutls_priority_set: do not override the version after handshake is complete (!777) In-Reply-To: References: Message-ID: Tom commented on a discussion on lib/priority.c: > session->internals.priorities = priority; > gnutls_atomic_increment(&priority->usage_cnt); > > - /* set the current version to the first in the chain. > - * This will be overridden later. > - */ > + /* set the current version to the first in the chain, if that's > + * the call before the initial handshake. This will be overridden by > + * the handshake call. */ I would still move the if-statement at line 601 up (after line 587) to be able to return early. Also the condition at line 592 excludes the one at line 601. Don't you think that's better? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/777#note_111220066 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Oct 23 20:43:09 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 23 Oct 2018 18:43:09 +0000 Subject: [gnutls-devel] GnuTLS | fips140: aligned code with documentation (!781) In-Reply-To: References: Message-ID: Thank you. I renamed `GNUTLS_FIPS140_SET_RELAX_MODE` to `GNUTLS_FIPS140_SET_LAX_MODE` so that it is in par with the `GNUTLS_FIPS140_LAX` mode. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/781#note_111228048 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Oct 23 20:43:18 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 23 Oct 2018 18:43:18 +0000 Subject: [gnutls-devel] GnuTLS | fips140: aligned code with documentation (!781) In-Reply-To: References: Message-ID: Reassigned Merge Request 781 https://gitlab.com/gnutls/gnutls/merge_requests/781 Assignee changed to Nikos Mavrogiannopoulos -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/781 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Oct 23 21:01:41 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 23 Oct 2018 19:01:41 +0000 Subject: [gnutls-devel] GnuTLS | gnutls_priority_set: do not override the version after handshake is complete (!777) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos commented on a discussion on lib/priority.c: > session->internals.priorities = priority; > gnutls_atomic_increment(&priority->usage_cnt); > > - /* set the current version to the first in the chain. > - * This will be overridden later. > - */ > + /* set the current version to the first in the chain, if that's > + * the call before the initial handshake. This will be overridden by > + * the handshake call. */ Indeed. It can further be simplified. Sent an updated version. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/777#note_111230752 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Oct 24 10:41:51 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 24 Oct 2018 08:41:51 +0000 Subject: [gnutls-devel] GnuTLS | p11tool: fix admin user PIN initialization (!776) In-Reply-To: References: Message-ID: Hubert Kario started a new discussion on src/common.c: > + } > + > + len = strlen(tmp); > + if (len >= max_pass_size) { > + gnutls_memset(tmp, 0, len); > + pass[0] = 0; > + return; > + } > + > + strcpy(pass, tmp); > + gnutls_memset(tmp, 0, len); > + > + return; > +} > + > +/* error is an empty string */ same here -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/776#note_111351000 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Oct 24 10:41:53 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 24 Oct 2018 08:41:53 +0000 Subject: [gnutls-devel] GnuTLS | p11tool: fix admin user PIN initialization (!776) In-Reply-To: References: Message-ID: Hubert Kario started a new discussion on src/common.c: > return 0; > } > > +/* error is an empty password */ what `error`? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/776#note_111351002 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Oct 24 10:41:51 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 24 Oct 2018 08:41:51 +0000 Subject: [gnutls-devel] GnuTLS | p11tool: fix admin user PIN initialization (!776) In-Reply-To: References: Message-ID: Hubert Kario started a new discussion on tests/testpkcs11.sh: > + if test $? != 0; then > + echo failed > + exit_error > + fi > + echo ok > + > + echo -n "* Re-setting user PIN... " > + export GNUTLS_PIN="${UPIN}" > + ${P11TOOL} ${ADDITIONAL_PARAM} --login --initialize-pin "${token}" >>"${LOGFILE}" 2>&1 > + if test $? != 0; then > + echo failed > + exit_error > + fi > + > + echo ok > +} test case checking what happens if the pin is longer than 64 characters is missing -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/776#note_111350998 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Oct 24 10:43:52 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 24 Oct 2018 08:43:52 +0000 Subject: [gnutls-devel] GnuTLS | p11tool: fix admin user PIN initialization (!776) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos commented on a discussion on src/common.c: > + } > + > + len = strlen(tmp); > + if (len >= max_pass_size) { > + gnutls_memset(tmp, 0, len); > + pass[0] = 0; > + return; > + } > + > + strcpy(pass, tmp); > + gnutls_memset(tmp, 0, len); > + > + return; > +} > + > +/* error is an empty string */ Would the text `error is indicated via an empty string` be more clear? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/776#note_111357352 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Oct 24 10:44:46 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 24 Oct 2018 08:44:46 +0000 Subject: [gnutls-devel] GnuTLS | p11tool: fix admin user PIN initialization (!776) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos commented on a discussion on tests/testpkcs11.sh: > + if test $? != 0; then > + echo failed > + exit_error > + fi > + echo ok > + > + echo -n "* Re-setting user PIN... " > + export GNUTLS_PIN="${UPIN}" > + ${P11TOOL} ${ADDITIONAL_PARAM} --login --initialize-pin "${token}" >>"${LOGFILE}" 2>&1 > + if test $? != 0; then > + echo failed > + exit_error > + fi > + > + echo ok > +} do you mean testing whether 64 chars work, or testing that over 64 chars fails? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/776#note_111361118 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Oct 24 11:03:10 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 24 Oct 2018 09:03:10 +0000 Subject: [gnutls-devel] GnuTLS | p11tool: fix admin user PIN initialization (!776) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos commented on a discussion on tests/testpkcs11.sh: > + if test $? != 0; then > + echo failed > + exit_error > + fi > + echo ok > + > + echo -n "* Re-setting user PIN... " > + export GNUTLS_PIN="${UPIN}" > + ${P11TOOL} ${ADDITIONAL_PARAM} --login --initialize-pin "${token}" >>"${LOGFILE}" 2>&1 > + if test $? != 0; then > + echo failed > + exit_error > + fi > + > + echo ok > +} Actually, adding tests for these, uncovered that the real limit is imposed by the lib. Updated and added test cases to test the maximum supported chars and max + 1 more. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/776#note_111383458 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Oct 24 12:37:34 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 24 Oct 2018 10:37:34 +0000 Subject: [gnutls-devel] GnuTLS | p11tool: fix admin user PIN initialization (!776) In-Reply-To: References: Message-ID: Hubert Kario commented on a discussion on tests/testpkcs11.sh: > + if test $? != 0; then > + echo failed > + exit_error > + fi > + echo ok > + > + echo -n "* Re-setting user PIN... " > + export GNUTLS_PIN="${UPIN}" > + ${P11TOOL} ${ADDITIONAL_PARAM} --login --initialize-pin "${token}" >>"${LOGFILE}" 2>&1 > + if test $? != 0; then > + echo failed > + exit_error > + fi > + > + echo ok > +} the latter, that over 64 chars fails -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/776#note_111422512 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Oct 24 12:37:53 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 24 Oct 2018 10:37:53 +0000 Subject: [gnutls-devel] GnuTLS | p11tool: fix admin user PIN initialization (!776) In-Reply-To: References: Message-ID: Hubert Kario commented on a discussion on src/common.c: > + } > + > + len = strlen(tmp); > + if (len >= max_pass_size) { > + gnutls_memset(tmp, 0, len); > + pass[0] = 0; > + return; > + } > + > + strcpy(pass, tmp); > + gnutls_memset(tmp, 0, len); > + > + return; > +} > + > +/* error is an empty string */ yes, it would -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/776#note_111422598 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Oct 24 12:39:58 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 24 Oct 2018 10:39:58 +0000 Subject: [gnutls-devel] GnuTLS | p11tool: fix admin user PIN initialization (!776) In-Reply-To: References: Message-ID: Merge Request !776 was approved by Hubert Kario Merge Request url: https://gitlab.com/gnutls/gnutls/merge_requests/776 Branches: tmp-initialize-so-pin-fix to master Author: Nikos Mavrogiannopoulos Assignee: -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/776 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Oct 24 12:50:41 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 24 Oct 2018 10:50:41 +0000 Subject: [gnutls-devel] GnuTLS | p11tool: fix admin user PIN initialization (!776) In-Reply-To: References: Message-ID: Reassigned Merge Request 776 https://gitlab.com/gnutls/gnutls/merge_requests/776 Assignee changed to Nikos Mavrogiannopoulos -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/776 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Oct 24 12:51:03 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 24 Oct 2018 10:51:03 +0000 Subject: [gnutls-devel] GnuTLS | p11tool: fix admin user PIN initialization (!776) In-Reply-To: References: Message-ID: All discussions on Merge Request !776 were resolved by Nikos Mavrogiannopoulos https://gitlab.com/gnutls/gnutls/merge_requests/776 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/776 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Oct 24 12:51:10 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 24 Oct 2018 10:51:10 +0000 Subject: [gnutls-devel] GnuTLS | p11tool: fix admin user PIN initialization (!776) In-Reply-To: References: Message-ID: Merge Request !776 was merged Merge Request url: https://gitlab.com/gnutls/gnutls/merge_requests/776 Branches: tmp-initialize-so-pin-fix to master Author: Nikos Mavrogiannopoulos Assignee: Nikos Mavrogiannopoulos -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/776 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Oct 24 12:51:10 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 24 Oct 2018 10:51:10 +0000 Subject: [gnutls-devel] GnuTLS | p11tool --initialize-so-pin does not change so pin but initializes user pin (#561) In-Reply-To: References: Message-ID: Issue was closed by Nikos Mavrogiannopoulos Issue #561: https://gitlab.com/gnutls/gnutls/issues/561 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/561 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Oct 24 13:04:26 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 24 Oct 2018 11:04:26 +0000 Subject: [gnutls-devel] GnuTLS | fips140: aligned code with documentation (!781) In-Reply-To: References: Message-ID: Merge Request !781 was approved by Anderson Sasaki Merge Request url: https://gitlab.com/gnutls/gnutls/merge_requests/781 Branches: tmp-fix-fips-mode to master Author: Nikos Mavrogiannopoulos Assignee: Nikos Mavrogiannopoulos -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/781 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Oct 24 13:10:03 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 24 Oct 2018 11:10:03 +0000 Subject: [gnutls-devel] GnuTLS | fips140: aligned code with documentation (!781) In-Reply-To: References: Message-ID: - [x] Any issues marked for closing are addressed - [x] There is a test suite reasonably covering new functionality or modifications - [x] Function naming, parameters, return values, types, etc., are consistent and according to `CONTRIBUTION.md` - [x] This feature/change has adequate documentation added - [x] No obvious mistakes in the code LGTM -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/781#note_111430038 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Oct 24 13:16:27 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 24 Oct 2018 11:16:27 +0000 Subject: [gnutls-devel] GnuTLS | fips140: aligned code with documentation (!781) In-Reply-To: References: Message-ID: Merge Request !781 was merged Merge Request url: https://gitlab.com/gnutls/gnutls/merge_requests/781 Branches: tmp-fix-fips-mode to master Author: Nikos Mavrogiannopoulos Assignee: Nikos Mavrogiannopoulos -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/781 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Oct 24 13:16:40 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 24 Oct 2018 11:16:40 +0000 Subject: [gnutls-devel] GnuTLS | fips140: aligned code with documentation (!781) In-Reply-To: References: Message-ID: Thank you! -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/781#note_111431661 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Oct 24 20:01:55 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 24 Oct 2018 18:01:55 +0000 Subject: [gnutls-devel] GnuTLS | WIP: Add support for AES CFB8 cipher (!783) References: Message-ID: New Merge Request !783 https://gitlab.com/gnutls/gnutls/merge_requests/783 Project:Branches: simo5/gnutls:cfb8 to gnutls/gnutls:master Author: Simo Sorce Assignee: This is mostly backporting the CFB8 code in nettle's master tree so we can use it also when compiled against 3.4 Fixes #357 ## Checklist * [X] Code modified for feature * [ ] Test suite updated with functionality tests * [ ] Test suite updated with negative tests * [ ] Documentation updated ## Reviewer's checklist: * [ ] Any issues marked for closing are addressed * [ ] There is a test suite reasonably covering new functionality or modifications * [ ] Function naming, parameters, return values, types, etc., are consistent and according to `CONTRIBUTION.md` * [ ] This feature/change has adequate documentation added * [ ] No obvious mistakes in the code -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/783 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Oct 24 21:09:29 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 24 Oct 2018 19:09:29 +0000 Subject: [gnutls-devel] GnuTLS | WIP: Add support for AES CFB8 cipher (!783) In-Reply-To: References: Message-ID: Dmitry Eremin-Solenikov started a new discussion on configure.ac: > fi > AM_CONDITIONAL(ENABLE_NON_SUITEB_CURVES, test "$enable_non_suiteb" = "yes") > > +# Check if nettle has CFB8 support > +save_LIBS=$LIBS > +LIBS="$LIBS $NETTLE_LIBS" > +AC_CHECK_FUNCS(cfb8_encrypt) > +LIBS=$save_LIBS Well, since cfb8 will be a part of Nettle 3.5, you can just check library version here. See 803f2e10748995c6386bb54cad4ceaca6bd1c1b3 for an example. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/783#note_111609947 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Oct 24 21:09:29 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 24 Oct 2018 19:09:29 +0000 Subject: [gnutls-devel] GnuTLS | WIP: Add support for AES CFB8 cipher (!783) In-Reply-To: References: Message-ID: Dmitry Eremin-Solenikov started a new discussion on lib/nettle/cipher.c: > #include > #include > #include > -#include > +#include "cfb8.h" I'd prefer to see `#if` here, so that it would be cleaner that we can drop those files after starting to require later Nettle version. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/783#note_111609948 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Oct 24 21:43:43 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 24 Oct 2018 19:43:43 +0000 Subject: [gnutls-devel] GnuTLS | WIP: Add support for AES CFB8 cipher (!783) In-Reply-To: References: Message-ID: Simo Sorce commented on a discussion on configure.ac: > fi > AM_CONDITIONAL(ENABLE_NON_SUITEB_CURVES, test "$enable_non_suiteb" = "yes") > > +# Check if nettle has CFB8 support > +save_LIBS=$LIBS > +LIBS="$LIBS $NETTLE_LIBS" > +AC_CHECK_FUNCS(cfb8_encrypt) > +LIBS=$save_LIBS Explicit function checks is more robust on platforms where people may backport the same function to nettle 3.4, the problem otherwise is clash of symbols -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/783#note_111619351 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Oct 24 21:44:26 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 24 Oct 2018 19:44:26 +0000 Subject: [gnutls-devel] GnuTLS | WIP: Add support for AES CFB8 cipher (!783) In-Reply-To: References: Message-ID: Simo Sorce commented on a discussion on lib/nettle/cipher.c: > #include > #include > #include > -#include > +#include "cfb8.h" The ifdef is within cfb8.h, should I bring it out, or keep in both places ? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/783#note_111619450 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Oct 24 21:50:47 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 24 Oct 2018 19:50:47 +0000 Subject: [gnutls-devel] GnuTLS | WIP: Add support for AES CFB8 cipher (!783) In-Reply-To: References: Message-ID: Simo Sorce commented on a discussion on configure.ac: > fi > AM_CONDITIONAL(ENABLE_NON_SUITEB_CURVES, test "$enable_non_suiteb" = "yes") > > +# Check if nettle has CFB8 support > +save_LIBS=$LIBS > +LIBS="$LIBS $NETTLE_LIBS" > +AC_CHECK_FUNCS(cfb8_encrypt) > +LIBS=$save_LIBS Which reminds me I need to change this to actually check for nettle_cfb8_encrypt -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/783#note_111620730 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Oct 24 21:58:59 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 24 Oct 2018 19:58:59 +0000 Subject: [gnutls-devel] GnuTLS | WIP: Add support for AES CFB8 cipher (!783) In-Reply-To: References: Message-ID: Dmitry Eremin-Solenikov commented on a discussion on configure.ac: > fi > AM_CONDITIONAL(ENABLE_NON_SUITEB_CURVES, test "$enable_non_suiteb" = "yes") > > +# Check if nettle has CFB8 support > +save_LIBS=$LIBS > +LIBS="$LIBS $NETTLE_LIBS" > +AC_CHECK_FUNCS(cfb8_encrypt) > +LIBS=$save_LIBS For gost functions, which are submitted to Nettle, but not yet merged, I rewrote symbol renaming to use `_gnutls_` prefix instead of `nettle_` one. I'd suggest to do the same. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/783#note_111622648 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Oct 24 22:00:02 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 24 Oct 2018 20:00:02 +0000 Subject: [gnutls-devel] GnuTLS | WIP: Add support for AES CFB8 cipher (!783) In-Reply-To: References: Message-ID: Dmitry Eremin-Solenikov commented on a discussion on lib/nettle/cipher.c: > #include > #include > #include > -#include > +#include "cfb8.h" I think it's easier to have `cfb8.c`/`.h` with minimal changes compared to Nettle original (maybe except renaming changes) and to have `#ifdef` here. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/783#note_111622811 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Oct 24 22:00:21 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 24 Oct 2018 20:00:21 +0000 Subject: [gnutls-devel] GnuTLS | WIP: Add support for AES CFB8 cipher (!783) In-Reply-To: References: Message-ID: Simo Sorce commented on a discussion on configure.ac: > fi > AM_CONDITIONAL(ENABLE_NON_SUITEB_CURVES, test "$enable_non_suiteb" = "yes") > > +# Check if nettle has CFB8 support > +save_LIBS=$LIBS > +LIBS="$LIBS $NETTLE_LIBS" > +AC_CHECK_FUNCS(cfb8_encrypt) > +LIBS=$save_LIBS I already have it, check latest pushed code -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/783#note_111622848 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Oct 24 22:01:26 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 24 Oct 2018 20:01:26 +0000 Subject: [gnutls-devel] GnuTLS | WIP: Add support for AES CFB8 cipher (!783) In-Reply-To: References: Message-ID: Simo Sorce commented on a discussion on lib/nettle/cipher.c: > #include > #include > #include > -#include > +#include "cfb8.h" The code is identical, but I only have the additions as nettle has both cfb and cfb8 in the same cfb.[c|h] files. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/783#note_111623144 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Oct 24 22:24:11 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 24 Oct 2018 20:24:11 +0000 Subject: [gnutls-devel] GnuTLS | WIP: Add support for AES CFB8 cipher (!783) In-Reply-To: References: Message-ID: Simo Sorce commented on a discussion on configure.ac: > fi > AM_CONDITIONAL(ENABLE_NON_SUITEB_CURVES, test "$enable_non_suiteb" = "yes") > > +# Check if nettle has CFB8 support > +save_LIBS=$LIBS > +LIBS="$LIBS $NETTLE_LIBS" > +AC_CHECK_FUNCS(cfb8_encrypt) > +LIBS=$save_LIBS So I added a temp commit to show the difference between adding the ifdef in lib/nettle/cipher.c or keeping it in cfb8.h Let me know which is better and I'll rebase the commit into the right one or away -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/783#note_111635609 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Oct 24 23:23:39 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 24 Oct 2018 21:23:39 +0000 Subject: [gnutls-devel] GnuTLS | WIP: Add support for AES CFB8 cipher (!783) In-Reply-To: References: Message-ID: Dmitry Eremin-Solenikov commented on a discussion on configure.ac: > fi > AM_CONDITIONAL(ENABLE_NON_SUITEB_CURVES, test "$enable_non_suiteb" = "yes") > > +# Check if nettle has CFB8 support > +save_LIBS=$LIBS > +LIBS="$LIBS $NETTLE_LIBS" > +AC_CHECK_FUNCS(cfb8_encrypt) > +LIBS=$save_LIBS I prefer the version with temp commit. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/783#note_111662162 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Oct 24 23:57:41 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 24 Oct 2018 21:57:41 +0000 Subject: [gnutls-devel] GnuTLS | WIP: Add support for AES CFB8 cipher (!783) In-Reply-To: References: Message-ID: Simo Sorce commented on a discussion on configure.ac: > fi > AM_CONDITIONAL(ENABLE_NON_SUITEB_CURVES, test "$enable_non_suiteb" = "yes") > > +# Check if nettle has CFB8 support > +save_LIBS=$LIBS > +LIBS="$LIBS $NETTLE_LIBS" > +AC_CHECK_FUNCS(cfb8_encrypt) > +LIBS=$save_LIBS Ok I squashed that patch in the second commit, rebased on master and pushed the tree. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/783#note_111667296 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Oct 24 23:57:52 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 24 Oct 2018 21:57:52 +0000 Subject: [gnutls-devel] GnuTLS | WIP: Add support for AES CFB8 cipher (!783) In-Reply-To: References: Message-ID: All discussions on Merge Request !783 were resolved by Simo Sorce https://gitlab.com/gnutls/gnutls/merge_requests/783 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/783 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Thu Oct 25 00:00:44 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 24 Oct 2018 22:00:44 +0000 Subject: [gnutls-devel] GnuTLS | WIP: Add support for AES CFB8 cipher (!783) In-Reply-To: References: Message-ID: Simo Sorce started a new discussion: I do not think we have docs that cover individual ciphers explicitly and negative tests are note necessary here (proper testing is handled in nettle), should I just remove the last 2 checkboxes from the decription text ? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/783#note_111667654 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Thu Oct 25 00:01:51 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 24 Oct 2018 22:01:51 +0000 Subject: [gnutls-devel] GnuTLS | WIP: Add support for AES CFB8 cipher (!783) In-Reply-To: References: Message-ID: Dmitry Eremin-Solenikov started a new discussion on lib/crypto-selftests.c: > }, > }; > > +const struct cipher_vectors_st aes128_cfb8_vectors[] = { Could you please add a note, mentioning the source for test vectors (like NIST SP800-38a). -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/783#note_111667875 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Thu Oct 25 00:02:29 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 24 Oct 2018 22:02:29 +0000 Subject: [gnutls-devel] GnuTLS | WIP: Add support for AES CFB8 cipher (!783) In-Reply-To: References: Message-ID: Dmitry Eremin-Solenikov started a new discussion on configure.ac: > fi > AM_CONDITIONAL(ENABLE_NON_SUITEB_CURVES, test "$enable_non_suiteb" = "yes") > > +# Check if nettle has CFB8 support > +save_LIBS=$LIBS > +LIBS="$LIBS $NETTLE_LIBS" > +AC_CHECK_FUNCS(nettle_cfb8_encrypt) > +LIBS=$save_LIBS > + I'm still unsure about explicit check vs Nettle version check here. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/783#note_111667932 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Thu Oct 25 00:04:45 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 24 Oct 2018 22:04:45 +0000 Subject: [gnutls-devel] GnuTLS | WIP: Add support for AES CFB8 cipher (!783) In-Reply-To: References: Message-ID: Dmitry Eremin-Solenikov commented on a discussion: Yes, I think you can just remove those two. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/783#note_111668250 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Thu Oct 25 08:31:13 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 25 Oct 2018 06:31:13 +0000 Subject: [gnutls-devel] GnuTLS | gnutls-cli: reduce printed session information (!784) References: Message-ID: New Merge Request !784 https://gitlab.com/gnutls/gnutls/merge_requests/784 Branches: tmp-cli-reduce-output to master Author: Nikos Mavrogiannopoulos Assignee: Approvers: Simon Josefsson, Dmitry Eremin-Solenikov, Hubert Kario, Tim R?hsen, Andreas Metzler, Daiki Ueno, Tom, Ander Juaristi, Tom?? Mr?z, Anderson Sasaki and GnuTLS devel mailing list When connecting to a server we were printing a lot of duplicate information that was already part of the "Description" string. No longer print that information unless --verbose is given. ## Checklist * [x] Code modified for feature * [ ] Test suite updated with functionality tests * [ ] Test suite updated with negative tests * [ ] Documentation updated ## Reviewer's checklist: * [ ] Any issues marked for closing are addressed * [ ] There is a test suite reasonably covering new functionality or modifications * [ ] Function naming, parameters, return values, types, etc., are consistent and according to `CONTRIBUTION.md` * [ ] This feature/change has adequate documentation added * [ ] No obvious mistakes in the code -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/784 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Thu Oct 25 09:31:50 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 25 Oct 2018 07:31:50 +0000 Subject: [gnutls-devel] coverage | Makefile: use gcc-7 for coverage (!2) References: Message-ID: New Merge Request !2 https://gitlab.com/gnutls/coverage/merge_requests/2 Branches: tmp-fix-coverage to master Author: Nikos Mavrogiannopoulos Assignee: Resolves: gnutls/gnutls#550 Signed-off-by: Nikos Mavrogiannopoulos -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/coverage/merge_requests/2 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Thu Oct 25 09:33:21 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 25 Oct 2018 07:33:21 +0000 Subject: [gnutls-devel] GnuTLS | CTYPE-OPENPGP priority no longer recognized (#593) In-Reply-To: References: Message-ID: @Vrancken would you like to check this? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/593#note_111723388 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Thu Oct 25 10:12:30 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 25 Oct 2018 08:12:30 +0000 Subject: [gnutls-devel] GnuTLS | gnutls_priority_set: do not override the version after handshake is complete (!777) In-Reply-To: References: Message-ID: Tom started a new discussion on lib/priority.c: > } I don't think that this is the correct error code to return here. We already concluded that there are priorities set because we pass the sanity tests above. Maybe we can just use the returned error code from the function `_gnutls_set_current_version()` (i.e. `GNUTLS_E_UNSUPPORTED_VERSION_PACKET`). What do you think? e.g. ``` ret = _gnutls_set_current_version(...); if (ret < 0) return gnutls_assert_val(ret); ``` -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/777#note_111732493 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Thu Oct 25 10:19:58 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 25 Oct 2018 08:19:58 +0000 Subject: [gnutls-devel] GnuTLS | gnutls_priority_set: do not override the version after handshake is complete (!777) In-Reply-To: References: Message-ID: Tom commented on a discussion on lib/priority.c: > session->internals.priorities = priority; > gnutls_atomic_increment(&priority->usage_cnt); > > - /* set the current version to the first in the chain. > - * This will be overridden later. > - */ > + /* set the current version to the first in the chain, if that's > + * the call before the initial handshake. This will be overridden by > + * the handshake call. */ That looks good :) -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/777#note_111734485 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Thu Oct 25 11:52:05 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 25 Oct 2018 09:52:05 +0000 Subject: [gnutls-devel] GnuTLS | gnutls_priority_set: do not override the version after handshake is complete (!777) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos commented on a discussion on lib/priority.c: > } In the documentation before the `GNUTLS_E_NO_PRIORITIES_WERE_SET` is defined to be returned when the existing priority structure was not modified/updated. I think what you mention above fits this definition. Is your suggestion to change it? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/777#note_111763783 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Thu Oct 25 14:11:32 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 25 Oct 2018 12:11:32 +0000 Subject: [gnutls-devel] GnuTLS | TLS 1.3: calculate ticket age based on higher precision time (!785) References: Message-ID: New Merge Request !785 https://gitlab.com/gnutls/gnutls/merge_requests/785 Branches: tmp-session-ticket-timestamp to master Author: Daiki Ueno Assignee: Approvers: Simon Josefsson, Nikos Mavrogiannopoulos, Dmitry Eremin-Solenikov, Hubert Kario, Tim R?hsen, Andreas Metzler, Tom, Ander Juaristi, Tom?? Mr?z, Anderson Sasaki and GnuTLS devel mailing list Previously, the client's view of ticket age was calculated from the time in seconds, something like: ``` time_t cur_time = gnutls_time(0); (cur_time - ticket->timestamp) * 1000; ``` while the RFC 8446 explicitly says that ticket ages are in milliseconds. This prevents implementing freshness checks correctly as in !782. This MR consists of 3 parts: - use `struct timespec` for ticket arrival time, which is the baseline of ticket age - add a means to replace `gettime()` function extensively used in the library for testing - other refactoring and fixes ## Checklist * [ ] Code modified for feature * [ ] Test suite updated with functionality tests * [ ] Test suite updated with negative tests * [ ] Documentation updated ## Reviewer's checklist: * [ ] Any issues marked for closing are addressed * [ ] There is a test suite reasonably covering new functionality or modifications * [ ] Function naming, parameters, return values, types, etc., are consistent and according to `CONTRIBUTION.md` * [ ] This feature/change has adequate documentation added * [ ] No obvious mistakes in the code -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/785 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Thu Oct 25 14:25:54 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 25 Oct 2018 12:25:54 +0000 Subject: [gnutls-devel] GnuTLS | WIP: Add support for AES CFB8 cipher (!783) In-Reply-To: References: Message-ID: Simo Sorce commented on a discussion on lib/crypto-selftests.c: > }, > }; > > +const struct cipher_vectors_st aes128_cfb8_vectors[] = { will do -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/783#note_111806139 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Thu Oct 25 14:29:35 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 25 Oct 2018 12:29:35 +0000 Subject: [gnutls-devel] GnuTLS | WIP: Add support for AES CFB8 cipher (!783) In-Reply-To: References: Message-ID: Simo Sorce commented on a discussion on configure.ac: > fi > AM_CONDITIONAL(ENABLE_NON_SUITEB_CURVES, test "$enable_non_suiteb" = "yes") > > +# Check if nettle has CFB8 support > +save_LIBS=$LIBS > +LIBS="$LIBS $NETTLE_LIBS" > +AC_CHECK_FUNCS(nettle_cfb8_encrypt) > +LIBS=$save_LIBS > + I have a strong preference for precise checks, what's the issue in checking exactly for the function we need ? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/783#note_111807248 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Thu Oct 25 16:05:26 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 25 Oct 2018 14:05:26 +0000 Subject: [gnutls-devel] GnuTLS | add support for 0-RTT (!775) In-Reply-To: References: Message-ID: Daiki Ueno 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 receiving size, do you see an advantage in that separation in practice? RFC 8470 actually suggests that the server could defer processing of early data only after the handshake is completed, to mitigate the replay risks in case the anti-replay measure doesn't work. In any case, I think the current API is sufficient to cover both use-cases; maybe later, we could add convenient API on top of it. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/775#note_111837959 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Thu Oct 25 16:05:48 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 25 Oct 2018 14:05:48 +0000 Subject: [gnutls-devel] GnuTLS | add support for 0-RTT (!775) In-Reply-To: References: Message-ID: All discussions on Merge Request !775 were resolved by Daiki Ueno https://gitlab.com/gnutls/gnutls/merge_requests/775 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/775 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Thu Oct 25 16:29:15 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 25 Oct 2018 14:29:15 +0000 Subject: [gnutls-devel] GnuTLS | WIP: Add support for AES CFB8 cipher (!783) In-Reply-To: References: Message-ID: All discussions on Merge Request !783 were resolved by Dmitry Eremin-Solenikov https://gitlab.com/gnutls/gnutls/merge_requests/783 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/783 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Thu Oct 25 16:29:15 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 25 Oct 2018 14:29:15 +0000 Subject: [gnutls-devel] GnuTLS | WIP: Add support for AES CFB8 cipher (!783) In-Reply-To: References: Message-ID: Dmitry Eremin-Solenikov commented on a discussion on configure.ac: > fi > AM_CONDITIONAL(ENABLE_NON_SUITEB_CURVES, test "$enable_non_suiteb" = "yes") > > +# Check if nettle has CFB8 support > +save_LIBS=$LIBS > +LIBS="$LIBS $NETTLE_LIBS" > +AC_CHECK_FUNCS(nettle_cfb8_encrypt) > +LIBS=$save_LIBS > + Fine then. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/783#note_111859796 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Thu Oct 25 16:29:49 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 25 Oct 2018 14:29:49 +0000 Subject: [gnutls-devel] GnuTLS | WIP: Add support for AES CFB8 cipher (!783) In-Reply-To: References: Message-ID: @simo5 could you please fix FIPS test failure (see Pipeline build failure). Then the MR will be ready from my point of view. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/783#note_111859977 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Thu Oct 25 16:54:35 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 25 Oct 2018 14:54:35 +0000 Subject: [gnutls-devel] GnuTLS | WIP: Add support for AES CFB8 cipher (!783) In-Reply-To: References: Message-ID: Yes, absolutely, was planning to look into it this morning, but had other priorities. I should have it done by today. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/783#note_111867936 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Thu Oct 25 19:18:10 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 25 Oct 2018 17:18:10 +0000 Subject: [gnutls-devel] GnuTLS | Add support for AES CFB8 cipher (!783) In-Reply-To: References: Message-ID: I removed WIP as tests pass locally, now just waiting for them to pass in CI which is being particularly slow today ... -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/783#note_111903180 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Thu Oct 25 19:32:55 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 25 Oct 2018 17:32:55 +0000 Subject: [gnutls-devel] coverage | Makefile: use gcc-7 for coverage (!2) In-Reply-To: References: Message-ID: Merge Request !2 was closed by Nikos Mavrogiannopoulos Merge Request url: https://gitlab.com/gnutls/coverage/merge_requests/2 Branches: tmp-fix-coverage to master Author: Nikos Mavrogiannopoulos Assignee: -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/coverage/merge_requests/2 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Thu Oct 25 22:32:40 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 25 Oct 2018 20:32:40 +0000 Subject: [gnutls-devel] GnuTLS | Add support for AES CFB8 cipher (!783) In-Reply-To: References: Message-ID: So tests pass locally, but failed in CI, any idea ? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/783#note_111938972 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Thu Oct 25 23:31:41 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 25 Oct 2018 21:31:41 +0000 Subject: [gnutls-devel] GnuTLS | Add support for AES CFB8 cipher (!783) In-Reply-To: References: Message-ID: @simo5 Yes, AES-CFB8 is allowed in FIPS 140-2 mode, but you did not mark it so. Please apply the following patch: ```diff diff --git a/lib/fips.h b/lib/fips.h index 7d3f3cfd3960..4e09916ac44e 100644 --- a/lib/fips.h +++ b/lib/fips.h @@ -139,6 +139,9 @@ static unsigned is_cipher_algo_forbidden(gnutls_cipher_algorithm_t algo) case GNUTLS_CIPHER_3DES_CBC: case GNUTLS_CIPHER_AES_128_CCM_8: case GNUTLS_CIPHER_AES_256_CCM_8: + case GNUTLS_CIPHER_AES_128_CFB8: + case GNUTLS_CIPHER_AES_192_CFB8: + case GNUTLS_CIPHER_AES_256_CFB8: return 0; default: if (mode == GNUTLS_FIPS140_LAX) ``` -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/783#note_111947816 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Thu Oct 25 23:34:13 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 25 Oct 2018 21:34:13 +0000 Subject: [gnutls-devel] GnuTLS | Add support for AES CFB8 cipher (!783) In-Reply-To: References: Message-ID: Ok still do not get why it fails locally when enabling FIPS ... btw looking at the CCM ciphers I wonder if I should change the define to CFB_8 instead of CFB8 ? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/783#note_111948119 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Thu Oct 25 23:39:03 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 25 Oct 2018 21:39:03 +0000 Subject: [gnutls-devel] GnuTLS | Add support for AES CFB8 cipher (!783) In-Reply-To: References: Message-ID: It probably did not fail, because you've missed one of two pieces: - `./configure --enable-fips140-mode` - `GNUTLS_SKIP_FIPS_INTEGRITY_CHECKS=1 GNUTLS_FORCE_FIPS_MODE=1 make check` Well, SP800-38A clearly uses 'CFB8' without underscore, so I'd stick to it. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/783#note_111948689 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Thu Oct 25 23:39:56 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 25 Oct 2018 21:39:56 +0000 Subject: [gnutls-devel] GnuTLS | Add support for AES CFB8 cipher (!783) In-Reply-To: References: Message-ID: Ah a minute after I posted I realized I have the env vars on the make check line but forgot the --enable-fips140-mode configure switch running a local test build with that now, thanks! -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/783#note_111948821 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Oct 26 00:05:53 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 25 Oct 2018 22:05:53 +0000 Subject: [gnutls-devel] GnuTLS | Deprecate TPM 1.2 code (#101) In-Reply-To: References: Message-ID: TPMv2.0 is a completely different beast, but that doesn't in itself render the TPMv1.2 support obsolete. The TPMv1.2 hardware is still in common use. The TPMv2.0 model still doesn't lend itself well to being exposed via PKCS#11, just as TPMv1.2 didn't. There is a different format for the PEM storage of wrapped keys, and there are different fields to be included in a TPMv2.0-capable update to the TPM URI draft, but I think it still makes sense to support them in the same way we do TPMv1.2. Sure, it sucks a bit that TPMv2.0 is so completely different ? and it sucks that we have two separate TSS2 library implementations we might want to be able to use ? but I think we should. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/101#note_111951506 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Oct 26 00:09:33 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 25 Oct 2018 22:09:33 +0000 Subject: [gnutls-devel] GnuTLS | Deprecate TPM 1.2 code (#101) In-Reply-To: References: Message-ID: Btw, is the source XML of the tpmkey draft available anywhere? I think I'd like to use it as the basis for a new version that includes TPMv2 URIs and also defines the ASN.1 storage format for wrapped keys. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/101#note_111951858 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Oct 26 00:12:09 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 25 Oct 2018 22:12:09 +0000 Subject: [gnutls-devel] GnuTLS | Add support for AES CFB8 cipher (!783) In-Reply-To: References: Message-ID: ok a full git clean -f -x -d -f follwed by full reconfigure showed the issue finally, and your patch fixes it. Applied and pushed. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/783#note_111952091 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Oct 26 00:26:51 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Thu, 25 Oct 2018 22:26:51 +0000 Subject: [gnutls-devel] GnuTLS | Add support for AES CFB8 cipher (!783) In-Reply-To: References: Message-ID: Merge Request !783 was approved by Dmitry Eremin-Solenikov Merge Request url: https://gitlab.com/gnutls/gnutls/merge_requests/783 Project:Branches: simo5/gnutls:cfb8 to gnutls/gnutls:master Author: Simo Sorce Assignee: -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/783 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Oct 26 06:53:11 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 26 Oct 2018 04:53:11 +0000 Subject: [gnutls-devel] GnuTLS | Deprecate TPM 1.2 code (#101) In-Reply-To: References: Message-ID: Indeed. I think we then need a new issue to extend the current code to TPM 2.0, and add support for transparent loading of TPM2 keys by `gnutls_privkey_import_x509_raw` and possibly `gnutls_x509_privkey_import`. The original draft was in gitorious and was not moved to gitlab. The source is attached here: [draft-mavrogiannopoulos-tpmuri-02.xml](/uploads/6c9f39a8ad452928b5db734882974eac/draft-mavrogiannopoulos-tpmuri-02.xml) -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/101#note_111984097 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Oct 26 06:55:41 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 26 Oct 2018 04:55:41 +0000 Subject: [gnutls-devel] GnuTLS | Bring support for TPM 2.0 (#594) References: Message-ID: New Issue was created. Issue 594: https://gitlab.com/gnutls/gnutls/issues/594 Author: Nikos Mavrogiannopoulos Assignee: TPMv2.0 is a completely different beast to TPM 1.2, and needs to be added on top of TPM 1.2 because the TPMv1.2 hardware is still in common use. The TPMv2.0 model still doesn't lend itself well to being exposed via PKCS#11 completely, just as TPMv1.2 didn't. There is a different format for the PEM storage of wrapped keys, and there are different fields to be included in a TPMv2.0-capable update to the TPM URI draft, but I think it still makes sense to support them in the same way we do TPMv1.2. We should - extend the current code to TPM 2.0, - add support for transparent loading of TPM2 keys by `gnutls_privkey_import_x509_raw` and possibly `gnutls_x509_privkey_import`. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/594 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Oct 26 06:55:53 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 26 Oct 2018 04:55:53 +0000 Subject: [gnutls-devel] GnuTLS | Deprecate TPM 1.2 code (#101) In-Reply-To: References: Message-ID: Closing in favor of #594 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/101#note_111984332 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Oct 26 06:55:54 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 26 Oct 2018 04:55:54 +0000 Subject: [gnutls-devel] GnuTLS | Deprecate TPM 1.2 code (#101) In-Reply-To: References: Message-ID: Issue was closed by Nikos Mavrogiannopoulos Issue #101: https://gitlab.com/gnutls/gnutls/issues/101 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/101 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Oct 26 07:09:36 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 26 Oct 2018 05:09:36 +0000 Subject: [gnutls-devel] GnuTLS | Add support for AES CFB8 cipher (!783) In-Reply-To: References: Message-ID: @simo5 the CI failures are due to limits in the config of your local repo. Could you change it to 2h in Settings -> CI/CD -> General pipelines? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/783#note_111985244 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Oct 26 08:26:22 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 26 Oct 2018 06:26:22 +0000 Subject: [gnutls-devel] GnuTLS | Add support for AES CFB8 cipher (!783) In-Reply-To: References: Message-ID: Reassigned Merge Request 783 https://gitlab.com/gnutls/gnutls/merge_requests/783 Assignee changed to Dmitry Eremin-Solenikov -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/783 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Oct 26 15:42:59 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 26 Oct 2018 13:42:59 +0000 Subject: [gnutls-devel] GnuTLS | TLS 1.3: calculate ticket age based on higher precision time (!785) In-Reply-To: References: Message-ID: Merge Request !785 was approved by Nikos Mavrogiannopoulos Merge Request url: https://gitlab.com/gnutls/gnutls/merge_requests/785 Branches: tmp-session-ticket-timestamp to master Author: Daiki Ueno Assignee: -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/785 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Oct 26 15:43:14 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 26 Oct 2018 13:43:14 +0000 Subject: [gnutls-devel] GnuTLS | TLS 1.3: calculate ticket age based on higher precision time (!785) In-Reply-To: References: Message-ID: Reassigned Merge Request 785 https://gitlab.com/gnutls/gnutls/merge_requests/785 Assignee changed to Daiki Ueno -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/785 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Oct 26 15:43:29 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 26 Oct 2018 13:43:29 +0000 Subject: [gnutls-devel] GnuTLS | TLS 1.3: calculate ticket age based on higher precision time (!785) In-Reply-To: References: Message-ID: Merge Request !785 was merged Merge Request url: https://gitlab.com/gnutls/gnutls/merge_requests/785 Branches: tmp-session-ticket-timestamp to master Author: Daiki Ueno Assignee: Daiki Ueno -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/785 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Oct 26 16:15:17 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 26 Oct 2018 14:15:17 +0000 Subject: [gnutls-devel] GnuTLS | Add support for AES CFB8 cipher (!783) In-Reply-To: References: Message-ID: Merge Request !783 was merged Merge Request url: https://gitlab.com/gnutls/gnutls/merge_requests/783 Project:Branches: simo5/gnutls:cfb8 to gnutls/gnutls:master Author: Simo Sorce Assignee: Dmitry Eremin-Solenikov -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/783 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Oct 26 16:15:17 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 26 Oct 2018 14:15:17 +0000 Subject: [gnutls-devel] GnuTLS | add support for AES-CFB8 (#357) In-Reply-To: References: Message-ID: Issue was closed by Dmitry Eremin-Solenikov Issue #357: https://gitlab.com/gnutls/gnutls/issues/357 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/357 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Oct 26 16:30:36 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 26 Oct 2018 14:30:36 +0000 Subject: [gnutls-devel] GnuTLS | Add support for AES CFB8 cipher (!783) In-Reply-To: References: Message-ID: @simo5 thank you! -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/783#note_112140458 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Oct 26 18:22:01 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 26 Oct 2018 16:22:01 +0000 Subject: [gnutls-devel] GnuTLS | Add support for AES CFB8 cipher (!783) In-Reply-To: References: Message-ID: @lumag thanks for the review and help! -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/783#note_112174149 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Oct 26 23:03:00 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 26 Oct 2018 21:03:00 +0000 Subject: [gnutls-devel] GnuTLS | Add support for AES CMAC mac (!786) References: Message-ID: New Merge Request !786 https://gitlab.com/gnutls/gnutls/merge_requests/786 Project:Branches: simo5/gnutls:cmac to gnutls/gnutls:master Author: Simo Sorce Assignee: Add a description of the new feature/bug fix. Reference any relevant bugs. ## Checklist * [X] Code modified for feature * [X] Test suite updated with functionality tests ## Reviewer's checklist: * [ ] Any issues marked for closing are addressed * [ ] There is a test suite reasonably covering new functionality or modifications * [ ] Function naming, parameters, return values, types, etc., are consistent and according to `CONTRIBUTION.md` * [ ] This feature/change has adequate documentation added * [ ] No obvious mistakes in the code -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/786 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Oct 26 23:06:51 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 26 Oct 2018 21:06:51 +0000 Subject: [gnutls-devel] GnuTLS | Add support for AES CMAC mac (!786) In-Reply-To: References: Message-ID: This is a merge request analogous to the one just merged for CFB8. The only doubt I have here is that in theory CMAC can return an arbitrary digest length between 1 and 16 bytes, however GnuTLS hmac (misnamed) API does not allow for variable length digest as far a sI can see, nor the self tests. In practice this is not a big deal because internally the mac simply truncates the output to return anything shorter than 16 bytes, so users can do the same. The only issue is that I couldn't use SP800-38 CAV vectors because they give outputs for 4 or 15 bytes length, so I had to use a couple of vectors lifted from nettle's own tests. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/786#note_112231352 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Oct 26 23:50:24 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 26 Oct 2018 21:50:24 +0000 Subject: [gnutls-devel] GnuTLS | Add support for AES CMAC mac (!786) In-Reply-To: References: Message-ID: @simo5 0. Why are you adding all these algorithms to GnuTLS? (You have added CFB8, now comes CMAC and I saw that you were working on XTS.) Do you have any application in mind, which would benefit from using GnuTLS, rather than using Nettle directly? 1. Could you please change just `CMAC_128`/`CMAC_256` to `AES_CMAC_128`/`AES_CMAC_256` (and so on for lower case names). Nettle code uses cmac128 for generic 128-bit-block CMAC version (e.g. for GOST ciphers I'm adding `cmac64_*` interface). However CMAC code is not specific to AES (NIST defines TDEA-CMAC-xxx, CMAC computed using 3DES as basis). 2. [NIST SP800-38B](https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-38b.pdf) contained test vectors with tags which are exactly 16 bytes long. It is replaced now, but [examples for AES-CMAC](https://csrc.nist.gov/CSRC/media/Projects/Cryptographic-Standards-and-Guidelines/documents/examples/AES_CMAC.pdf) page also has 16-byte tags. Could you please re-verify them and just attribute them to NIST SP800-38A? 3. I think it's find to always return 16 bytes. If anybody wants, he can handle tag truncation manually. 4. Which part of GnuTLS MAC interface seems misnamed to you? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/786#note_112236320 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Sat Oct 27 10:46:56 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sat, 27 Oct 2018 08:46:56 +0000 Subject: [gnutls-devel] GnuTLS | Add support for AES CMAC mac (!786) In-Reply-To: References: Message-ID: Hi Dmitri, The milestone that these issues are under was made after discussing with samba, qemu and chrony developers. They use gnutls for TLS but had to use some other library for crypto like CFB8 or xts. Nettle is an option for some of them but it has two shortcomings: 1. It is changing abi and api quite regularly, while at gnutls we are getting better in terms of abi and especially api stability, 2. It is very low level and thus cannot serve as a crypto module in the fips definition (eg it cannot refuse the use of a forbidden algorithm like md5) -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/786#note_112274380 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Sat Oct 27 17:43:36 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sat, 27 Oct 2018 15:43:36 +0000 Subject: [gnutls-devel] GnuTLS | Add support for AES CMAC mac (!786) In-Reply-To: References: Message-ID: > 0. Why are you adding all these algorithms to GnuTLS? (You have added > CFB8, now comes CMAC and I saw that you were working on XTS.) Do you > have any application in mind, which would benefit from using GnuTLS, > rather than using Nettle directly? CFB8 and CMAC are used by Samba, we're working on making it use GnuTLS for all algorithms instead of implementing their own. I think this is partially so we can do FIPS certification on a single library. XTS is used by libvirt, which had to copy it from another library although they normally use only GnuTLS. So in general I am just bringing in stuff the our downstreams asked us for, and Nikos opened issues for, a while ago. > 1. Could you please change just `CMAC_128`/`CMAC_256` to > `AES_CMAC_128`/`AES_CMAC_256` (and so on for lower case names). > Nettle code uses cmac128 for generic 128-bit-block CMAC version (e.g. > for GOST ciphers I'm adding `cmac64_*` interface). However CMAC code > is not specific to AES (NIST defines TDEA-CMAC-xxx, CMAC computed > using 3DES as basis). I can change it to CMAC_AES_128/256 like nettle does, the other way around would make people think that this is AES + CMAC authentication of some sort. > 2. [NIST SP800- > 38B](https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublicati > on800-38b.pdf) contained test vectors with tags which are exactly 16 > bytes long. It is replaced now, but [examples for AES- > CMAC](https://csrc.nist.gov/CSRC/media/Projects/Cryptographic- > Standards-and-Guidelines/documents/examples/AES_CMAC.pdf) page also > has 16-byte tags. Could you please re-verify them and just attribute > them to NIST SP800-38A? Ok. > 3. I think it's find to always return 16 bytes. If anybody wants, he > can handle tag truncation manually. I guess find -> fine, I agree. > 4. Which part of GnuTLS MAC interface seems misnamed to you? it's called HMAC, gnutls_hmac_init when it handles MAC generally, infact we are adding CMAC and there is already UMAC too. It is not a big deal, but may be a little confusing to a novice. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/786#note_112431524 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Sat Oct 27 18:32:55 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sat, 27 Oct 2018 16:32:55 +0000 Subject: [gnutls-devel] GnuTLS | Add support for AES CMAC mac (!786) In-Reply-To: References: Message-ID: Ok, renamed to GNUTLS_MAC_CMAC_AES_128/256, and checked the AES_CMAC.pdf and confirmed these were NIST vectors, so changed the comment to NIST SP800-38A. Tests seem to be passing locally, waiting on the pipeline. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/786#note_112434638 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Sat Oct 27 20:14:49 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sat, 27 Oct 2018 18:14:49 +0000 Subject: [gnutls-devel] GnuTLS | Support ESNI (#595) References: Message-ID: New Issue was created. Issue 595: https://gitlab.com/gnutls/gnutls/issues/595 Author: Craig Andrews Assignee: Encrypted SNI is on the standards track and is already being deployed by big players. Draft RFC: https://tools.ietf.org/html/draft-rescorla-tls-esni-00 Championed by the EFF: https://www.eff.org/deeplinks/2018/09/esni-privacy-protecting-upgrade-https Deployed by Cloudflare: https://blog.cloudflare.com/esni/ Cloudflare's technical details post: https://blog.cloudflare.com/encrypted-sni/ Supported by Firefox: https://blog.mozilla.org/security/2018/10/18/encrypted-sni-comes-to-firefox-nightly/ Supported by NSS: https://bugzilla.mozilla.org/show_bug.cgi?id=1495120 ESNI is specifically being pushed by Sen. Ron Wyden (D-OR): https://gizmodo.com/sen-wyden-urges-dhs-to-adopt-new-encryption-tech-to-pr-1830001179 Work in progress in H2O: https://github.com/h2o/picotls/issues/187 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/595 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Sat Oct 27 23:38:28 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sat, 27 Oct 2018 21:38:28 +0000 Subject: [gnutls-devel] GnuTLS | Add support for AES CMAC mac (!786) In-Reply-To: References: Message-ID: Dmitry Eremin-Solenikov started a new discussion on lib/algorithms/mac.c: > .output_size = 64, > .key_size = 64, > .block_size = 64}, > + {.name = "CMAC-128", > + .id = GNUTLS_MAC_CMAC_AES_128, > + .output_size = 16, > + .key_size = 16,}, > + {.name = "CMAC-256", And here -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/786#note_112450406 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Sat Oct 27 23:38:29 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sat, 27 Oct 2018 21:38:29 +0000 Subject: [gnutls-devel] GnuTLS | Add support for AES CMAC mac (!786) In-Reply-To: References: Message-ID: Dmitry Eremin-Solenikov started a new discussion on lib/algorithms/mac.c: > .output_size = 64, > .key_size = 64, > .block_size = 64}, > + {.name = "CMAC-128", Could you please change here to mention AES too? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/786#note_112450407 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Sat Oct 27 23:39:43 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sat, 27 Oct 2018 21:39:43 +0000 Subject: [gnutls-devel] GnuTLS | Add support for AES CMAC mac (!786) In-Reply-To: References: Message-ID: I'd prefer to follow [RFC 4493](https://tools.ietf.org/html/rfc4493) and name it AES-CMAC. @nmav your opinion? Other than that and two minor notes above looks good to me. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/786#note_112450460 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Sat Oct 27 23:56:29 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sat, 27 Oct 2018 21:56:29 +0000 Subject: [gnutls-devel] GnuTLS | Add support for AES CMAC mac (!786) In-Reply-To: References: Message-ID: Ok given RFC 4493 names it that way I changed all names around and fixed the .name assignments -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/786#note_112451138 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Sun Oct 28 00:03:22 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sat, 27 Oct 2018 22:03:22 +0000 Subject: [gnutls-devel] GnuTLS | Add support for AES CMAC mac (!786) In-Reply-To: References: Message-ID: Dmitry Eremin-Solenikov started a new discussion on lib/includes/gnutls/gnutls.h.in: > * @GNUTLS_MAC_AEAD: MAC implicit through AEAD cipher. > * @GNUTLS_MAC_UMAC_96: The UMAC-96 MAC algorithm. > * @GNUTLS_MAC_UMAC_128: The UMAC-128 MAC algorithm. > + * @GNUTLS_MAC_CMAC_128: The CMAC-128 MAC algorithm. please fix documentation to use new names. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/786#note_112451418 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Sun Oct 28 08:20:57 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sun, 28 Oct 2018 07:20:57 +0000 Subject: [gnutls-devel] GnuTLS | Selftests for symmetric GOST algorithms (!787) References: Message-ID: New Merge Request !787 https://gitlab.com/gnutls/gnutls/merge_requests/787 Project:Branches: GostCrypt/gnutls:gost-selfcheck to gnutls/gnutls:master Author: Dmitry Eremin-Solenikov Assignee: Approvers: Simon Josefsson, Nikos Mavrogiannopoulos, Hubert Kario, Tim R?hsen, Andreas Metzler, Daiki Ueno, Tom, Ander Juaristi, Tom?? Mr?z, Anderson Sasaki and GnuTLS devel mailing list A partial fix for #492. Add test vectors for block cipher/digest/hmac functions. Also fix S-box selection for CryptoPro-B, -C, -D variants. ## Checklist * [X] Code modified for feature * [X] Test suite updated with functionality tests ## Reviewer's checklist: * [ ] Any issues marked for closing are addressed * [ ] There is a test suite reasonably covering new functionality or modifications * [ ] Function naming, parameters, return values, types, etc., are consistent and according to `CONTRIBUTION.md` * [ ] This feature/change has adequate documentation added * [ ] No obvious mistakes in the code -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/787 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Sun Oct 28 11:22:24 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sun, 28 Oct 2018 10:22:24 +0000 Subject: [gnutls-devel] GnuTLS | Add support for AES CMAC mac (!786) In-Reply-To: References: Message-ID: > I'd prefer to follow [RFC 4493](https://tools.ietf.org/html/rfc4493) and name it AES-CMAC. @nmav your opinion? Using the RFC name (even if confusing) makes sense to me. btw. it would be nice to have an entry in the `NEWS` file as well. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/786#note_112478752 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Sun Oct 28 11:24:30 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sun, 28 Oct 2018 10:24:30 +0000 Subject: [gnutls-devel] GnuTLS | Selftests for symmetric GOST algorithms (!787) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos started a new discussion on lib/nettle/cipher.c: > _gost28147_set_key_cpb(void *ctx, const uint8_t *key) > { > gost28147_set_key(ctx, key); > - gost28147_set_param(ctx, &gost28147_param_CryptoPro_A); > + gost28147_set_param(ctx, &gost28147_param_CryptoPro_B); Is that something that will cause compatibility issues? Should it have a NEWS entry? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/787#note_112478868 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Sun Oct 28 11:25:43 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sun, 28 Oct 2018 10:25:43 +0000 Subject: [gnutls-devel] GnuTLS | Selftests for symmetric GOST algorithms (!787) In-Reply-To: References: Message-ID: With the exception of the question, it looks good to me. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/787#note_112478934 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Sun Oct 28 11:29:49 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sun, 28 Oct 2018 10:29:49 +0000 Subject: [gnutls-devel] GnuTLS | Support ESNI (#595) In-Reply-To: References: Message-ID: I've updated the link to point to the final draft. I think it is a feature worth considering after it is being published even as an experimental rfc. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/595#note_112479135 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Sun Oct 28 13:28:18 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sun, 28 Oct 2018 12:28:18 +0000 Subject: [gnutls-devel] GnuTLS | Selftests for symmetric GOST algorithms (!787) In-Reply-To: References: Message-ID: Dmitry Eremin-Solenikov commented on a discussion on lib/nettle/cipher.c: > _gost28147_set_key_cpb(void *ctx, const uint8_t *key) > { > gost28147_set_key(ctx, key); > - gost28147_set_param(ctx, &gost28147_param_CryptoPro_A); > + gost28147_set_param(ctx, &gost28147_param_CryptoPro_B); Yes, it looks so. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/787#note_112485155 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Sun Oct 28 17:17:52 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sun, 28 Oct 2018 16:17:52 +0000 Subject: [gnutls-devel] GnuTLS | Add support for AES CMAC mac (!786) In-Reply-To: References: Message-ID: Simo Sorce commented on a discussion on lib/includes/gnutls/gnutls.h.in: > * @GNUTLS_MAC_AEAD: MAC implicit through AEAD cipher. > * @GNUTLS_MAC_UMAC_96: The UMAC-96 MAC algorithm. > * @GNUTLS_MAC_UMAC_128: The UMAC-128 MAC algorithm. > + * @GNUTLS_MAC_CMAC_128: The CMAC-128 MAC algorithm. Ah, good catch! -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/786#note_112550482 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Sun Oct 28 17:20:51 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sun, 28 Oct 2018 16:20:51 +0000 Subject: [gnutls-devel] GnuTLS | Add support for AES CMAC mac (!786) In-Reply-To: References: Message-ID: @namv add a commit to put AES-CMAC as well as the prevbious AES-CFB8 cipher on a news line. See if it is ok this way or if you want separate lines. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/786#note_112550744 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Sun Oct 28 17:32:41 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sun, 28 Oct 2018 16:32:41 +0000 Subject: [gnutls-devel] GnuTLS | Add support for AES CMAC mac (!786) In-Reply-To: References: Message-ID: Oops did not realize you already pushed a NEWS line for CFB8, reworked the commit to add only a NEW item for CMAC -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/786#note_112551588 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Sun Oct 28 17:40:59 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sun, 28 Oct 2018 16:40:59 +0000 Subject: [gnutls-devel] GnuTLS | Selftests for symmetric GOST algorithms (!787) In-Reply-To: References: Message-ID: Merge Request !787 was approved by Nikos Mavrogiannopoulos Merge Request url: https://gitlab.com/gnutls/gnutls/merge_requests/787 Project:Branches: GostCrypt/gnutls:gost-selfcheck to gnutls/gnutls:master Author: Dmitry Eremin-Solenikov Assignee: -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/787 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Sun Oct 28 17:41:13 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sun, 28 Oct 2018 16:41:13 +0000 Subject: [gnutls-devel] GnuTLS | Selftests for symmetric GOST algorithms (!787) In-Reply-To: References: Message-ID: All discussions on Merge Request !787 were resolved by Nikos Mavrogiannopoulos https://gitlab.com/gnutls/gnutls/merge_requests/787 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/787 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Sun Oct 28 17:41:20 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sun, 28 Oct 2018 16:41:20 +0000 Subject: [gnutls-devel] GnuTLS | Selftests for symmetric GOST algorithms (!787) In-Reply-To: References: Message-ID: Merge Request !787 was merged Merge Request url: https://gitlab.com/gnutls/gnutls/merge_requests/787 Project:Branches: GostCrypt/gnutls:gost-selfcheck to gnutls/gnutls:master Author: Dmitry Eremin-Solenikov Assignee: -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/787 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Sun Oct 28 17:41:56 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sun, 28 Oct 2018 16:41:56 +0000 Subject: [gnutls-devel] GnuTLS | Selftests for symmetric GOST algorithms (!787) In-Reply-To: References: Message-ID: Thank you -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/787#note_112552132 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Sun Oct 28 23:07:20 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sun, 28 Oct 2018 22:07:20 +0000 Subject: [gnutls-devel] GnuTLS | Add support for AES CMAC mac (!786) In-Reply-To: References: Message-ID: All discussions on Merge Request !786 were resolved by Dmitry Eremin-Solenikov https://gitlab.com/gnutls/gnutls/merge_requests/786 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/786 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Sun Oct 28 23:07:31 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sun, 28 Oct 2018 22:07:31 +0000 Subject: [gnutls-devel] GnuTLS | Add support for AES CMAC mac (!786) In-Reply-To: References: Message-ID: Merge Request !786 was approved by Dmitry Eremin-Solenikov Merge Request url: https://gitlab.com/gnutls/gnutls/merge_requests/786 Project:Branches: simo5/gnutls:cmac to gnutls/gnutls:master Author: Simo Sorce Assignee: -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/786 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Sun Oct 28 23:37:02 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sun, 28 Oct 2018 22:37:02 +0000 Subject: [gnutls-devel] GnuTLS | Add support for AES CMAC mac (!786) In-Reply-To: References: Message-ID: @simo5 could you please rebase it on top of current master? I can't merge it otherwise. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/786#note_112589152 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Sun Oct 28 23:38:46 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sun, 28 Oct 2018 22:38:46 +0000 Subject: [gnutls-devel] GnuTLS | Add support for AES CMAC mac (!786) In-Reply-To: References: Message-ID: @nmav was there any discussion/outcome about non-ff merges? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/786#note_112589238 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Oct 29 00:42:38 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sun, 28 Oct 2018 23:42:38 +0000 Subject: [gnutls-devel] GnuTLS | Add support for AES CMAC mac (!786) In-Reply-To: References: Message-ID: @lumag rebased (personally I hate non-ff merges) -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/786#note_112593865 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Oct 29 01:48:56 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 29 Oct 2018 00:48:56 +0000 Subject: [gnutls-devel] GnuTLS | add support for AES-CMAC (#351) In-Reply-To: References: Message-ID: Issue was closed by Dmitry Eremin-Solenikov Issue #351: https://gitlab.com/gnutls/gnutls/issues/351 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/351 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Oct 29 01:48:56 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 29 Oct 2018 00:48:56 +0000 Subject: [gnutls-devel] GnuTLS | Add support for AES CMAC mac (!786) In-Reply-To: References: Message-ID: Merge Request !786 was merged Merge Request url: https://gitlab.com/gnutls/gnutls/merge_requests/786 Project:Branches: simo5/gnutls:cmac to gnutls/gnutls:master Author: Simo Sorce Assignee: -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/786 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Oct 29 01:50:18 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 29 Oct 2018 00:50:18 +0000 Subject: [gnutls-devel] GnuTLS | Add support for AES CMAC mac (!786) In-Reply-To: References: Message-ID: @simo5 thank you! -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/786#note_112596922 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Oct 29 09:48:39 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 29 Oct 2018 08:48:39 +0000 Subject: [gnutls-devel] GnuTLS | implement anti-replay mechanism for 0-RTT (!782) In-Reply-To: References: Message-ID: Merge Request !782 was closed by Daiki Ueno Merge Request url: https://gitlab.com/gnutls/gnutls/merge_requests/782 Branches: tmp-anti-replay to tmp-0rtt Author: Daiki Ueno Assignee: -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/782 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Oct 29 09:48:55 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 29 Oct 2018 08:48:55 +0000 Subject: [gnutls-devel] GnuTLS | implement anti-replay mechanism for 0-RTT (!782) In-Reply-To: References: Message-ID: Merged this to !775. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/782#note_112676460 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Oct 29 09:56:27 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 29 Oct 2018 08:56:27 +0000 Subject: [gnutls-devel] GnuTLS | add support for 0-RTT (!775) In-Reply-To: References: Message-ID: Reassigned Merge Request 775 https://gitlab.com/gnutls/gnutls/merge_requests/775 Assignee changed to Nikos Mavrogiannopoulos -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/775 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Oct 29 09:57:32 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 29 Oct 2018 08:57:32 +0000 Subject: [gnutls-devel] GnuTLS | gnutls_priority_set: do not override the version after handshake is complete (!777) In-Reply-To: References: Message-ID: @Vrancken how should we proceed with this? I think the fix should enter gnutls for the next release irrespective of the cleanup. If you still have concerns with the cleanup should I split it to another merge request? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/777#note_112678766 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Oct 29 12:02:31 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 29 Oct 2018 11:02:31 +0000 Subject: [gnutls-devel] GnuTLS | change or make configurable to number of tickets to send by default (#596) References: Message-ID: New Issue was created. Issue 596: https://gitlab.com/gnutls/gnutls/issues/596 Author: Nikos Mavrogiannopoulos Assignee: As a server we currently send only a single ticket by default, and expect the application to use `gnutls_session_ticket_send` to send additional ones. Should we send a larger number by default to be more HTTP friendly? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/596 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Oct 29 13:46:08 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 29 Oct 2018 12:46:08 +0000 Subject: [gnutls-devel] GnuTLS | self-tests: add GOST public key tests (!788) References: Message-ID: New Merge Request !788 https://gitlab.com/gnutls/gnutls/merge_requests/788 Project:Branches: GostCrypt/gnutls:gost-selfcheck to gnutls/gnutls:master Author: Dmitry Eremin-Solenikov Assignee: Approvers: Simon Josefsson, Nikos Mavrogiannopoulos, Hubert Kario, Tim R?hsen, Andreas Metzler, Daiki Ueno, Tom, Ander Juaristi, Tom?? Mr?z, Anderson Sasaki and GnuTLS devel mailing list Add a description of the new feature/bug fix. Reference any relevant bugs. ## Checklist * [x] Code modified for feature * [x] Test suite updated with functionality tests ## Reviewer's checklist: * [ ] Any issues marked for closing are addressed * [ ] There is a test suite reasonably covering new functionality or modifications * [ ] Function naming, parameters, return values, types, etc., are consistent and according to `CONTRIBUTION.md` * [ ] This feature/change has adequate documentation added * [ ] No obvious mistakes in the code -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/788 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Oct 29 13:51:14 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 29 Oct 2018 12:51:14 +0000 Subject: [gnutls-devel] GnuTLS | add support for 0-RTT (!775) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos started a new discussion on lib/gnutls_int.h: > * early_secret, client_early_traffic_secret, ... */ > uint8_t temp_secret[MAX_HASH_SIZE]; > unsigned temp_secret_size; /* depends on negotiated PRF size */ > + uint8_t e_ckey[MAX_HASH_SIZE]; /* client_early_traffic_secret */ I'm wondering whether we should introduce a `MAX_TLS13_KDF_SIZE`, to reduce the size taken by these keys... -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/775#note_112778603 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Oct 29 13:51:17 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 29 Oct 2018 12:51:17 +0000 Subject: [gnutls-devel] GnuTLS | add support for 0-RTT (!775) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos started a new discussion on lib/ext/early_data.c: > return 0; > } > > +/** > + * gnutls_record_get_max_early_data_size: > + * @session: is a #gnutls_session_t type. > + * > + * This function gets the maximum early data size in this connection. I think 's/gets/returns' seems more natural -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/775#note_112778634 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Oct 29 13:51:18 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 29 Oct 2018 12:51:18 +0000 Subject: [gnutls-devel] GnuTLS | add support for 0-RTT (!775) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos started a new discussion on lib/Makefile.am: > tls13/hello_retry.c tls13/hello_retry.h \ > tls13/session_ticket.c tls13/session_ticket.h \ This commit message seems to be one of the most important. It would be good to have a more detailed message on what it is that is added. That is, something like that 'it adds the back-end for handling early data receiving and sending', or so. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/775#note_112778625 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Oct 29 13:51:19 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 29 Oct 2018 12:51:19 +0000 Subject: [gnutls-devel] GnuTLS | add support for 0-RTT (!775) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos started a new discussion on lib/handshake-tls13.c: > case STATE101: > - ret = > - generate_and_set_hs_traffic_keys(session); > + /* Note that we check IN_FLIGHT, not ACCEPTED > + * here. This is because the client sends early data > + * speculatively. */ > + if (session->internals.hsk_flags & HSK_EARLY_DATA_IN_FLIGHT) { > + ret = _tls13_write_connection_state_init(session, STAGE_EARLY); > + if (ret == 0) { > + _gnutls_epoch_bump(session); > + ret = _gnutls_epoch_dup(session, EPOCH_WRITE_CURRENT); > + } > + } > STATE = STATE101; > - IMED_RET_FATAL("generate session keys", ret, 0); > + IMED_RET_FATAL("set early traffic keys", ret, 0); should these two lines enter the if block? `ret` will have a value set to zero, so it works, but it feels like easy for a change to break this part. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/775#note_112778628 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Oct 29 13:51:20 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 29 Oct 2018 12:51:20 +0000 Subject: [gnutls-devel] GnuTLS | add support for 0-RTT (!775) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos started a new discussion on lib/includes/gnutls/gnutls.h.in: > > void gnutls_supplemental_send(gnutls_session_t session, unsigned do_send_supplemental); > > +/* Anti-replay related functions */ > + > +typedef struct gnutls_anti_replay_st *gnutls_anti_replay_t; > + > +typedef int (*gnutls_anti_replay_add_func) (void *, const gnutls_datum_t *key); > +typedef unsigned (*gnutls_anti_replay_check_func) (void *, const gnutls_datum_t *key); > +typedef void(*gnutls_anti_replay_clear_func) (void *); This introduces a new set of database functions that should be set by servers supporting 0rtt. Why not re-use the existing `gnutls_db` subsystem to store such entries? From the app developer perspective there will be minimal changes to an existing server application. What do you think is the main benefit from this new api? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/775#note_112778620 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Oct 29 13:51:17 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 29 Oct 2018 12:51:17 +0000 Subject: [gnutls-devel] GnuTLS | add support for 0-RTT (!775) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos started a new discussion on lib/record.c: > + * @data: contains the data to send > + * @data_size: is the length of the data > + * > + * This function has the similar semantics with gnutls_record_send(). > + * The difference is that the data will be sent as early data, and > + * thus this function must be called before gnutls_handshake() by the > + * client. > + * > + * Returns: The number of bytes sent, or a negative error code. The > + * number of bytes sent might be less than @data_size. The maximum > + * number of bytes this function can send in a single call depends > + * on the negotiated maximum record size. > + * > + * Since: 3.6.5 > + **/ > +int gnutls_record_send_early_data(gnutls_session_t session, shouldn't return type be `ssize_t` here, since the sent data is of type `size_t`? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/775#note_112778635 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Oct 29 13:51:17 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 29 Oct 2018 12:51:17 +0000 Subject: [gnutls-devel] GnuTLS | add support for 0-RTT (!775) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos started a new discussion on lib/tls13/siphash.c: > + v1 = ROTL(v1, 13); \ > + v1 ^= v0; \ > + v0 = ROTL(v0, 32); \ > + v2 += v3; \ > + v3 = ROTL(v3, 16); \ > + v3 ^= v2; \ > + v0 += v3; \ > + v3 = ROTL(v3, 21); \ > + v3 ^= v0; \ > + v2 += v1; \ > + v1 = ROTL(v1, 17); \ > + v1 ^= v2; \ > + v2 = ROTL(v2, 32); \ > + } while (0) > + > +uint64_t _gnutls_siphash_2_4(const uint8_t *in, const size_t inlen, Shouldn't we have some test vectors for this function? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/775#note_112778632 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Oct 29 13:51:20 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 29 Oct 2018 12:51:20 +0000 Subject: [gnutls-devel] GnuTLS | add support for 0-RTT (!775) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos started a new discussion on lib/tls13/siphash.c: > + v1 = ROTL(v1, 13); \ > + v1 ^= v0; \ > + v0 = ROTL(v0, 32); \ > + v2 += v3; \ > + v3 = ROTL(v3, 16); \ > + v3 ^= v2; \ > + v0 += v3; \ > + v3 = ROTL(v3, 21); \ > + v3 ^= v0; \ > + v2 += v1; \ > + v1 = ROTL(v1, 17); \ > + v1 ^= v2; \ > + v2 = ROTL(v2, 32); \ > + } while (0) > + > +uint64_t _gnutls_siphash_2_4(const uint8_t *in, const size_t inlen, would be nice to have some internal documentation on how is this supposed to be used. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/775#note_112778651 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Oct 29 13:51:15 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 29 Oct 2018 12:51:15 +0000 Subject: [gnutls-devel] GnuTLS | add support for 0-RTT (!775) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos started a new discussion on tests/suite/testcompat-tls13-openssl.sh: > kill ${PID} > wait > > + # Try resumption with early data > + echo_cmd "${PREFIX}Checking TLS 1.3 with resumption with early data..." Should we also test with our maximum value? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/775#note_112778612 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Oct 29 13:51:15 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 29 Oct 2018 12:51:15 +0000 Subject: [gnutls-devel] GnuTLS | add support for 0-RTT (!775) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos started a new discussion on lib/state.c: > _mbuffer_head_clear(&session->internals.record_recv_buffer); > _mbuffer_head_clear(&session->internals.record_send_buffer); > > + _mbuffer_head_clear(&session->internals.early_data_recv_buffer); > + _gnutls_buffer_clear(&session->internals.early_data_presend_buffer); would it make sense for it to be cleared after the handshake is complete as well? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/775#note_112778616 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Oct 29 13:51:19 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 29 Oct 2018 12:51:19 +0000 Subject: [gnutls-devel] GnuTLS | add support for 0-RTT (!775) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos started a new discussion on lib/tls13/siphash.c: > + v0 += v1; \ > + v1 = ROTL(v1, 13); \ > + v1 ^= v0; \ > + v0 = ROTL(v0, 32); \ > + v2 += v3; \ > + v3 = ROTL(v3, 16); \ > + v3 ^= v2; \ > + v0 += v3; \ > + v3 = ROTL(v3, 21); \ > + v3 ^= v0; \ > + v2 += v1; \ > + v1 = ROTL(v1, 17); \ > + v1 ^= v2; \ > + v2 = ROTL(v2, 32); \ > + } while (0) > + It would be good to have some comment on how this function is to be used (desc+parameters). -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/775#note_112778641 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Oct 29 13:51:21 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 29 Oct 2018 12:51:21 +0000 Subject: [gnutls-devel] GnuTLS | add support for 0-RTT (!775) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos started a new discussion on lib/record.c: > +ssize_t > +gnutls_record_recv_early_data(gnutls_session_t session, void *data, size_t data_size) > +{ > + mbuffer_st *bufel; > + gnutls_datum_t msg; > + size_t length; > + > + if (session->security_parameters.entity != GNUTLS_SERVER) > + return gnutls_assert_val(GNUTLS_E_INVALID_REQUEST); > + > + bufel = _mbuffer_head_get_first(&session->internals.early_data_recv_buffer, > + &msg); > + if (bufel == NULL) > + return > + gnutls_assert_val > + (GNUTLS_E_REQUESTED_DATA_NOT_AVAILABLE); It would be good to document this error code explicitly in the `Returns` field above. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/775#note_112778644 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Oct 29 13:51:18 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 29 Oct 2018 12:51:18 +0000 Subject: [gnutls-devel] GnuTLS | add support for 0-RTT (!775) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos started a new discussion on lib/record.c: > + ("REC[%p]: failed to decrypt early data, in epoch %d\n", > + session, > + record_params->epoch); > + ret = GNUTLS_E_DECRYPTION_FAILED; > goto sanity_check_error; > - } > + } else if (record.type == GNUTLS_APPLICATION_DATA) { > + size_t decrypted_length = > + _mbuffer_get_udata_size(decrypted); > + _gnutls_record_log > + ("REC[%p]: decrypted early data with length: %d, in epoch %d\n", > + session, > + (int) decrypted_length, > + record_params->epoch); > + if (decrypted_length > > + session->security_parameters.max_early_data_size - Can `max_early_data_size` - `session->internals.early_data_received` be negative? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/775#note_112778618 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Oct 29 13:51:23 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 29 Oct 2018 12:51:23 +0000 Subject: [gnutls-devel] GnuTLS | add support for 0-RTT (!775) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos started a new discussion on lib/constate.c: > return _tls13_update_keys(session, stage, > params, iv_size, key_size); > > + if (stage == STAGE_EARLY) > + return _tls13_set_early_keys(session, > + params, iv_size, key_size); > + doesn't it make sense to combine these two blocks with if then else? E.g, ``` if (stage == STAGE_EARLY) ... else if (stage == ...) ``` -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/775#note_112778655 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Oct 29 13:51:18 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 29 Oct 2018 12:51:18 +0000 Subject: [gnutls-devel] GnuTLS | add support for 0-RTT (!775) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos started a new discussion on lib/record.c: > + _gnutls_buffer_append_data(&session->internals. > + early_data_presend_buffer, data, > + data_size); > + if (ret < 0) > + return gnutls_assert_val(ret); > + > + return ret; > +} > + > +/** > + * gnutls_record_recv_early_data: > + * @session: is a #gnutls_session_t type. > + * @data: the buffer that the data will be read into > + * @data_size: the number of requested bytes > + * > + * This function has the similar semantics with gnutls_record_recv(). typo: `has the` to `has` also the same comment as above -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/775#note_112778614 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Oct 29 13:51:20 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 29 Oct 2018 12:51:20 +0000 Subject: [gnutls-devel] GnuTLS | add support for 0-RTT (!775) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos started a new discussion on lib/ext/early_data.c: > > +/** > + * gnutls_record_get_max_early_data_size: > + * @session: is a #gnutls_session_t type. > + * > + * This function gets the maximum early data size in this connection. > + * This property can only be set to servers. The client may be > + * provided with the maximum allowed size through the "early_data" > + * extension of the NewSessionTicket handshake message. > + * > + * Returns: On success, %GNUTLS_E_SUCCESS (0) is returned, > + * otherwise a negative error code is returned. > + * > + * Since: 3.6.5 > + **/ > +ssize_t If it always returns a positive number, maybe `size_t` is more suitable. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/775#note_112778660 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Oct 29 13:51:21 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 29 Oct 2018 12:51:21 +0000 Subject: [gnutls-devel] GnuTLS | add support for 0-RTT (!775) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos started a new discussion on lib/ext/early_data.c: > const uint8_t * data, size_t _data_size) > { > const version_entry_st *vers = get_version(session); > + > if (!vers || !vers->tls13_sem) > return gnutls_assert_val(0); > - if (session->security_parameters.entity == GNUTLS_SERVER) > + How do we ensure here that no early data are sent or received after [a helloretryrequest is sent](https://tools.ietf.org/html/rfc8446#section-4.2.10)? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/775#note_112778654 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Oct 29 13:51:19 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 29 Oct 2018 12:51:19 +0000 Subject: [gnutls-devel] GnuTLS | add support for 0-RTT (!775) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos started a new discussion on lib/tls13/session_ticket.c: > int ret; > gnutls_datum_t packed = { NULL, 0 }; > tls13_ticket_st ticket_data; > - time_t now = gnutls_time(0); > > if (session->internals.resumed != RESUME_FALSE) { > + time_t now = gnutls_time(0); Here we call both gnutls_time() and gnutls_gettime(). There are most likely not very significant calls in performance terms as they are often implemented as vdso, but why not call only gnutls_gettime() once and assign the now from its seconds value? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/775#note_112778639 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Oct 29 13:51:19 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 29 Oct 2018 12:51:19 +0000 Subject: [gnutls-devel] GnuTLS | add support for 0-RTT (!775) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos started a new discussion on lib/ext/early_data.c: > return 0; > } > > +/** > + * gnutls_record_get_max_early_data_size: > + * @session: is a #gnutls_session_t type. > + * > + * This function gets the maximum early data size in this connection. > + * This property can only be set to servers. The client may be > + * provided with the maximum allowed size through the "early_data" > + * extension of the NewSessionTicket handshake message. > + * > + * Returns: On success, %GNUTLS_E_SUCCESS (0) is returned, This seems incorrect. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/775#note_112778643 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Oct 29 13:51:21 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 29 Oct 2018 12:51:21 +0000 Subject: [gnutls-devel] GnuTLS | add support for 0-RTT (!775) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos started a new discussion on lib/tls13/session_ticket.c: > return 0; > } > > +static int append_nst_extension(void *ctx, gnutls_buffer_st *buf) > +{ > + gnutls_session_t session = ctx; > + int ret; > + > + if (!(session->internals.flags & GNUTLS_ENABLE_EARLY_DATA)) What if `max_early_data_size` is set to zero? Should we behave as it is disabled? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/775#note_112778647 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Oct 29 13:51:22 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 29 Oct 2018 12:51:22 +0000 Subject: [gnutls-devel] GnuTLS | add support for 0-RTT (!775) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos started a new discussion on lib/tls13/anti_replay.c: > + if (ret < 0) { > + gnutls_free (*anti_replay); > + return gnutls_assert_val(ret); > + } > + > + gnutls_gettime(&(*anti_replay)->start_time); > + > + return 0; > +} > + > +/** > + * gnutls_anti_replay_set_window: > + * @anti_replay: is a #gnutls_anti_replay_t type. > + * @window: is the time window recording ClientHello, in milliseconds > + * > + * Sets the time window used for ClientHello recording. We should provide more info about what this time is an how it affects the db usage. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/775#note_112778662 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Oct 29 13:51:16 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 29 Oct 2018 12:51:16 +0000 Subject: [gnutls-devel] GnuTLS | add support for 0-RTT (!775) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos started a new discussion on lib/record.c: > } > } > > +/** > + * gnutls_record_send_early_data: > + * @session: is a #gnutls_session_t type. > + * @data: contains the data to send > + * @data_size: is the length of the data > + * > + * This function has the similar semantics with gnutls_record_send(). > + * The difference is that the data will be sent as early data, and > + * thus this function must be called before gnutls_handshake() by the > + * client. > + * I think it makes sense to reference `gnutls_record_get_max_early_data_size` from here, and say that this function is bounded by that value (if that's the case). -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/775#note_112778602 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Oct 29 13:51:18 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 29 Oct 2018 12:51:18 +0000 Subject: [gnutls-devel] GnuTLS | add support for 0-RTT (!775) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos started a new discussion on lib/includes/gnutls/gnutls.h.in: > +typedef struct gnutls_anti_replay_st *gnutls_anti_replay_t; > + > +typedef int (*gnutls_anti_replay_add_func) (void *, const gnutls_datum_t *key); > +typedef unsigned (*gnutls_anti_replay_check_func) (void *, const gnutls_datum_t *key); > +typedef void(*gnutls_anti_replay_clear_func) (void *); > + > +int gnutls_anti_replay_init(gnutls_anti_replay_t *anti_replay); > +void gnutls_anti_replay_deinit(gnutls_anti_replay_t anti_replay); > +void gnutls_anti_replay_set_window(gnutls_anti_replay_t anti_replay, > + unsigned int window); > +void gnutls_anti_replay_set_functions(gnutls_anti_replay_t anti_replay, > + gnutls_anti_replay_add_func add_func, > + gnutls_anti_replay_check_func check_func, > + gnutls_anti_replay_clear_func clear_func, > + void *ptr); > +int gnutls_anti_replay_enable(gnutls_session_t session, I think we should have an anti-replay mechanism always on, and refuse to use 0-rtt if that's not possible. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/775#note_112778598 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Oct 29 13:51:31 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 29 Oct 2018 12:51:31 +0000 Subject: [gnutls-devel] GnuTLS | add support for 0-RTT (!775) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos started a new discussion on lib/record.c: > } > } > > +/** > + * gnutls_record_send_early_data: > + * @session: is a #gnutls_session_t type. > + * @data: contains the data to send > + * @data_size: is the length of the data > + * > + * This function has the similar semantics with gnutls_record_send(). typo: `has the` to `has` Also maybe moving this first sentence later, and start the description by what this sentence does may be more easy to read. E.g., what about: ``` This function can be used to send data early in the handshake processes when resuming a session. This is used to implement a zero-roundtrip (0-rtt) mode. It has the same semantics as `gnutls_record_recv()`. ``` -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/775#note_112778609 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Oct 29 13:51:23 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 29 Oct 2018 12:51:23 +0000 Subject: [gnutls-devel] GnuTLS | add support for 0-RTT (!775) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos started a new discussion on tests/suite/testcompat-tls13-openssl.sh: > kill ${PID} > wait > > + # Try resumption with early data > + echo_cmd "${PREFIX}Checking TLS 1.3 with resumption with early data..." > + testdir=`create_testdir tls13-openssl-resumption` > + eval "${GETPORT}" > + launch_bare_server $$ s_server -quiet -www -accept "${PORT}" -keyform pem -certform pem ${OPENSSL_DH_PARAMS_OPT} -key "${RSA_KEY}" -cert "${RSA_CERT}" -CAfile "${CA_CERT}" -early_data > + PID=$! > + wait_server ${PID} > + > + echo "This file contains early data sent by the client" > "${testdir}/earlydata.txt" > + ${VALGRIND} "${CLI}" ${DEBUG} -p "${PORT}" 127.0.0.1 --priority "NORMAL:-VERS-ALL:+VERS-TLS1.3:+GROUP-ALL${ADD}" --earlydata "${testdir}/earlydata.txt" --insecure --inline-commands <<< $(echo -e "^resume^\nGET / HTTP/1.0\r\n\r\n")| tee "${testdir}/client.out" >> ${OUTPUT} given that we are sending early data, is the `GET /` cmd needed here? Shouldn't we rely on the early data to send that? We can have it with variable size by adding an arbitrary header `X-test: 00000000000000000` -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/775#note_112778649 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Oct 29 13:51:14 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 29 Oct 2018 12:51:14 +0000 Subject: [gnutls-devel] GnuTLS | add support for 0-RTT (!775) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos started a new discussion on lib/handshake-tls13.c: > #endif > FALLTHROUGH; > case STATE101: > - ret = > - generate_and_set_hs_traffic_keys(session); > STATE = STATE101; > - IMED_RET_FATAL("generate session keys", ret, 0); > + if (session->internals.hsk_flags & HSK_EARLY_DATA_ACCEPTED) { Can this if-clause be combined with the one below? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/775#note_112778604 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Oct 29 13:51:16 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 29 Oct 2018 12:51:16 +0000 Subject: [gnutls-devel] GnuTLS | add support for 0-RTT (!775) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos started a new discussion on lib/ext/early_data.c: > return 0; > } > > +/** > + * gnutls_record_get_max_early_data_size: > + * @session: is a #gnutls_session_t type. > + * > + * This function gets the maximum early data size in this connection. > + * This property can only be set to servers. The client may be What will be the return value if this property is not set? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/775#note_112778623 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Oct 29 13:59:27 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 29 Oct 2018 12:59:27 +0000 Subject: [gnutls-devel] GnuTLS | Provide selftests for all crypto algorithms (#597) References: Message-ID: New Issue was created. Issue 597: https://gitlab.com/gnutls/gnutls/issues/597 Author: Dmitry Eremin-Solenikov Assignee: Provide crypto selftests for all algorithms: - ciphers: - [ ] null - [x] arcfour-128 - [x] 3des-cbc - [x] aes-*-cbc - [x] aes-*-ccm - [ ] aes-*-ccm_8 - [x] aes-*-cfb8 - [x] aes-*-gcm - [ ] arcfour-40 [not implemented] - [ ] rc2-40-cbc - [ ] camellia-*-cbc - [ ] camellia-*-gcm - [ ] salsa20-256 - [ ] salsa20/r12-256 - [x] chacha20-poly1305 - [x] gost28147-*-cfb [5 paramsets] - [ ] xxx-pgp-cfb [9 ciphersuites, not implemented] - digests: - [ ] null - [ ] rmd-160 - [ ] md2 - [x] md5 - [ ] md5-sha1 - [x] sha1 - [x] sha-2-224/-356/-384/512 - [x] sha-3-224/-256/-384/-512 - [x] gostr-94 - [x] streebog-256/-512 - macs: - [ ] null - [ ] rmd-160 - [ ] md2 - [x] md5 - [ ] md5-sha1 - [x] sha1 - [x] sha-2-224/-356/-384/512 - [x] sha-3-224/-256/-384/-512 - [x] gostr-94 - [x] streebog-256/-512 - [ ] sha3-* [reserved, not implemented] - [ ] umac-96/umac-128 - [x] aes-cmac-128/-256 - pk: - [x] rsa - [ ] rsa-pss - [x] dsa - [x] dh - [x] ecdsa - [ ] ecdh-x55519 - [ ] eddsa-ed25519 - [ ] gost-01 - [ ] gost-12-256/gost-12-512 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/597 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Oct 29 14:12:11 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 29 Oct 2018 13:12:11 +0000 Subject: [gnutls-devel] GnuTLS | self-tests: add GOST public key tests (!788) In-Reply-To: References: Message-ID: @nmav strangely enough this MR is not marked as related to #492 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/788#note_112784713 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Oct 29 14:27:23 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 29 Oct 2018 13:27:23 +0000 Subject: [gnutls-devel] GnuTLS | self-tests: add GOST public key tests (!788) In-Reply-To: References: Message-ID: Would using "Resolves" or "Closes" change that? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/788#note_112789822 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Oct 29 14:28:34 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 29 Oct 2018 13:28:34 +0000 Subject: [gnutls-devel] GnuTLS | self-tests: add GOST public key tests (!788) In-Reply-To: References: Message-ID: Thanks for #492 btw, it made me realize that we miss tests for RSA-PSS as well. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/788#note_112790184 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Oct 29 14:30:58 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 29 Oct 2018 13:30:58 +0000 Subject: [gnutls-devel] GnuTLS | add support for 0-RTT (!775) In-Reply-To: References: Message-ID: Daiki Ueno commented on a discussion on lib/includes/gnutls/gnutls.h.in: > > void gnutls_supplemental_send(gnutls_session_t session, unsigned do_send_supplemental); > > +/* Anti-replay related functions */ > + > +typedef struct gnutls_anti_replay_st *gnutls_anti_replay_t; > + > +typedef int (*gnutls_anti_replay_add_func) (void *, const gnutls_datum_t *key); > +typedef unsigned (*gnutls_anti_replay_check_func) (void *, const gnutls_datum_t *key); > +typedef void(*gnutls_anti_replay_clear_func) (void *); I originally thought so, but gave up reusing it for the following reasons: - There are a few gaps between the current db backend function and the what anti-replay DB needs: i.e., `_clear()` (= remove all) is missing and `_retr()` always returns a value, though it's not needed - It was unclear that the DB might also be used for different purposes: e.g., for TLS <= 1.2 resumption, at the same time -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/775#note_112790817 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Oct 29 16:38:20 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 29 Oct 2018 15:38:20 +0000 Subject: [gnutls-devel] GnuTLS | self-tests: add GOST public key tests (!788) In-Reply-To: References: Message-ID: Looks good to me. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/788#note_112859423 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Oct 29 16:38:41 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 29 Oct 2018 15:38:41 +0000 Subject: [gnutls-devel] GnuTLS | self-tests: add GOST public key tests (!788) In-Reply-To: References: Message-ID: Merge Request !788 was approved by Nikos Mavrogiannopoulos Merge Request url: https://gitlab.com/gnutls/gnutls/merge_requests/788 Project:Branches: GostCrypt/gnutls:gost-selfcheck to gnutls/gnutls:master Author: Dmitry Eremin-Solenikov Assignee: -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/788 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Oct 29 17:04:21 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 29 Oct 2018 16:04:21 +0000 Subject: [gnutls-devel] GnuTLS | self-tests: add GOST public key tests (!788) In-Reply-To: References: Message-ID: @nmav maybe it was some backend issue. Now GitLab correctly shows as closing #492. Regarding RSA-PSS. I've opened #597 to track all algorithms and respective tests existence. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/788#note_112869141 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Oct 29 17:04:38 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 29 Oct 2018 16:04:38 +0000 Subject: [gnutls-devel] GnuTLS | missing testsuite for new ciphers (#492) In-Reply-To: References: Message-ID: Issue was closed by Dmitry Eremin-Solenikov Issue #492: https://gitlab.com/gnutls/gnutls/issues/492 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/492 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Oct 29 17:04:38 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 29 Oct 2018 16:04:38 +0000 Subject: [gnutls-devel] GnuTLS | self-tests: add GOST public key tests (!788) In-Reply-To: References: Message-ID: Merge Request !788 was merged Merge Request url: https://gitlab.com/gnutls/gnutls/merge_requests/788 Project:Branches: GostCrypt/gnutls:gost-selfcheck to gnutls/gnutls:master Author: Dmitry Eremin-Solenikov Assignee: -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/788 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Oct 29 17:10:22 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 29 Oct 2018 16:10:22 +0000 Subject: [gnutls-devel] GnuTLS | add support for 0-RTT (!775) In-Reply-To: References: Message-ID: Daiki Ueno commented on a discussion on lib/state.c: > _mbuffer_head_clear(&session->internals.record_recv_buffer); > _mbuffer_head_clear(&session->internals.record_send_buffer); > > + _mbuffer_head_clear(&session->internals.early_data_recv_buffer); > + _gnutls_buffer_clear(&session->internals.early_data_presend_buffer); Good point, fixed. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/775#note_112870774 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Oct 29 17:15:32 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 29 Oct 2018 16:15:32 +0000 Subject: [gnutls-devel] GnuTLS | add support for 0-RTT (!775) In-Reply-To: References: Message-ID: Daiki Ueno commented on a discussion on lib/record.c: > + ("REC[%p]: failed to decrypt early data, in epoch %d\n", > + session, > + record_params->epoch); > + ret = GNUTLS_E_DECRYPTION_FAILED; > goto sanity_check_error; > - } > + } else if (record.type == GNUTLS_APPLICATION_DATA) { > + size_t decrypted_length = > + _mbuffer_get_udata_size(decrypted); > + _gnutls_record_log > + ("REC[%p]: decrypted early data with length: %d, in epoch %d\n", > + session, > + (int) decrypted_length, > + record_params->epoch); > + if (decrypted_length > > + session->security_parameters.max_early_data_size - I don't think so, because `session->internals.early_data_received` must always be less than `max_early_data_size`. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/775#note_112872061 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Oct 29 17:20:04 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 29 Oct 2018 16:20:04 +0000 Subject: [gnutls-devel] GnuTLS | add support for 0-RTT (!775) In-Reply-To: References: Message-ID: Daiki Ueno commented on a discussion on lib/ext/early_data.c: > return 0; > } > > +/** > + * gnutls_record_get_max_early_data_size: > + * @session: is a #gnutls_session_t type. > + * > + * This function gets the maximum early data size in this connection. > + * This property can only be set to servers. The client may be This is a getter function so it shouldn't return error, IMO. I have changed the return type to `size_t` from `ssize_t`. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/775#note_112873372 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Oct 29 17:21:28 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 29 Oct 2018 16:21:28 +0000 Subject: [gnutls-devel] GnuTLS | add support for 0-RTT (!775) In-Reply-To: References: Message-ID: Daiki Ueno commented on a discussion on lib/record.c: > + * @data: contains the data to send > + * @data_size: is the length of the data > + * > + * This function has the similar semantics with gnutls_record_send(). > + * The difference is that the data will be sent as early data, and > + * thus this function must be called before gnutls_handshake() by the > + * client. > + * > + * Returns: The number of bytes sent, or a negative error code. The > + * number of bytes sent might be less than @data_size. The maximum > + * number of bytes this function can send in a single call depends > + * on the negotiated maximum record size. > + * > + * Since: 3.6.5 > + **/ > +int gnutls_record_send_early_data(gnutls_session_t session, Indeed, good catch. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/775#note_112873774 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Oct 29 17:46:49 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 29 Oct 2018 16:46:49 +0000 Subject: [gnutls-devel] GnuTLS | add support for 0-RTT (!775) In-Reply-To: References: Message-ID: Daiki Ueno commented on a discussion on lib/handshake-tls13.c: > #endif > FALLTHROUGH; > case STATE101: > - ret = > - generate_and_set_hs_traffic_keys(session); > STATE = STATE101; > - IMED_RET_FATAL("generate session keys", ret, 0); > + if (session->internals.hsk_flags & HSK_EARLY_DATA_ACCEPTED) { It is possible, but we need to duplicate: ```c ret = generate_hs_traffic_keys(session); IMED_RET_FATAL("generate hs traffic keys", ret, 0); ``` in both branches, as it touches `session->key.proto.tls13.temp_secret`. Anyway, did that change. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/775#note_112880134 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Oct 29 17:50:07 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 29 Oct 2018 16:50:07 +0000 Subject: [gnutls-devel] GnuTLS | add support for 0-RTT (!775) In-Reply-To: References: Message-ID: Daiki Ueno commented on a discussion on lib/Makefile.am: > tls13/hello_retry.c tls13/hello_retry.h \ > tls13/session_ticket.c tls13/session_ticket.h \ Sorry, I couldn't figure out which commit you mean, as the gitlab interface doesn't point me to the specific commit and the line 98 is from some older commit. Do you mean the one with "handshake: handle early data"? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/775#note_112881110 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Oct 29 18:02:55 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 29 Oct 2018 17:02:55 +0000 Subject: [gnutls-devel] GnuTLS | add support for 0-RTT (!775) In-Reply-To: References: Message-ID: Daiki Ueno commented on a discussion on lib/tls13/session_ticket.c: > return 0; > } > > +static int append_nst_extension(void *ctx, gnutls_buffer_st *buf) > +{ > + gnutls_session_t session = ctx; > + int ret; > + > + if (!(session->internals.flags & GNUTLS_ENABLE_EARLY_DATA)) The RFC doesn't say anything about the minimum value, so zero seems to be a legitimate value (though it's useless). -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/775#note_112898875 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Oct 29 20:22:34 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 29 Oct 2018 19:22:34 +0000 Subject: [gnutls-devel] GnuTLS | Provide selftests for all crypto algorithms (#597) In-Reply-To: References: Message-ID: Thank you for opening this. There are two reasons of these self tests: 1. FIPS140 requirements, which require them to run on application start-up (applies to FIPS-approved algorithms) 2. Ciphers which are not tested via nettle (e.g., bundled), and in that case they are run as part of the test suite. So I think the minimum / necessary outcome for that is: * pk - [ ] rsa-pss (FIPS140) - [ ] gost-01 (not in nettle) - [ ] gost-12-256/gost-12-512 (not in nettle) What do you think? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/597#note_112945046 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Oct 29 20:25:21 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 29 Oct 2018 19:25:21 +0000 Subject: [gnutls-devel] GnuTLS | add support for 0-RTT (!775) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos commented on a discussion on lib/Makefile.am: > tls13/hello_retry.c tls13/hello_retry.h \ > tls13/session_ticket.c tls13/session_ticket.h \ yes -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/775#note_112945528 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Oct 29 20:29:53 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 29 Oct 2018 19:29:53 +0000 Subject: [gnutls-devel] GnuTLS | add support for 0-RTT (!775) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos commented on a discussion on lib/tls13/session_ticket.c: > return 0; > } > > +static int append_nst_extension(void *ctx, gnutls_buffer_st *buf) > +{ > + gnutls_session_t session = ctx; > + int ret; > + > + if (!(session->internals.flags & GNUTLS_ENABLE_EARLY_DATA)) Indeed, that's why I think we shouldn't communicate (as server) values which don't have much sense as they may cause unpredictable behavior to clients. Alternatively, we could return an error when a zero value is set. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/775#note_112946267 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Oct 29 20:30:50 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 29 Oct 2018 19:30:50 +0000 Subject: [gnutls-devel] GnuTLS | add support for 0-RTT (!775) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos commented on a discussion on lib/gnutls_int.h: > * early_secret, client_early_traffic_secret, ... */ > uint8_t temp_secret[MAX_HASH_SIZE]; > unsigned temp_secret_size; /* depends on negotiated PRF size */ > + uint8_t e_ckey[MAX_HASH_SIZE]; /* client_early_traffic_secret */ I'm resolving this, as it is not much related to this particular MR. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/775#note_112946387 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Oct 29 20:55:25 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 29 Oct 2018 19:55:25 +0000 Subject: [gnutls-devel] GnuTLS | Update docs for session ticket key rotation (!768) In-Reply-To: References: Message-ID: @juaristi ? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/768#note_112950594 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Oct 29 21:50:46 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 29 Oct 2018 20:50:46 +0000 Subject: [gnutls-devel] GnuTLS | Provide selftests for all crypto algorithms (#597) In-Reply-To: References: Message-ID: Well. There are other sources for untested code. `lib/accelerated/` contains code which is not tested under nettle. Cryptodev and !555 use kernel facilities and have to be tested on their own. Thus I'd prefer to have small selftests for each algo. Just to be sure. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/597#note_112959433 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Oct 29 21:55:32 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 29 Oct 2018 20:55:32 +0000 Subject: [gnutls-devel] GnuTLS | Provide selftests for all crypto algorithms (#597) In-Reply-To: References: Message-ID: BTW: arcfour-40 support was lost in 7d1308f29b7512a2913a031f5baccab65f68073d. Should it be fixed? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/597#note_112960325 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Oct 30 08:12:45 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 30 Oct 2018 07:12:45 +0000 Subject: [gnutls-devel] GnuTLS | Provide selftests for all crypto algorithms (#597) In-Reply-To: References: Message-ID: I do not remember the details but arcfour-40 was only part of TLS export ciphersuites, and was not supported in pkcs12 or other encrypted scheme. Given that and the fact that no-one complained these 3 years for it, I'd say let's ignore it. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/597#note_113046643 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Oct 30 09:09:24 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 30 Oct 2018 08:09:24 +0000 Subject: [gnutls-devel] GnuTLS | Provide selftests for all crypto algorithms (#597) In-Reply-To: References: Message-ID: Well, it was part of PKCS#12. But it's definitely seems unused now, so let's forget about it for now. Quoting [RFC 7292](https://tools.ietf.org/html/rfc7292): ``` pkcs-12PbeIds OBJECT IDENTIFIER ::= {pkcs-12 1} pbeWithSHAAnd128BitRC4 OBJECT IDENTIFIER ::= {pkcs-12PbeIds 1} pbeWithSHAAnd40BitRC4 OBJECT IDENTIFIER ::= {pkcs-12PbeIds 2} pbeWithSHAAnd3-KeyTripleDES-CBC OBJECT IDENTIFIER ::= {pkcs-12PbeIds 3} pbeWithSHAAnd2-KeyTripleDES-CBC OBJECT IDENTIFIER ::= {pkcs-12PbeIds 4} pbeWithSHAAnd128BitRC2-CBC OBJECT IDENTIFIER ::= {pkcs-12PbeIds 5} pbewithSHAAnd40BitRC2-CBC OBJECT IDENTIFIER ::= {pkcs-12PbeIds 6} ``` -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/597#note_113058347 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Oct 30 09:14:41 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 30 Oct 2018 08:14:41 +0000 Subject: [gnutls-devel] GnuTLS | gnutls-cli: reduce printed session information (!784) In-Reply-To: References: Message-ID: It's a pity that gitlab doesn't have `git diff -w`. This patch looks much cleaner with this option. LGTM -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/784#note_113059390 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Oct 30 09:14:52 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 30 Oct 2018 08:14:52 +0000 Subject: [gnutls-devel] GnuTLS | gnutls-cli: reduce printed session information (!784) In-Reply-To: References: Message-ID: Merge Request !784 was merged Merge Request url: https://gitlab.com/gnutls/gnutls/merge_requests/784 Branches: tmp-cli-reduce-output to master Author: Nikos Mavrogiannopoulos Assignee: -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/784 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Oct 30 09:14:44 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 30 Oct 2018 08:14:44 +0000 Subject: [gnutls-devel] GnuTLS | gnutls-cli: reduce printed session information (!784) In-Reply-To: References: Message-ID: Merge Request !784 was approved by Dmitry Eremin-Solenikov Merge Request url: https://gitlab.com/gnutls/gnutls/merge_requests/784 Branches: tmp-cli-reduce-output to master Author: Nikos Mavrogiannopoulos Assignee: -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/784 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Oct 30 10:03:37 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 30 Oct 2018 09:03:37 +0000 Subject: [gnutls-devel] GnuTLS | Update docs for session ticket key rotation (!768) In-Reply-To: References: Message-ID: Yes, sorry. I've had a sudden burst of work and have been offline during last week. This will be done soon. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/768#note_113071142 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Oct 30 10:15:02 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 30 Oct 2018 09:15:02 +0000 Subject: [gnutls-devel] GnuTLS | gnutls-cli: reduce printed session information (!784) In-Reply-To: References: Message-ID: Thank you! -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/784#note_113074121 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Oct 30 10:16:05 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 30 Oct 2018 09:16:05 +0000 Subject: [gnutls-devel] GnuTLS | Update docs for session ticket key rotation (!768) In-Reply-To: References: Message-ID: np, just wanted to make sure it we don't miss it for next release. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/768#note_113074372 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Oct 30 10:29:57 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 30 Oct 2018 09:29:57 +0000 Subject: [gnutls-devel] GnuTLS | add support for 0-RTT (!775) In-Reply-To: References: Message-ID: Daiki Ueno commented on a discussion on lib/includes/gnutls/gnutls.h.in: > +typedef struct gnutls_anti_replay_st *gnutls_anti_replay_t; > + > +typedef int (*gnutls_anti_replay_add_func) (void *, const gnutls_datum_t *key); > +typedef unsigned (*gnutls_anti_replay_check_func) (void *, const gnutls_datum_t *key); > +typedef void(*gnutls_anti_replay_clear_func) (void *); > + > +int gnutls_anti_replay_init(gnutls_anti_replay_t *anti_replay); > +void gnutls_anti_replay_deinit(gnutls_anti_replay_t anti_replay); > +void gnutls_anti_replay_set_window(gnutls_anti_replay_t anti_replay, > + unsigned int window); > +void gnutls_anti_replay_set_functions(gnutls_anti_replay_t anti_replay, > + gnutls_anti_replay_add_func add_func, > + gnutls_anti_replay_check_func check_func, > + gnutls_anti_replay_clear_func clear_func, > + void *ptr); > +int gnutls_anti_replay_enable(gnutls_session_t session, The current implementation refuses the use of 0-rtt if the anti-replay mechanism is not set on the session (see the documentation). Not sure if it is feasible to enable it by default. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/775#note_113078434 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Oct 30 10:41:21 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 30 Oct 2018 09:41:21 +0000 Subject: [gnutls-devel] GnuTLS | add support for 0-RTT (!775) In-Reply-To: References: Message-ID: Daiki Ueno commented on a discussion on lib/ext/early_data.c: > const uint8_t * data, size_t _data_size) > { > const version_entry_st *vers = get_version(session); > + > if (!vers || !vers->tls13_sem) > return gnutls_assert_val(0); > - if (session->security_parameters.entity == GNUTLS_SERVER) > + Added a check against `HSK_HRR_SENT` here. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/775#note_113081605 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Oct 30 11:28:21 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 30 Oct 2018 10:28:21 +0000 Subject: [gnutls-devel] GnuTLS | gnutls_priority_set: do not override the version after handshake is complete (!777) In-Reply-To: References: Message-ID: Tom commented on a discussion on lib/priority.c: > } It's about line 597. I think this part is reachable when you use this function to set priorities for the first time. If the `_gnutls_set_current_version()` function fails then now you get an `GNUTLS_E_NO_PRIORITIES_WERE_SET` error code back. This is imo not the correct error code here because there were priorities set. Therefore I would suggest to return the error code that `_gnutls_set_current_version()` returns. Furthermore, I think the function documentation is currently not correct since we do not return any error if someone calls this function again with incorrect priorities (i.e. different proto version). In the current implementation we simply do not (re)set a new protocol version if the handshake is in progress or if it has been completed. The rest of the priorities will be changed to the new ones given in that case and 0 will be returned. We should therefore either update the docs or return an error code if someone whats to change the protocol version. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/777#note_113096274 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Oct 30 11:28:37 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 30 Oct 2018 10:28:37 +0000 Subject: [gnutls-devel] GnuTLS | gnutls_priority_set: do not override the version after handshake is complete (!777) In-Reply-To: References: Message-ID: Yes, I'm sorry I was abroad for a couple of days. There is one important discussion to revolve I think. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/777#note_113096339 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Oct 30 11:42:56 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 30 Oct 2018 10:42:56 +0000 Subject: [gnutls-devel] GnuTLS | WIP: RFC7250 Raw public keys (!650) In-Reply-To: References: Message-ID: Tom commented on a discussion on lib/includes/gnutls/gnutls.h.in: > unsigned idx, > gnutls_datum_t * response); > > +/* RAW public key functions (RFC7250) */ > +#ifdef ENABLE_RAWPK > +int gnutls_certificate_set_rawpk_keypair(gnutls_certificate_credentials_t cred, > + const gnutls_pubkey_t subjectPublicKeyInfo, > + const gnutls_privkey_t key); > + > +int gnutls_certificate_set_rawpk_keypair_raw(gnutls_certificate_credentials_t cred, I mean how about following the naming convention from `pcert.c`. There you use the `_raw` suffix when plain `datum_t` types are being fed into the functions. E.g. `gnutls_pcert_import_x509_raw` and `gnutls_pcert_import_x509`. And then create an alias for the `...set_x509_key_mem` functions. Also we can think about renaming these key set functions to using "keypair" in the name instead of "key" to make clear its about a key pair. Of course we need to stay API compatible and need to create aliases for the old ones. Just a wild idea to improve code readability. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/650#note_113100454 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Oct 30 13:13:08 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 30 Oct 2018 12:13:08 +0000 Subject: [gnutls-devel] GnuTLS | gnutls_priority_set: do not override the version after handshake is complete (!777) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos commented on a discussion on lib/priority.c: > } > Furthermore, I think the function documentation is currently not correct since we do not return any error if someone calls this function again with incorrect priorities (i.e. different proto version). In the current implementation we simply do not (re)set a new protocol version if the handshake is in progress or if it has been completed. The rest of the priorities will be changed to the new ones given in that case and 0 will be returned. We do limited checks that's true. I've updated the documentation to clarify that if it is called multiple times, the caller should ensure sanity of the values. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/777#note_113124107 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Oct 30 14:35:02 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 30 Oct 2018 13:35:02 +0000 Subject: [gnutls-devel] GnuTLS | add support for 0-RTT (!775) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos commented on a discussion on lib/includes/gnutls/gnutls.h.in: > > void gnutls_supplemental_send(gnutls_session_t session, unsigned do_send_supplemental); > > +/* Anti-replay related functions */ > + > +typedef struct gnutls_anti_replay_st *gnutls_anti_replay_t; > + > +typedef int (*gnutls_anti_replay_add_func) (void *, const gnutls_datum_t *key); > +typedef unsigned (*gnutls_anti_replay_check_func) (void *, const gnutls_datum_t *key); > +typedef void(*gnutls_anti_replay_clear_func) (void *); Ok, we discussed this offline, and I suggested to take a look to see whether we can do something that: - reduces the changes needed to an existing app - if that's not possible, an API which consolidates our database usage (e.g., an API that will be used both for tls1.2 sessions and tls1.3 anti-replay checks, with the ability to separate); that I believe would be good in case we need something different in tlsx.y -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/775#note_113151479 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Oct 30 19:34:41 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 30 Oct 2018 18:34:41 +0000 Subject: [gnutls-devel] GnuTLS | WIP: RFC7250 Raw public keys (!650) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos commented on a discussion on lib/includes/gnutls/gnutls.h.in: > unsigned idx, > gnutls_datum_t * response); > > +/* RAW public key functions (RFC7250) */ > +#ifdef ENABLE_RAWPK > +int gnutls_certificate_set_rawpk_keypair(gnutls_certificate_credentials_t cred, > + const gnutls_pubkey_t subjectPublicKeyInfo, > + const gnutls_privkey_t key); > + > +int gnutls_certificate_set_rawpk_keypair_raw(gnutls_certificate_credentials_t cred, Following existing conventions is of course what I'd also recommend. About renaming it's quite complex to do any existing function renames in order to achieve API and ABI compatibility (goal is not to break ABI anytime soon). Unless there is a serious issue I'd suggest against it because it creates quite some ugly situation on the back-end that is only resolved with an ABI breakage. Maybe we can record possible renames in an issue for future reference for when an ABI break is planned. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/650#note_113252198 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Oct 30 19:43:05 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 30 Oct 2018 18:43:05 +0000 Subject: [gnutls-devel] GnuTLS | Getting error "Please insert token 'TEE_TOKEN' in slot and press enter" on searching private objects. (#583) In-Reply-To: References: Message-ID: Hi, `count == 1` means that an object matching the template was found. I'm not sure what's the issue you are seeing but it looks like the object you specified is not found. Could you send a reproducer using softhsm for example? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/583#note_113253610 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Oct 30 19:57:01 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 30 Oct 2018 18:57:01 +0000 Subject: [gnutls-devel] GnuTLS | CTYPE-OPENPGP priority no longer recognized (#593) In-Reply-To: References: Message-ID: Reassigned Issue 593 https://gitlab.com/gnutls/gnutls/issues/593 Assignee changed to Nikos Mavrogiannopoulos -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/593 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Oct 30 20:00:50 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 30 Oct 2018 19:00:50 +0000 Subject: [gnutls-devel] GnuTLS | gnutls_priority_init: ignore CTYPE-OPENPGP options (!789) References: Message-ID: New Merge Request !789 https://gitlab.com/gnutls/gnutls/merge_requests/789 Branches: tmp-ignore-ctypes to master Author: Nikos Mavrogiannopoulos Assignee: Approvers: Simon Josefsson, Dmitry Eremin-Solenikov, Hubert Kario, Tim R?hsen, Andreas Metzler, Daiki Ueno, Tom, Ander Juaristi, Tom?? Mr?z, Anderson Sasaki and GnuTLS devel mailing list In GnuTLS 3.6.0 we dropped support for openpgp keys, however the CTYPE-OPENPGP is often seen in applications, sometimes has -CTYPE-OPENPGP to ensure it is not enabled. We simply ignore this priority string when seen, to avoid preventing these applications from running. ## Checklist * [x] Code modified for feature * [x] Test suite updated with functionality tests * [x] Documentation updated / NEWS entry present (for non-trivial changes) ## Reviewer's checklist: * [ ] Any issues marked for closing are addressed * [ ] There is a test suite reasonably covering new functionality or modifications * [ ] Function naming, parameters, return values, types, etc., are consistent and according to `CONTRIBUTION.md` * [ ] This feature/change has adequate documentation added * [ ] No obvious mistakes in the code -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/789 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Oct 30 20:19:58 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 30 Oct 2018 19:19:58 +0000 Subject: [gnutls-devel] GnuTLS | Service Desk (from achraf@achrafsellam.com): TLS problem (#598) In-Reply-To: References: Message-ID: I suspect this is a duplicate of #593 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/598#note_113273661 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Oct 30 20:21:15 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 30 Oct 2018 19:21:15 +0000 Subject: [gnutls-devel] GnuTLS | Service Desk (from achraf@achrafsellam.com): TLS problem (#598) In-Reply-To: References: Message-ID: If you are using a distribution which ships gnutls, I'd suggest to open a ticket there and refer them to: https://gitlab.com/gnutls/gnutls/issues/593 I'm closing this now as duplicate, but feel free to open a new ticket with more information, if that is not the case. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/598#note_113274842 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Oct 30 20:21:17 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 30 Oct 2018 19:21:17 +0000 Subject: [gnutls-devel] GnuTLS | Service Desk (from achraf@achrafsellam.com): TLS problem (#598) In-Reply-To: References: Message-ID: Issue was closed by Nikos Mavrogiannopoulos Issue #598: https://gitlab.com/gnutls/gnutls/issues/598 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/598 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Oct 30 22:30:09 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 30 Oct 2018 21:30:09 +0000 Subject: [gnutls-devel] GnuTLS | gnutls_priority_set: do not override the version after handshake is complete (!777) In-Reply-To: References: Message-ID: Tom started a new discussion on lib/priority.c: > * @priority: is a #gnutls_priority_t type. > * > * Sets the priorities to use on the ciphers, key exchange methods, > - * and macs. > + * and macs. Note that this function is expected to be called once > + * per session; when called multiple times (e.g., before a re-handshake, > + * the caller should make sure that any new settings are not incompatible > + * with the original session). > * > * Returns: %GNUTLS_E_SUCCESS on success, %GNUTLS_E_NO_PRIORITIES_WERE_SET if > * the existing priorities were not overriden due to invalid priority set (behavior I think we can remove the > %GNUTLS_E_NO_PRIORITIES_WERE_SET if the existing priorities were not overriden due to... part because we don't remove that error code anymore in that case. Right? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/777#note_113323897 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Oct 31 07:33:59 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 31 Oct 2018 06:33:59 +0000 Subject: [gnutls-devel] GnuTLS | gnutls_priority_set: do not override the version after handshake is complete (!777) In-Reply-To: References: Message-ID: Nikos Mavrogiannopoulos commented on a discussion on lib/priority.c: > * @priority: is a #gnutls_priority_t type. > * > * Sets the priorities to use on the ciphers, key exchange methods, > - * and macs. > + * and macs. Note that this function is expected to be called once > + * per session; when called multiple times (e.g., before a re-handshake, > + * the caller should make sure that any new settings are not incompatible > + * with the original session). > * > * Returns: %GNUTLS_E_SUCCESS on success, %GNUTLS_E_NO_PRIORITIES_WERE_SET if > * the existing priorities were not overriden due to invalid priority set (behavior done -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/777#note_113373687 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Oct 31 09:47:21 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 31 Oct 2018 08:47:21 +0000 Subject: [gnutls-devel] GnuTLS | add support for 0-RTT (!775) In-Reply-To: References: Message-ID: Daiki Ueno commented on a discussion on lib/includes/gnutls/gnutls.h.in: > > void gnutls_supplemental_send(gnutls_session_t session, unsigned do_send_supplemental); > > +/* Anti-replay related functions */ > + > +typedef struct gnutls_anti_replay_st *gnutls_anti_replay_t; > + > +typedef int (*gnutls_anti_replay_add_func) (void *, const gnutls_datum_t *key); > +typedef unsigned (*gnutls_anti_replay_check_func) (void *, const gnutls_datum_t *key); > +typedef void(*gnutls_anti_replay_clear_func) (void *); For the latter approach, what do you say the new backend functions (`store`, `remove`, `retr`) take a list of attributes instead of a datum, as in `C_FindObjects` in PKCS#11? That way we could supply arbitrary hints to the backend and wouldn't need another function for the "remove all" behavior. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/775#note_113406203 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Oct 31 10:26:16 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 31 Oct 2018 09:26:16 +0000 Subject: [gnutls-devel] GnuTLS | gnutls_priority_set: do not override the version after handshake is complete (!777) In-Reply-To: References: Message-ID: Merge Request !777 was approved by Tom Merge Request url: https://gitlab.com/gnutls/gnutls/merge_requests/777 Branches: tmp-fix-priority-set to master Author: Nikos Mavrogiannopoulos Assignee: -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/777 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Oct 31 10:34:31 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 31 Oct 2018 09:34:31 +0000 Subject: [gnutls-devel] GnuTLS | gnutls_priority_set: do not override the version after handshake is complete (!777) In-Reply-To: References: Message-ID: All discussions on Merge Request !777 were resolved by Nikos Mavrogiannopoulos https://gitlab.com/gnutls/gnutls/merge_requests/777 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/777 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Oct 31 10:34:53 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 31 Oct 2018 09:34:53 +0000 Subject: [gnutls-devel] GnuTLS | gnutls_priority_set: do not override the version after handshake is complete (!777) In-Reply-To: References: Message-ID: Merge Request !777 was merged Merge Request url: https://gitlab.com/gnutls/gnutls/merge_requests/777 Branches: tmp-fix-priority-set to master Author: Nikos Mavrogiannopoulos Assignee: Nikos Mavrogiannopoulos -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/777 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Oct 31 10:35:01 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 31 Oct 2018 09:35:01 +0000 Subject: [gnutls-devel] GnuTLS | gnutls_priority_set: do not override the version after handshake is complete (!777) In-Reply-To: References: Message-ID: Reassigned Merge Request 777 https://gitlab.com/gnutls/gnutls/merge_requests/777 Assignee changed to Nikos Mavrogiannopoulos -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/777 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Oct 31 10:35:02 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 31 Oct 2018 09:35:02 +0000 Subject: [gnutls-devel] GnuTLS | gnutls_priority_set: do not override the version after handshake is complete (!777) In-Reply-To: References: Message-ID: Thank you! -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/777#note_113419811 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Oct 31 11:04:14 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 31 Oct 2018 10:04:14 +0000 Subject: [gnutls-devel] GnuTLS | gnutls_priority_init: ignore CTYPE-OPENPGP options (!789) In-Reply-To: References: Message-ID: @ametzler would you like to review this? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/789#note_113427975 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Oct 31 13:46:03 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 31 Oct 2018 12:46:03 +0000 Subject: [gnutls-devel] GnuTLS | WIP: Eddsa via pkcs11 (!790) References: Message-ID: New Merge Request !790 https://gitlab.com/gnutls/gnutls/merge_requests/790 Project:Branches: simo5/gnutls:eddsa_pkcs11 to gnutls/gnutls:master Author: Simo Sorce Assignee: Add a description of the new feature/bug fix. Reference any relevant bugs. ## Checklist * [X] Code modified for feature * [X] Test suite updated with functionality tests * [ ] Test suite updated with negative tests * [ ] Documentation updated / NEWS entry present (for non-trivial changes) ## Reviewer's checklist: * [ ] Any issues marked for closing are addressed * [ ] There is a test suite reasonably covering new functionality or modifications * [ ] Function naming, parameters, return values, types, etc., are consistent and according to `CONTRIBUTION.md` * [ ] This feature/change has adequate documentation added * [ ] No obvious mistakes in the code -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/790 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Oct 31 15:12:45 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 31 Oct 2018 14:12:45 +0000 Subject: [gnutls-devel] GnuTLS | gnutls_priority_init: ignore CTYPE-OPENPGP options (!789) In-Reply-To: References: Message-ID: Tom started a new discussion on lib/priority.c: > + cert_type_priority_all); > } else if ((algo = gnutls_certificate_type_get_id > - (&broken_list[i][11])) != GNUTLS_CRT_UNKNOWN) > - { // Specific server cert type allowed > + (&broken_list[i][11])) != GNUTLS_CRT_UNKNOWN) { > + // Specific server cert type allowed > fn(&(*priority_cache)->server_ctype, algo); > } else goto error; > } else { // Symmetric certificate type > if ((algo = gnutls_certificate_type_get_id > - (&broken_list[i][7])) != GNUTLS_CRT_UNKNOWN) > - { > + (&broken_list[i][7])) != GNUTLS_CRT_UNKNOWN) { > fn(&(*priority_cache)->client_ctype, algo); > fn(&(*priority_cache)->server_ctype, algo); > + } else if (strncasecmp(&broken_list[i][1], "CTYPE-OPENPGP", 13) == 0) { I think this check should be done first, i.e. before the `&broken_list[i][7])) != GNUTLS_CRT_UNKNOWN` check. Otherwise we do not reach this second condition. `GNUTLS_CRT_OPENPGP` is not equal to `GNUTLS_CRT_UNKNOWN` and therefore we always end up in the first branch. I think this will do the trick: ``` if ((algo = gnutls_certificate_type_get_id(&broken_list[i][7])) == GNUTLS_CRT_OPENPGP) { continue; } else if (algo != GNUTLS_CRT_UNKNOWN) { //original code } ``` or nested differently: ``` if ((algo = gnutls_certificate_type_get_id(&broken_list[i][7])) != GNUTLS_CRT_UNKNOWN) { if (algo == GNUTLS_CRT_OPENPGP) { continue; } else { fn(&(*priority_cache)->client_ctype, algo); fn(&(*priority_cache)->server_ctype, algo); } } ``` BTW, untested code so please check syntax errors and stuff. It's just to give you an idea. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/789#note_113516677 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: