From willem at nlnetlabs.nl Wed Apr 3 14:57:23 2019 From: willem at nlnetlabs.nl (Willem Toorop) Date: Wed, 3 Apr 2019 16:57:23 +0200 Subject: [getdns-users] getdns-1.5.2 and stubby-0.2.6 released Message-ID: Dear all, I am pleased to announce the new GnuTLS, bugfix and maintenance release, version 1.5.2 of getdns. This release has experimental support for GnuTLS >= 3.5.0 as replacement for OpenSSL. To enabled, use the --with-gnutls option at configure time. Note that getdns needs the gnutls-dane library too (which is used for SPKI authentication of DNS-over-TLS upstreams). DNSSEC validation will use the cryptographic functions from libnettle (the cryptographic library also used by GnuTLS). When build with GnuTLS, getdns will still be linked with libcrypto (from OpenSSL) for S/MIME verification of the root-anchors.xml file with Zero configuration DNSSEC. It is our intention to replace that with something more GnuTLS native at some point in the future too, so that getdns can do without OpenSSL altogether. Maintenance work included bringing TCP Fast Open up to par with current practice. This means that at least on Linux 4.11+, getdns can connect TFO with TLS. The most prominent bugfix is for DNSSEC scheduling which in some circumstances wrongly failed with insecure delegations of more than one label. A few more issues are resolved with this release. For a complete overview see the ChangeLog below. This release has the 0.2.6 release of Stubby included, with updates to documentation and fixes for the Windows build. link : https://getdnsapi.net/dist/getdns-1.5.2.tar.gz pgp : https://getdnsapi.net/dist/getdns-1.5.2.tar.gz.asc sha256: 1826a6a221ea9e9301f2c1f5d25f6f5588e841f08b967645bf50c53b970694c0 ChangeLog ========= * 2019-04-03: Version 1.5.2 * PR #424: Two small trust anchor fetcher fixes Thanks Maciej S. Szmigiero * Issue #422: Enable server side and update client side TCP Fast Open implementation. Thanks Craig Andrews * Issue #423: Fix insecure delegation detection while scheduling. Thanks Charles Milette * Issue #419: Escape backslashed when printing in JSON format. Thanks boB Rudis * Use GnuTLS instead of OpenSSL for TLS with the --with-gnutls option to configure. libcrypto (from OpenSSL) still needed for Zero configuration DNSSEC. * DOA rr-type * AMTRELAY rr-type Stubby ChangeLog ================ * 2019-04-03: Version 0.2.6 * Windows: use appropriate system and user configuration directories. * Windows: replace references to C:\Program Files with %PROGRAMFILES%. * Windows: use location of stubby.bat to find stubby.exe and stubby.yml. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From cm at appliedprivacy.net Wed Apr 17 11:26:00 2019 From: cm at appliedprivacy.net (Christoph) Date: Wed, 17 Apr 2019 11:26:00 +0000 Subject: [getdns-users] Does stubby honor TLSA records when verifying tls_auth_name? Message-ID: <52daf051-d7ca-0cc3-7a33-43f036d61c3a@appliedprivacy.net> Hello! we created TLSA records for our public resolvers [1] as recommended by [2]. Now we were wondering whether stubby takes TLSA records [3] into account when verifying the TLS connection to the server (tls_auth_name) - in addition to PKIX [4]? We didn't publish SPKI pins because we rotate keys - which makes SPKI less practical. The TLSA record is only on the CA level (requires the CA to be Let's Encrypt). thanks, Christoph [1] https://github.com/getdnsapi/stubby/pull/177/files [2] https://datatracker.ietf.org/doc/draft-ietf-dprive-bcp-op/?include_text=1 [3] https://tools.ietf.org/html/rfc8310#section-8.2 [4] https://tools.ietf.org/html/rfc8310#section-8.1 From cm at appliedprivacy.net Thu Apr 18 17:40:00 2019 From: cm at appliedprivacy.net (Christoph) Date: Thu, 18 Apr 2019 17:40:00 +0000 Subject: [getdns-users] Does stubby honor TLSA records when verifying tls_auth_name? In-Reply-To: <52daf051-d7ca-0cc3-7a33-43f036d61c3a@appliedprivacy.net> References: <52daf051-d7ca-0cc3-7a33-43f036d61c3a@appliedprivacy.net> Message-ID: <0e1e079e-f84a-0f4a-8a53-fa2a7ef19d1f@appliedprivacy.net> > We didn't publish SPKI pins because we rotate keys - which makes > SPKI less practical. After noticing that the pin can also be at the CA level we will provide SPKI pins. The DANE/TLSA question for Stubby would still be interesting since that would allow us to manage the "pins" without changing the configuration. thanks, Christoph From sara at sinodun.com Mon Apr 29 14:51:22 2019 From: sara at sinodun.com (Sara Dickinson) Date: Mon, 29 Apr 2019 15:51:22 +0100 Subject: [getdns-users] Does stubby honor TLSA records when verifying tls_auth_name? In-Reply-To: <0e1e079e-f84a-0f4a-8a53-fa2a7ef19d1f@appliedprivacy.net> References: <52daf051-d7ca-0cc3-7a33-43f036d61c3a@appliedprivacy.net> <0e1e079e-f84a-0f4a-8a53-fa2a7ef19d1f@appliedprivacy.net> Message-ID: > On 18 Apr 2019, at 18:40, Christoph wrote: > >> We didn't publish SPKI pins because we rotate keys - which makes >> SPKI less practical. > > After noticing that the pin can also be at the CA level we > will provide SPKI pins. The DANE/TLSA question for Stubby > would still be interesting since that would allow us to > manage the "pins" without changing the configuration. Hi Christoph, The current version of Stubby doesn?t implement verification using TLSA records, but it is on the roadmap for a future version. Best regards Sara. From willem at nlnetlabs.nl Wed Apr 3 14:57:26 2019 From: willem at nlnetlabs.nl (Willem Toorop) Date: Wed, 3 Apr 2019 16:57:26 +0200 Subject: [getdns-api] getdns-1.5.2 and stubby-0.2.6 released Message-ID: Dear all, I am pleased to announce the new GnuTLS, bugfix and maintenance release, version 1.5.2 of getdns. This release has experimental support for GnuTLS >= 3.5.0 as replacement for OpenSSL. To enabled, use the --with-gnutls option at configure time. Note that getdns needs the gnutls-dane library too (which is used for SPKI authentication of DNS-over-TLS upstreams). DNSSEC validation will use the cryptographic functions from libnettle (the cryptographic library also used by GnuTLS). When build with GnuTLS, getdns will still be linked with libcrypto (from OpenSSL) for S/MIME verification of the root-anchors.xml file with Zero configuration DNSSEC. It is our intention to replace that with something more GnuTLS native at some point in the future too, so that getdns can do without OpenSSL altogether. Maintenance work included bringing TCP Fast Open up to par with current practice. This means that at least on Linux 4.11+, getdns can connect TFO with TLS. The most prominent bugfix is for DNSSEC scheduling which in some circumstances wrongly failed with insecure delegations of more than one label. A few more issues are resolved with this release. For a complete overview see the ChangeLog below. This release has the 0.2.6 release of Stubby included, with updates to documentation and fixes for the Windows build. link : https://getdnsapi.net/dist/getdns-1.5.2.tar.gz pgp : https://getdnsapi.net/dist/getdns-1.5.2.tar.gz.asc sha256: 1826a6a221ea9e9301f2c1f5d25f6f5588e841f08b967645bf50c53b970694c0 ChangeLog ========= * 2019-04-03: Version 1.5.2 * PR #424: Two small trust anchor fetcher fixes Thanks Maciej S. Szmigiero * Issue #422: Enable server side and update client side TCP Fast Open implementation. Thanks Craig Andrews * Issue #423: Fix insecure delegation detection while scheduling. Thanks Charles Milette * Issue #419: Escape backslashed when printing in JSON format. Thanks boB Rudis * Use GnuTLS instead of OpenSSL for TLS with the --with-gnutls option to configure. libcrypto (from OpenSSL) still needed for Zero configuration DNSSEC. * DOA rr-type * AMTRELAY rr-type Stubby ChangeLog ================ * 2019-04-03: Version 0.2.6 * Windows: use appropriate system and user configuration directories. * Windows: replace references to C:\Program Files with %PROGRAMFILES%. * Windows: use location of stubby.bat to find stubby.exe and stubby.yml. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: