From jgh at wizmail.org  Tue Mar  3 13:50:12 2020
From: jgh at wizmail.org (Jeremy Harris)
Date: Tue, 3 Mar 2020 12:50:12 +0000
Subject: [gnutls-help] Error in the push function
Message-ID: <e6077f40-b034-2bb7-89c9-ac11281ba0a4@wizmail.org>

When a call returns the (somewhat generic) GNUTLS_E_PUSH_ERROR
is it legitimate to use the global errno?  Will it always be
meaningful?   Or, is there some other way to obtain more detailed
information?
-- 
Cheers,
  Jeremy


From mukrop at mail.muni.cz  Thu Mar  5 16:10:11 2020
From: mukrop at mail.muni.cz (Martin Ukrop)
Date: Thu, 5 Mar 2020 16:10:11 +0100
Subject: [gnutls-help] Improving X.509 certificate validation errors
Message-ID: <CAGSd0m+1DMGzR6KzfzHaoK65-OrnJrT7T5DrQADPsObR8YoNcA@mail.gmail.com>

Hi,

I?m the lead of a university project investigating (and improving) the
usability of certificate validation errors. Our goal is to simplify the
ecosystem by consolidating the errors and their documentation in one place,
providing replicable example certificates for all validation errors and by
explaining better what the individual errors mean. The project is live at
https://x509errors.org/

Now we are reaching out to library developers and users (you) to ask for
feedback.

Currently, we base the system on OpenSSL errors (as it?s the most common).
We have example certificates for 30+ OpenSSL errors and in-progress mapping
for corresponding errors error for OpenSSL, GnuTLS, Botan and MbedTLS.
In the future, we plan the possibility of web reorganization based on the
other libraries (currently, the web is organized by OpenSSL), adding the
error frequencies based on IP-wide scans and elaborating on the
consequences of individual errors.
Ultimately, we want to propose better (ideally user-tested) errors and
their documentation. (Just recently, we made a survey among 180 developers
regarding their error documentation preference with good reception).

As developers/users of TLS libraries, what do you think of the idea?
* Which part(s) do you find the most/least useful?
* Is there anything you see missing?
* What are your thoughts on unifying the error taxonomy? (a very long-term
goal, if at all possible)

During spring, we would like to start creating pull requests improving the
documentation and error messages in some of the libraries. Would you
welcome such contributions?

For transparency: My PhD is done at Masaryk University (Czech Republic) and
I?m partially supported by Red Hat Czech.

With regards,
Martin.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnutls-help/attachments/20200305/a983f4dd/attachment-0001.html>

From nmav at gnutls.org  Fri Mar  6 16:07:43 2020
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Fri, 6 Mar 2020 16:07:43 +0100
Subject: [gnutls-help] Improving X.509 certificate validation errors
In-Reply-To: <CAGSd0m+1DMGzR6KzfzHaoK65-OrnJrT7T5DrQADPsObR8YoNcA@mail.gmail.com>
References: <CAGSd0m+1DMGzR6KzfzHaoK65-OrnJrT7T5DrQADPsObR8YoNcA@mail.gmail.com>
Message-ID: <CAJU7za+beh4m2dV7MWLAQuKOny-+bT0OAp-pRzEq1ahwgvQsGg@mail.gmail.com>

Hi Martin,
 Would you like to move your questions to our gitlab.com site as an
issue to initiate the discussion? I am not sure all in the development
team follow this mailing list.

regards,
Nikos

On Thu, Mar 5, 2020 at 4:48 PM Martin Ukrop <mukrop at mail.muni.cz> wrote:
>
> Hi,
>
> I?m the lead of a university project investigating (and improving) the usability of certificate validation errors. Our goal is to simplify the ecosystem by consolidating the errors and their documentation in one place, providing replicable example certificates for all validation errors and by explaining better what the individual errors mean. The project is live at https://x509errors.org/
>
> Now we are reaching out to library developers and users (you) to ask for feedback.
>
> Currently, we base the system on OpenSSL errors (as it?s the most common). We have example certificates for 30+ OpenSSL errors and in-progress mapping for corresponding errors error for OpenSSL, GnuTLS, Botan and MbedTLS.
> In the future, we plan the possibility of web reorganization based on the other libraries (currently, the web is organized by OpenSSL), adding the error frequencies based on IP-wide scans and elaborating on the consequences of individual errors.
> Ultimately, we want to propose better (ideally user-tested) errors and their documentation. (Just recently, we made a survey among 180 developers regarding their error documentation preference with good reception).
>
> As developers/users of TLS libraries, what do you think of the idea?
> * Which part(s) do you find the most/least useful?
> * Is there anything you see missing?
> * What are your thoughts on unifying the error taxonomy? (a very long-term goal, if at all possible)
>
> During spring, we would like to start creating pull requests improving the documentation and error messages in some of the libraries. Would you welcome such contributions?
>
> For transparency: My PhD is done at Masaryk University (Czech Republic) and I?m partially supported by Red Hat Czech.
>
> With regards,
> Martin.
> _______________________________________________
> Gnutls-help mailing list
> Gnutls-help at lists.gnutls.org
> http://lists.gnupg.org/mailman/listinfo/gnutls-help


From mukrop at mail.muni.cz  Fri Mar  6 22:01:36 2020
From: mukrop at mail.muni.cz (Martin Ukrop)
Date: Fri, 6 Mar 2020 22:01:36 +0100
Subject: [gnutls-help] Improving X.509 certificate validation errors
In-Reply-To: <CAJU7za+beh4m2dV7MWLAQuKOny-+bT0OAp-pRzEq1ahwgvQsGg@mail.gmail.com>
References: <CAGSd0m+1DMGzR6KzfzHaoK65-OrnJrT7T5DrQADPsObR8YoNcA@mail.gmail.com>
 <CAJU7za+beh4m2dV7MWLAQuKOny-+bT0OAp-pRzEq1ahwgvQsGg@mail.gmail.com>
Message-ID: <CAGSd0m+iFu2CAE9GWAMT+dn=O=vCt3g9hDTO1M=rs+1LwXf7=A@mail.gmail.com>

Hi Nikos,

OK, I'll move it there about tomorrow ? I was not sure which place is ideal
(it's quite different in different libraries).

Thanks for the tip,
Martin.


On Fri, 6 Mar 2020 at 16:08, Nikos Mavrogiannopoulos <nmav at gnutls.org>
wrote:

> Hi Martin,
>  Would you like to move your questions to our gitlab.com site as an
> issue to initiate the discussion? I am not sure all in the development
> team follow this mailing list.
>
> regards,
> Nikos
>
> On Thu, Mar 5, 2020 at 4:48 PM Martin Ukrop <mukrop at mail.muni.cz> wrote:
> >
> > Hi,
> >
> > I?m the lead of a university project investigating (and improving) the
> usability of certificate validation errors. Our goal is to simplify the
> ecosystem by consolidating the errors and their documentation in one place,
> providing replicable example certificates for all validation errors and by
> explaining better what the individual errors mean. The project is live at
> https://x509errors.org/
> >
> > Now we are reaching out to library developers and users (you) to ask for
> feedback.
> >
> > Currently, we base the system on OpenSSL errors (as it?s the most
> common). We have example certificates for 30+ OpenSSL errors and
> in-progress mapping for corresponding errors error for OpenSSL, GnuTLS,
> Botan and MbedTLS.
> > In the future, we plan the possibility of web reorganization based on
> the other libraries (currently, the web is organized by OpenSSL), adding
> the error frequencies based on IP-wide scans and elaborating on the
> consequences of individual errors.
> > Ultimately, we want to propose better (ideally user-tested) errors and
> their documentation. (Just recently, we made a survey among 180 developers
> regarding their error documentation preference with good reception).
> >
> > As developers/users of TLS libraries, what do you think of the idea?
> > * Which part(s) do you find the most/least useful?
> > * Is there anything you see missing?
> > * What are your thoughts on unifying the error taxonomy? (a very
> long-term goal, if at all possible)
> >
> > During spring, we would like to start creating pull requests improving
> the documentation and error messages in some of the libraries. Would you
> welcome such contributions?
> >
> > For transparency: My PhD is done at Masaryk University (Czech Republic)
> and I?m partially supported by Red Hat Czech.
> >
> > With regards,
> > Martin.
> > _______________________________________________
> > Gnutls-help mailing list
> > Gnutls-help at lists.gnutls.org
> > http://lists.gnupg.org/mailman/listinfo/gnutls-help
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnutls-help/attachments/20200306/b5b9d56f/attachment.html>

From tdkuehnel at ncot.de  Tue Mar 10 12:59:37 2020
From: tdkuehnel at ncot.de (Torsten =?ISO-8859-1?Q?K=FChnel?=)
Date: Tue, 10 Mar 2020 12:59:37 +0100
Subject: [gnutls-help] Simple CA- and TLS-less secure connection possible
 with GnuTLS ?
Message-ID: <20200310125937.5e2d9b2e9b61db578fc15142@ncot.de>

Hello,

i am working the ladder from the ground up to establish a secure point
to point connection over an untrusted network like the internet.

Please correct me if i am wrong on my way. Further, please let us
ignore the global CA hierarchy for this example.

DH key exchange is a way to negotiate some crypto secrets to use in a
symmetric block or stream cipher to actually transfer encrypted
packets/bytes. The negotiated crypto secrets can not be revealed by
sniffing the unencrypted negotiation traffic involved.

Up to this point we do not know who the peer actually is. Is it a man
in the middle or our intended peer ? So we need some kind of
authentication.

We display the fingerprint of the peers private/public key pair, and
transmit it over an out of band connection for verification. Further
assume the OOB verfication succeeds.

Now we do have a secure point to point connection over an insecure
transport medium with a known peer.

How do i implement such an approach using GnuTLS? Is it at all
possible with this library, i.e. avoid TLS/CA and higher level
certificate stuff ?

I tried to reach the effect by using the following code:

	res = gnutls_priority_set_direct(
		session,
//		"SECURE128:-VERS-SSL3.0:-VERS-TLS1.0:-ARCFOUR-128:+PSK:+DHE-PSK",
//		"NONE:SECURE128:+PSK:+DHE-PSK",
//		"NONE:+SHA256:+AES-256-CCM:+DHE-PSK",
//		"NONE:+CIPHER-ALL:+KX-ALL:+MAC-ALL:+COMP-ALL:+SIGN-ALL:+CTYPE-ALL",
		&error
		);
	if (res != GNUTLS_E_SUCCESS) {
		error_exit2("gnutls_priority_set_direct() failed:", res);
	}

but with all but the first priority string uncommented i get the following error:

GnuTLS [5]: REC[0x6c0de0]: Allocating epoch #0
GnuTLS [3]: ASSERT: priority.c[gnutls_priority_set]:576
GnuTLS [3]: ASSERT: priority.c[gnutls_priority_set_direct]:1503
ERROR: gnutls_priority_set_direct() failed:, No or insufficient priorities were set.


GnuTLS is 3.5.8 on a slackware linux.

-- 
tdkuehnel at ncot.de <tdkuehnel at ncot.de>


From nicolas at babelouest.org  Mon Mar 30 00:01:09 2020
From: nicolas at babelouest.org (Nicolas Mora)
Date: Sun, 29 Mar 2020 18:01:09 -0400
Subject: [gnutls-help] Supported algorithms for JWE alg
Message-ID: <c0e3a558-4928-b34f-73d1-22509ad2f4b5@babelouest.org>

Hello,

I'm trying to implement a JSON Web Encryption (JWE [1]) library with GnuTLS.
I'm trying to figure out if all the algorithms specified in the JWA RFC
[2] can be implemented using GnuTLS.

So far, I have the following algorithm support list:

- RSA1_5: supported, using gnutls_pubkey_encrypt_data and a RSA public key
- RSA-OAEP, RSA-OAEP-256: not supported
- ECDH-ES, ECDH-ES+A128KW, ECDH-ES+A192KW, ECDH-ES+A256KW: I assume it's
supported but I wasn't able to make it work using
gnutls_pubkey_encrypt_data and a ECC public key
- A128KW, A192KW, A192KW, A128GCMKW, A192GCMKW, A256GCMKW,
PBES2-HS256+A128KW, PBES2-HS384+A192KW, PBES2-HS512+A256KW: supported,
but couldn't find how yet

Are my assumptions correct?

If so, how can I implement ECDH-ES* encryption/decryption?

Thanks in advance!

[1] - https://tools.ietf.org/html/rfc7516
[2] - https://tools.ietf.org/html/rfc7518#section-4.1


From michelbriand at free.fr  Mon Mar 30 08:24:48 2020
From: michelbriand at free.fr (Michel Briand)
Date: Mon, 30 Mar 2020 08:24:48 +0200
Subject: [gnutls-help] Simple CA- and TLS-less secure connection
 possible with GnuTLS ?
In-Reply-To: <20200310125937.5e2d9b2e9b61db578fc15142@ncot.de>
References: <20200310125937.5e2d9b2e9b61db578fc15142@ncot.de>
Message-ID: <20200330082448.7aa098f1@eridu.kheb.ignorelist.com>


Torsten K?hnel <tdkuehnel at ncot.de> - Tue, 10 Mar 2020 12:59:37 +0100

>Hello,
>
>i am working the ladder from the ground up to establish a secure point
>to point connection over an untrusted network like the internet.
>
>Please correct me if i am wrong on my way. Further, please let us
>ignore the global CA hierarchy for this example.
>
>DH key exchange is a way to negotiate some crypto secrets to use in a
>symmetric block or stream cipher to actually transfer encrypted
>packets/bytes. The negotiated crypto secrets can not be revealed by
>sniffing the unencrypted negotiation traffic involved.
>
>Up to this point we do not know who the peer actually is. Is it a man
>in the middle or our intended peer ? So we need some kind of
>authentication.
>
>We display the fingerprint of the peers private/public key pair, and
>transmit it over an out of band connection for verification. Further
>assume the OOB verfication succeeds.
>
>Now we do have a secure point to point connection over an insecure
>transport medium with a known peer.
>
>How do i implement such an approach using GnuTLS? Is it at all
>possible with this library, i.e. avoid TLS/CA and higher level
>certificate stuff ?
>
>I tried to reach the effect by using the following code:
>
>	res = gnutls_priority_set_direct(
>		session,
>//		"SECURE128:-VERS-SSL3.0:-VERS-TLS1.0:-ARCFOUR-128:+PSK:+DHE-PSK",
>//		"NONE:SECURE128:+PSK:+DHE-PSK",
>//		"NONE:+SHA256:+AES-256-CCM:+DHE-PSK",
>//		"NONE:+CIPHER-ALL:+KX-ALL:+MAC-ALL:+COMP-ALL:+SIGN-ALL:+CTYPE-ALL",
>		&error
>		);
>	if (res != GNUTLS_E_SUCCESS) {
>		error_exit2("gnutls_priority_set_direct() failed:", res);
>	}
>
>but with all but the first priority string uncommented i get the following error:
>
>GnuTLS [5]: REC[0x6c0de0]: Allocating epoch #0
>GnuTLS [3]: ASSERT: priority.c[gnutls_priority_set]:576
>GnuTLS [3]: ASSERT: priority.c[gnutls_priority_set_direct]:1503
>ERROR: gnutls_priority_set_direct() failed:, No or insufficient priorities were set.
>
>
>GnuTLS is 3.5.8 on a slackware linux.
>

Hello,

GnuTLS supported OpenPGP authentication some time ago.
I liked very much this feature.
TLS protocol works the same, but authentication takes place with a
circle of trust, instead of a hierarchy of trust.

Cheers,
Michel


From n.mavrogiannopoulos at gmail.com  Tue Mar 31 07:55:02 2020
From: n.mavrogiannopoulos at gmail.com (Nikos Mavrogiannopoulos)
Date: Tue, 31 Mar 2020 07:55:02 +0200
Subject: [gnutls-help] gnutls 3.6.13
Message-ID: <CAJU7za+xJCNhyqF0pyDSfG3waRgqXSGk1Lfr957MfA7gYQROEw@mail.gmail.com>

Hello,
 I've just released gnutls 3.6.13. This is a security and bug fix release on the
stable 3.6.x branch.

I'd like to thank everyone who contributed in this release:
Daiki Ueno, Dmitry Baryshkov, Tim R?hsen, Anderson Toshiyuki Sasaki,
Jakub Jelen, Daniel Lenski, Ander Juaristi, Dimitri John Ledkov,
Fiona Klute, Michael Catanzaro, Ross Nicholson, and Stefan B?hler.

The detailed list of changes follows; they can be seen in more detail
in our milestone tracker:
https://gitlab.com/gnutls/gnutls/-/milestones/27

* Version 3.6.13 (released 2020-03-31)

** libgnutls: Fix a DTLS-protocol regression (caused by TLS1.3
support), since 3.6.3.
   The DTLS client would not contribute any randomness to the DTLS negotiation,
   breaking the security guarantees of the DTLS protocol (#960)
   [GNUTLS-SA-2020-03-31, CVSS: high]

** libgnutls: Added new APIs to access KDF algorithms (#813).

** libgnutls: Added new callback gnutls_keylog_func that enables a custom
   logging functionality.

** libgnutls: Added support for non-null terminated usernames in PSK
   negotiation (#586).

** gnutls-cli-debug: Improved support for old servers that only support
   SSL 3.0.

** API and ABI modifications:
gnutls_hkdf_extract: Added
gnutls_hkdf_expand: Added
gnutls_pbkdf2: Added
gnutls_session_get_keylog_function: Added
gnutls_session_set_keylog_function: Added
gnutls_prf_hash_get: Added
gnutls_psk_server_get_username2: Added
gnutls_psk_set_client_credentials2: Added
gnutls_psk_set_client_credentials_function2: Added
gnutls_psk_set_server_credentials_function2: Added

Getting the Software
====================

GnuTLS may be downloaded directly from <
ftp://ftp.gnutls.org/gcrypt/gnutls/>;.
A list of GnuTLS mirrors can be found at <
http://www.gnutls.org/download.html>

Here are the XZ compressed sources:

  https://www.gnupg.org/ftp/gcrypt/gnutls/v3.6/gnutls-3.6.13.tar.xz

Here are OpenPGP detached signatures signed using key 0x96865171:

  https://www.gnupg.org/ftp/gcrypt/gnutls/v3.6/gnutls-3.6.13.tar.xz.sig

Note that it has been signed with my openpgp key:
pub   3104R/96865171 2008-05-04 [expires: 2028-04-29]
uid                  Nikos Mavrogiannopoulos <nmav <at> gnutls.org>
uid                  Nikos Mavrogiannopoulos <n.mavrogiannopoulos <at>
gmail.com>
sub   2048R/9013B842 2008-05-04 [expires: 2018-05-02]
sub   2048R/1404A91D 2008-05-04 [expires: 2018-05-02]

regards,
Nikos