Bug#733295: gnutls-bin: please compile GnuTLS with DANE support

[Andreas Metzler]

On 2016-11-02 "brian m. carlson"  wrote:
> libunbound2 1.5.10-1, which links against nettle instead of openssl, has
> been uploaded to unstable.  It should now be possible for gnutls to
> depend on libunbound2 if necessary.
[...]

Thanks for the heads-up.

cu Andreas

-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'

Bug#733295: gnutls-bin: please compile GnuTLS with DANE support

[brian m. carlson]

libunbound2 1.5.10-1, which links against nettle instead of openssl, has
been uploaded to unstable.  It should now be possible for gnutls to
depend on libunbound2 if necessary.
-- 
brian m. carlson / brian with sandals: Houston, Texas, US
+1 832 623 2791 | https://www.crustytoothpaste.net/~bmc | My opinion only
OpenPGP: https://keybase.io/bk2204


signature.asc
Description: PGP signature

Bug#733295: gnutls-bin: please compile GnuTLS with DANE support

[Luca Bruno]

On Tue, 24 Mar 2015 23:11:51 +0100 Cyril Brulebois  wrote:

> > >  3. Yet another way might be to teach unbound to support GnuTLS in
> > > addition to OpenSSL and NSS, so that one can build a GnuTLS variant
> > > instead of an NSS one.
 
> > option 3 would require probably using nettle as well as gnutls (for the
> > dnssec client verification) -- i'm not sure what sort of twisty maze of
> > dependencies or build-dependencies this creates, though :)
> 
> Oh, nettle is an old friend (we use it as a sha1 implementation in
> xserver-xorg-core-udeb).

> > libunbound should only depend on libssl for the purposes of outbound
> > DNS-over-TLS-over-TCP connections, right?  the DNSSEC verification work
> > only needs to use libcrypto (or nettle, if we were to port it, which
> > would avoid the circularity).
> 
> I really don't know. You can pretend somebody jumped on me asking
> whether I was part of Debian and mentioned this issue that has been
> tagged wontfix. That wouldn't be very far from what happened. ;)
> 
> I can add nettlifying unbound to my ever growing to-do list, and see
> what codepaths are involved there. Maybe someone even did that work
> upstream already, I didn't check yet.

I went ahead and coded the "nettlify libunbound" part, which is basically
option 3 proposed above.
I run this through upstream and they merged it today:
https://www.nlnetlabs.nl/bugs-script/show_bug.cgi?id=594

This changes only touch libunbound (and the testcases) to build with nettle,
while the rest of unbound still needs openssl or NSS (mostly for TLS).

Cheers, Luca

-- 
 .''`.  ** Debian GNU/Linux **  | Luca Bruno (kaeso)
: :'  :   The Universal O.S.| lucab (AT) debian.org
`. `'`  | GPG: 0xBB1A3A854F3BBEBF
  `- http://www.debian.org  | Debian GNU/Linux Developer


signature.asc
Description: This is a digitally signed message part.

Bug#733295: gnutls-bin: please compile GnuTLS with DANE support

[Nikos Mavrogiannopoulos]

On Tue, 2015-11-17 at 14:40 +0100, Luca Bruno wrote:

> > I really don't know. You can pretend somebody jumped on me asking
> > whether I was part of Debian and mentioned this issue that has been
> > tagged wontfix. That wouldn't be very far from what happened. ;)
> > 
> > I can add nettlifying unbound to my ever growing to-do list, and 
> > see
> > what codepaths are involved there. Maybe someone even did that work
> > upstream already, I didn't check yet.
> 
> I went ahead and coded the "nettlify libunbound" part, which is 
> basically
> option 3 proposed above.
> I run this through upstream and they merged it today:
> https://www.nlnetlabs.nl/bugs-script/show_bug.cgi?id=594
> 
> This changes only touch libunbound (and the testcases) to build with 
> nettle,
> while the rest of unbound still needs openssl or NSS (mostly for 
> TLS).

Luca, thank you for pursuing that.

regards,
Nikos

Bug#733295: gnutls-bin: please compile GnuTLS with DANE support

[Daniel Kahn Gillmor]

On Tue 2015-11-17 08:40:58 -0500, Luca Bruno wrote:
> I went ahead and coded the "nettlify libunbound" part, which is basically
> option 3 proposed above.
> I run this through upstream and they merged it today:
> https://www.nlnetlabs.nl/bugs-script/show_bug.cgi?id=594

Thank you, Luca.  This is great.

> This changes only touch libunbound (and the testcases) to build with nettle,
> while the rest of unbound still needs openssl or NSS (mostly for TLS).

Sure, i think that's a different set of concerns that we can deal with
separately.

--dkg

Bug#733295: gnutls-bin: please compile GnuTLS with DANE support

[Cyril Brulebois]

Hello people,

Daniel Kahn Gillmor d...@fifthhorseman.net (2015-03-24):
 On Tue 2015-03-24 16:01:20 -0500, Cyril Brulebois wrote:
  (Background: This issue has just been pointed out to me after a GNUnet
  conference. At least one developer there is interested in seeing a fix
  reach the archive.)
 
   1. Not having looked too much at unbound yet, it seems to indeed
  support NSS instead of OpenSSL, so one might think about switching
  to it to get rid of (possible) OpenSSL license incompatibilities.
 
   2. A softer way might be to build an NSS variant of the unbound library
  alongside with the OpenSSL (current/default) one, so that packages
  like GnuTLS can pull it instead, and deliver DANE support.
 
   3. Yet another way might be to teach unbound to support GnuTLS in
  addition to OpenSSL and NSS, so that one can build a GnuTLS variant
  instead of an NSS one.
 
  Solution 1 seems harsh and could possibly break rdepends; solution 2
  seems safer and only a (small?) matter of packaging; solution 3 might
  involve some bits of coding, and might cause tests entanglements in
  configure.ac.
 
  Thoughts? Should I look into patching unbound to support solution 2?
 
 I think option 2 is the simplest, shortest-path option for now, though
 the idea that installing libgnutls28 brings in libnss3 as a dependency
 seems rather ugly to me.

so I've spent a few moments trying to get stuff to build and see how it
goes. I'm particularly unimpressed with the resulting patches, but they
might at least be useful to someone who would like to try a bit harder
to get stuff into shape, and/or who would like to toy around locally.

The unbound patch introduces an NSS variant of libunbound, which I didn't
try to make co-installable along with the regular one.

The gnutls28 patch enables libdane, which in turn depends on the NSS
variant of libunbound. I'm not sure how much it would take to make this
package optional (so that gnutls28 doesn't pull it and NSS along by
default, yet letting users install it if they so wish).

The end result is error messages while trying to validate the domain
mentioned at the beginning of this bug report (www.nic.cz)… at the
moment, besides installing the resulting binary packages, I had to copy
/usr/share/dns/root.key under /etc/unbound/
| $ danetool --check=www.nic.cz
| Querying DNS for www.nic.cz (tcp:443)...
| [1428519378] libunbound[7678:0] error: PK11_GenerateRandom error: Unknown 
code ___f 65
| [1428519378] libunbound[7678:0] error: PK11_GenerateRandom error: Unknown 
code ___f 65
| [1428519378] libunbound[7678:0] error: PK11_GenerateRandom error: Unknown 
code ___f 65
| [1428519378] libunbound[7678:0] error: PK11_GenerateRandom error: Unknown 
code ___f 65
| [1428519378] libunbound[7678:0] error: PK11_GenerateRandom error: Unknown 
code ___f 65
| [1428519378] libunbound[7678:0] error: PK11_GenerateRandom error: Unknown 
code ___f 65
| [1428519378] libunbound[7678:0] error: PK11_GenerateRandom error: Unknown 
code ___f 65
| [1428519378] libunbound[7678:0] error: PK11_GenerateRandom error: Unknown 
code ___f 65
| [1428519378] libunbound[7678:0] error: PK11_GenerateRandom error: Unknown 
code ___f 65
| [1428519378] libunbound[7678:0] error: PK11_GenerateRandom error: Unknown 
code ___f 65
| [1428519378] libunbound[7678:0] error: PK11_GenerateRandom error: Unknown 
code ___f 65
| [1428519378] libunbound[7678:0] error: PK11_GenerateRandom error: Unknown 
code ___f 65
| [1428519378] libunbound[7678:0] error: PK11_GenerateRandom error: Unknown 
code ___f 65
| [1428519378] libunbound[7678:0] error: PK11_GenerateRandom error: Unknown 
code ___f 65
| [1428519378] libunbound[7678:0] error: PK11_GenerateRandom error: Unknown 
code ___f 65
| [1428519378] libunbound[7678:0] error: PK11_GenerateRandom error: Unknown 
code ___f 65
| [1428519378] libunbound[7678:0] error: PK11_GenerateRandom error: Unknown 
code ___f 65
| [1428519378] libunbound[7678:0] error: PK11_GenerateRandom error: Unknown 
code ___f 65
| [1428519378] libunbound[7678:0] error: PK11_GenerateRandom error: Unknown 
code ___f 65
| [1428519378] libunbound[7678:0] error: PK11_GenerateRandom error: Unknown 
code ___f 65
| [1428519378] libunbound[7678:0] error: PK11_GenerateRandom error: Unknown 
code ___f 65
| [1428519378] libunbound[7678:0] error: PK11_GenerateRandom error: Unknown 
code ___f 65
| [1428519378] libunbound[7678:0] error: PK11_GenerateRandom error: Unknown 
code ___f 65
| [1428519378] libunbound[7678:0] error: PK11_GenerateRandom error: Unknown 
code ___f 65
| [1428519378] libunbound[7678:0] error: PK11_GenerateRandom error: Unknown 
code ___f 65
| [1428519378] libunbound[7678:0] error: PK11_GenerateRandom error: Unknown 
code ___f 65
| [1428519378] libunbound[7678:0] error: PK11_GenerateRandom error: Unknown 
code ___f 65
| [1428519378] libunbound[7678:0] error: PK11_GenerateRandom error: Unknown 
code ___f 65
| [1428519378] libunbound[7678:0] error: PK11_GenerateRandom error: Unknown 
code ___f 65

Bug#733295: gnutls-bin: please compile GnuTLS with DANE support

[Nikos Mavrogiannopoulos]

On Tue, 2015-03-24 at 18:52 -0400, Robert Edmonds wrote:

  4. Design and implement a D-Bus interface for securely retrieving
 DNSSEC-validated records that have been validated *on the system*.
 Patch daemons (Unbound, BIND, et al) to answer to this interface.
 Patch clients (libdane, et al) to request records using this
 interface.
 
 This is sort of analogous to the security you would get in having a
 plain validating DNS server listening on localhost and a nameserver
 127.0.0.1 line (and no others) in /etc/resolv.conf and requiring the
 AD bit in responses, but the big advantage would be that the security
 guarantee from doing DNSSEC validation directly on the endpoint is
 guaranteed by the definition of the interface, and not from the
 happenstance of local configuration.
 This would:
 
  * Avoid licensing issues.
  
  * Avoid extra TLS/crypto related library dependencies in clients.
 
  * Allow other validators that are not written in the form of a library
(e.g., BIND, PowerDNS) to be used with clients that need
DNSSEC-secured answers.  And for validators that do have a library
API, do you really want to have each client have its own #ifdef mess
to support multiple APIs?
 
  * Allow system-wide, not just process-wide caching.  (Even if your
direct-libunbound client is pointed at a resolver on 127.0.0.1 that
has the answers in cache, it still may need to do many send/recv
system calls to obtain each needed record, because DNS can only
return one answer at a time per query/response.)
 
  * Insulate the client from needing to know how to configure the
DNSSEC-lookup library.  (E.g., remote DNS servers, trust anchors,
etc.)

Hi,
 The D-BUS interface is not really necessary because DNS provides
already this functionality. What we need is a convention for
applications in the system to discover the local trusted (for dnssec)
nameservers. 

My attempt to use c-ares for dnssec resolving would have the same effect
as the ones you mention and is much cleaner and straightforward than
D-BUS. However, it is blocked by the fact that there is no commonly
acceptable convention for reading the trusted nameservers. My current
solution was to use /etc/resolv-sec.conf, but it is pretty much
arbitrary and that's why c-ares upstream blocked it. If Debian would set
such a convention, I think it would allow software use DNSSEC easier.

https://github.com/bagder/c-ares/pulls

regards,
Nikos


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#733295: gnutls-bin: please compile GnuTLS with DANE support

[Robert Edmonds]

Hi, Nikos:

Nikos Mavrogiannopoulos wrote:
  The D-BUS interface is not really necessary because DNS provides
 already this functionality. What we need is a convention for
 applications in the system to discover the local trusted (for dnssec)
 nameservers. 

What do you mean by local?  A nameserver listening on localhost, or
only a nameserver on the local network?

 My attempt to use c-ares for dnssec resolving would have the same effect
 as the ones you mention and is much cleaner and straightforward than
 D-BUS. However, it is blocked by the fact that there is no commonly
 acceptable convention for reading the trusted nameservers. My current
 solution was to use /etc/resolv-sec.conf, but it is pretty much
 arbitrary and that's why c-ares upstream blocked it. If Debian would set
 such a convention, I think it would allow software use DNSSEC easier.
 
 https://github.com/bagder/c-ares/pulls

If I understand this pull request correctly, it only checks that the AD
bit is set in responses; in the language of RFC 4033, that makes this a
Non-Validating Security-Aware Stub Resolver.

libunbound, OTOH, is a Validating Stub Resolver (it can also do full
recursion if no forwarders are configured).  A tool that uses libunbound
can guarantee that the result is cryptographically authentic, to the
limits of the integrity of the local system.

So, I disagree with you if you are saying that trusting the AD bit
without validating from a nameserver on the local network (even if it
has been marked as trusted by local policy) has the same effect as
validating on the endpoint (whether it be by a trusted process or by a
nameserver bound to a privileged port, etc.).

Maybe better than a D-BUS service would be DNS transport over an
AF_LOCAL / SOCK_DGRAM socket; that can also guarantee that validation
happens on the local system by a trusted process.

Though, I wonder why danetool / libdane must perform the DNS lookup
itself.  Couldn't it also have an interface for accepting fetched TLSA
records that have already been validated by an external tool?  (I see
that it can fetch certificates from remote servers, too, so I guess it
wants to be an all-in-one tool.)  E.g., unbound-host can securely fetch
TLSA records:

$ unbound-host -v -f /usr/share/dns/root.key -t TLSA _443._tcp.www.nic.cz
_443._tcp.www.nic.cz has TLSA record 3 1 1 
AA7B93DAAB084536530BD3256E9CEFF4557CB43512640F7AB64487DC9CA14FAB (secure)
$

Also, unrelated to this discussion, I notice that gnutls hardcodes the
path to the root trust anchor file at compile time:

AC_ARG_WITH(unbound-root-key-file, 
AS_HELP_STRING([--with-unbound-root-key-file],
 [specify the unbound root key file]),
unbound_root_key_file=$withval,
if test $have_win = yes; then
unbound_root_key_file=C:\\Program Files\\Unbound\\root.key
else
if test -f /var/lib/unbound/root.key;then
unbound_root_key_file=/var/lib/unbound/root.key
else
unbound_root_key_file=/etc/unbound/root.key
fi
fi
)

This is not right; a buildd environment won't have a running unbound
daemon and thus won't have a /var/lib/unbound/root.key file, and
/etc/unbound/root.key won't normally exist on a Debian system.  (There
is a package in Debian that ships the root trust anchor, though:
dns-root-data.)

-- 
Robert Edmonds
edmo...@debian.org


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#733295: gnutls-bin: please compile GnuTLS with DANE support

[Ondřej Surý]

Hey,

Robert pointed out this bug to me, so let me have some comments:

1. getdns is better suited as a general API to use in third part
applications.

Although right now it links with libunbound, so it suffers from same
licensing problems as pure libunbound, but the API is more general, so
there might be different implementations of getdns API in the future.
Well, perhaps not so far future, since we plan to release getdns API as
a part of Knot DNS Resolver.

2. In any case, please use trust anchor from dns-root-data package. I
really don't want to chase all places around to be updated when root KSK
is rolled.

Cheers,
-- 
Ondřej Surý ond...@sury.org
Knot DNS (https://www.knot-dns.cz/) – a high-performance DNS server


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#733295: gnutls-bin: please compile GnuTLS with DANE support

[Nikos Mavrogiannopoulos]

On Wed, 2015-03-25 at 14:00 -0400, Robert Edmonds wrote:

   The D-BUS interface is not really necessary because DNS provides
  already this functionality. What we need is a convention for
  applications in the system to discover the local trusted (for dnssec)
  nameservers. 
 What do you mean by local?  A nameserver listening on localhost, or
 only a nameserver on the local network?

It depends how the network is organized. It can be a server on the
localhost, a server on a different VM, or container. That is system
policy applications cannot and should not enforce.

 If I understand this pull request correctly, it only checks that the AD
 bit is set in responses; in the language of RFC 4033, that makes this a
 Non-Validating Security-Aware Stub Resolver.
 libunbound, OTOH, is a Validating Stub Resolver (it can also do full
 recursion if no forwarders are configured).  A tool that uses libunbound
 can guarantee that the result is cryptographically authentic, to the
 limits of the integrity of the local system.

That's the same guarantee of you connect to unbound via localhost. It is
no different than connecting via unix sockets or using the API of
libunbound.

 So, I disagree with you if you are saying that trusting the AD bit
 without validating from a nameserver on the local network (even if it
 has been marked as trusted by local policy) has the same effect as
 validating on the endpoint (whether it be by a trusted process or by a
 nameserver bound to a privileged port, etc.).
 Maybe better than a D-BUS service would be DNS transport over an
 AF_LOCAL / SOCK_DGRAM socket; that can also guarantee that validation
 happens on the local system by a trusted process.

I don't see any difference of AF_LOCAL with the loopback interface.

regards,
Nikos


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#733295: gnutls-bin: please compile GnuTLS with DANE support

[Robert Edmonds]

Nikos Mavrogiannopoulos wrote:
 On Wed, 2015-03-25 at 14:00 -0400, Robert Edmonds wrote:
 
The D-BUS interface is not really necessary because DNS provides
   already this functionality. What we need is a convention for
   applications in the system to discover the local trusted (for dnssec)
   nameservers. 
  What do you mean by local?  A nameserver listening on localhost, or
  only a nameserver on the local network?
 
 It depends how the network is organized. It can be a server on the
 localhost, a server on a different VM, or container.

How does a server on a different VM count as local, even if running on
the same chassis?  (Also, you do exclude across a physical LAN/WLAN/etc.
from your definition of local, right?  Just making sure.)

 That is system policy applications cannot and should not enforce.

I disagree.  What's the use case for easily allowing, as a configurable
policy, delegating an application's cryptographic validation to a server
that may be off-host?

  If I understand this pull request correctly, it only checks that the AD
  bit is set in responses; in the language of RFC 4033, that makes this a
  Non-Validating Security-Aware Stub Resolver.
  libunbound, OTOH, is a Validating Stub Resolver (it can also do full
  recursion if no forwarders are configured).  A tool that uses libunbound
  can guarantee that the result is cryptographically authentic, to the
  limits of the integrity of the local system.
 
 That's the same guarantee of you connect to unbound via localhost. It is
 no different than connecting via unix sockets or using the API of
 libunbound.

I agree that non-validating stub resolution via localhost or AF_LOCAL to
a validating server running on the same host is the same guarantee as
calling libunbound -- validation takes place on-host, if not in the same
process, then by a privileged process running on the same host.

But your c-ares pull requests (#20, #21, #22) don't guarantee that
validation takes place on-host (i.e., via localhost/loopback).

  So, I disagree with you if you are saying that trusting the AD bit
  without validating from a nameserver on the local network (even if it
  has been marked as trusted by local policy) has the same effect as
  validating on the endpoint (whether it be by a trusted process or by a
  nameserver bound to a privileged port, etc.).
  Maybe better than a D-BUS service would be DNS transport over an
  AF_LOCAL / SOCK_DGRAM socket; that can also guarantee that validation
  happens on the local system by a trusted process.
 
 I don't see any difference of AF_LOCAL with the loopback interface.

Nor do I, but there is no guarantee that servers listed in resolv.conf
(or resolv-sec.conf) are on the loopback interface.

-- 
Robert Edmonds
edmo...@debian.org


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#733295: gnutls-bin: please compile GnuTLS with DANE support

[Nikos Mavrogiannopoulos]

On Wed, 2015-03-25 at 18:19 -0400, Robert Edmonds wrote:

 How does a server on a different VM count as local, even if running on
 the same chassis?  (Also, you do exclude across a physical LAN/WLAN/etc.
 from your definition of local, right?  Just making sure.)

You could run multiple validating servers on the same hardware if you
like. But it is not up to you to impose this decision to everyone else.
That's up to local policy to decide.

[...]

   So, I disagree with you if you are saying that trusting the AD bit
   without validating from a nameserver on the local network (even if it
   has been marked as trusted by local policy) has the same effect as
   validating on the endpoint (whether it be by a trusted process or by a
   nameserver bound to a privileged port, etc.).
   Maybe better than a D-BUS service would be DNS transport over an
   AF_LOCAL / SOCK_DGRAM socket; that can also guarantee that validation
   happens on the local system by a trusted process.
  
  I don't see any difference of AF_LOCAL with the loopback interface.
 
 Nor do I, but there is no guarantee that servers listed in resolv.conf
 (or resolv-sec.conf) are on the loopback interface.

I really cannot understand what point are you trying to make, and it is
irrelevant to the issue anyway. What guarantee do you have that the
AF_LOCAL interface is not forwarded to some other host for verification?
What about the API? How are you sure it is not an API compatible library
which uses RPC to validate the replies? In all the cases the
administrator can degrade, or even disable security if he wants to.
Pretending that using an API or AF_LOCAL is better to protect from that
is a fallacy.

regards,
Nikos


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#733295: gnutls-bin: please compile GnuTLS with DANE support

[Robert Edmonds]

Hi,

Cyril Brulebois wrote:
 James Cloos cl...@jhcloos.com (2013-12-29):
   AM == Andreas Metzler ametz...@bebt.de writes:
  
  AM libdane requires and links against libunbound. libunbound OTOH
  AM is linked against OpenSSL's libssl on Debian[1].
  
  A possible way forward is to configure unbound --with-nss, which
  should provide license compatibility for all libunbound users.
 
 (Background: This issue has just been pointed out to me after a GNUnet
 conference. At least one developer there is interested in seeing a fix
 reach the archive.)
 
  1. Not having looked too much at unbound yet, it seems to indeed
 support NSS instead of OpenSSL, so one might think about switching
 to it to get rid of (possible) OpenSSL license incompatibilities.

With my unbound maintainer hat on, I would only want to switch Unbound
from OpenSSL to NSS if this were considered a production-ready
configuration supported by upstream.  (I haven't researched whether this
is the case, but I suspect the NSS option has gotten substantially less
testing than the OpenSSL default.)

  2. A softer way might be to build an NSS variant of the unbound library
 alongside with the OpenSSL (current/default) one, so that packages
 like GnuTLS can pull it instead, and deliver DANE support.

Hm, possibly.

FWIW, IIRC Unbound needs OpenSSL for three different reasons:

 * libssl: In the unbound daemon, TLS is used to protect the
   communication between unbound-control and the unbound server.
   However, this is only really useful for unbound-control running on a
   remote host.  (Recent versions of unbound support an AF_LOCAL socket
   for the control socket, though I can't remember if it is still
   TLS-protected for some reason or not.)

 * libssl: In the unbound daemon and libunbound, too (I think), there is
   support for an ssl-upstream option that forwards queries to a
   remote Unbound server running with the ssl-port option.  This is an
   Unbound-specific transport option (I don't think any other DNS
   servers support it), not part of the real DNS protocol.

 * libcrypto: For doing the actual DNSSEC validation crypto operations.

If the ssl-upstream feature were somehow hacked out of libunbound (but
not necessarily the Unbound server itself), would it help?  Then there
would only be a libcrypto dependency, and maybe that is more manageable
to replace?

See also:

https://www.nlnetlabs.nl/bugs-script/show_bug.cgi?id=594

  3. Yet another way might be to teach unbound to support GnuTLS in
 addition to OpenSSL and NSS, so that one can build a GnuTLS variant
 instead of an NSS one.

By 'unbound', do you mean the Unbound server, or libunbound?

And what do you make of this comment on upstream bug #594:

The other option would be to add support GnuTLS but then you have a
circular dependency preventing libgnutls-dane from ever being merged
into libgnutls.

 Solution 1 seems harsh and could possibly break rdepends; solution 2
 seems safer and only a (small?) matter of packaging; solution 3 might
 involve some bits of coding, and might cause tests entanglements in
 configure.ac.
 
 Thoughts? Should I look into patching unbound to support solution 2?

There is also a solution 4:

 4. Design and implement a D-Bus interface for securely retrieving
DNSSEC-validated records that have been validated *on the system*.
Patch daemons (Unbound, BIND, et al) to answer to this interface.
Patch clients (libdane, et al) to request records using this
interface.

This is sort of analogous to the security you would get in having a
plain validating DNS server listening on localhost and a nameserver
127.0.0.1 line (and no others) in /etc/resolv.conf and requiring the
AD bit in responses, but the big advantage would be that the security
guarantee from doing DNSSEC validation directly on the endpoint is
guaranteed by the definition of the interface, and not from the
happenstance of local configuration.

This would:

 * Avoid licensing issues.
 
 * Avoid extra TLS/crypto related library dependencies in clients.

 * Allow other validators that are not written in the form of a library
   (e.g., BIND, PowerDNS) to be used with clients that need
   DNSSEC-secured answers.  And for validators that do have a library
   API, do you really want to have each client have its own #ifdef mess
   to support multiple APIs?

 * Allow system-wide, not just process-wide caching.  (Even if your
   direct-libunbound client is pointed at a resolver on 127.0.0.1 that
   has the answers in cache, it still may need to do many send/recv
   system calls to obtain each needed record, because DNS can only
   return one answer at a time per query/response.)

 * Insulate the client from needing to know how to configure the
   DNSSEC-lookup library.  (E.g., remote DNS servers, trust anchors,
   etc.)

That is substantially more work, though.

-- 
Robert Edmonds
edmo...@debian.org


-- 
To UNSUBSCRIBE, email to 

Bug#733295: gnutls-bin: please compile GnuTLS with DANE support

[Cyril Brulebois]

Hi,

Daniel Kahn Gillmor d...@fifthhorseman.net (2015-03-24):
 On Tue 2015-03-24 16:01:20 -0500, Cyril Brulebois wrote:
  (Background: This issue has just been pointed out to me after a GNUnet
  conference. At least one developer there is interested in seeing a fix
  reach the archive.)
 
   1. Not having looked too much at unbound yet, it seems to indeed
  support NSS instead of OpenSSL, so one might think about switching
  to it to get rid of (possible) OpenSSL license incompatibilities.
 
   2. A softer way might be to build an NSS variant of the unbound library
  alongside with the OpenSSL (current/default) one, so that packages
  like GnuTLS can pull it instead, and deliver DANE support.
 
   3. Yet another way might be to teach unbound to support GnuTLS in
  addition to OpenSSL and NSS, so that one can build a GnuTLS variant
  instead of an NSS one.
 
  Solution 1 seems harsh and could possibly break rdepends; solution 2
  seems safer and only a (small?) matter of packaging; solution 3 might
  involve some bits of coding, and might cause tests entanglements in
  configure.ac.
 
  Thoughts? Should I look into patching unbound to support solution 2?
 
 I think option 2 is the simplest, shortest-path option for now, though
 the idea that installing libgnutls28 brings in libnss3 as a dependency
 seems rather ugly to me.

I can understand the feeling. I can work on this somewhen after D-I
Jessie RC2 is out (hopefully this week).

 option 3 would require probably using nettle as well as gnutls (for the
 dnssec client verification) -- i'm not sure what sort of twisty maze of
 dependencies or build-dependencies this creates, though :)

Oh, nettle is an old friend (we use it as a sha1 implementation in
xserver-xorg-core-udeb).

About the “twisty maze” I was thinking about GOST and ECDSA disabling
code in configure.ac, which depends on whether NSS is in use. Nothing
dramatic though.

  http://sources.debian.net/src/unbound/1.4.22-3/configure.ac/#L703-L746

 libunbound should only depend on libssl for the purposes of outbound
 DNS-over-TLS-over-TCP connections, right?  the DNSSEC verification work
 only needs to use libcrypto (or nettle, if we were to port it, which
 would avoid the circularity).

I really don't know. You can pretend somebody jumped on me asking
whether I was part of Debian and mentioned this issue that has been
tagged wontfix. That wouldn't be very far from what happened. ;)

I can add nettlifying unbound to my ever growing to-do list, and see
what codepaths are involved there. Maybe someone even did that work
upstream already, I didn't check yet.

Also, thanks for the swift reply.

Mraw,
KiBi.


signature.asc
Description: Digital signature

Bug#733295: gnutls-bin: please compile GnuTLS with DANE support

[Daniel Kahn Gillmor]

On Tue 2015-03-24 16:01:20 -0500, Cyril Brulebois wrote:
 (Background: This issue has just been pointed out to me after a GNUnet
 conference. At least one developer there is interested in seeing a fix
 reach the archive.)

  1. Not having looked too much at unbound yet, it seems to indeed
 support NSS instead of OpenSSL, so one might think about switching
 to it to get rid of (possible) OpenSSL license incompatibilities.

  2. A softer way might be to build an NSS variant of the unbound library
 alongside with the OpenSSL (current/default) one, so that packages
 like GnuTLS can pull it instead, and deliver DANE support.

  3. Yet another way might be to teach unbound to support GnuTLS in
 addition to OpenSSL and NSS, so that one can build a GnuTLS variant
 instead of an NSS one.

 Solution 1 seems harsh and could possibly break rdepends; solution 2
 seems safer and only a (small?) matter of packaging; solution 3 might
 involve some bits of coding, and might cause tests entanglements in
 configure.ac.

 Thoughts? Should I look into patching unbound to support solution 2?

I think option 2 is the simplest, shortest-path option for now, though
the idea that installing libgnutls28 brings in libnss3 as a dependency
seems rather ugly to me.

option 3 would require probably using nettle as well as gnutls (for the
dnssec client verification) -- i'm not sure what sort of twisty maze of
dependencies or build-dependencies this creates, though :)

libunbound should only depend on libssl for the purposes of outbound
DNS-over-TLS-over-TCP connections, right?  the DNSSEC verification work
only needs to use libcrypto (or nettle, if we were to port it, which
would avoid the circularity).

  --dkg


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#733295: gnutls-bin: please compile GnuTLS with DANE support

[Cyril Brulebois]

Hi,

James Cloos cl...@jhcloos.com (2013-12-29):
  AM == Andreas Metzler ametz...@bebt.de writes:
 
 AM libdane requires and links against libunbound. libunbound OTOH
 AM is linked against OpenSSL's libssl on Debian[1].
 
 A possible way forward is to configure unbound --with-nss, which
 should provide license compatibility for all libunbound users.

(Background: This issue has just been pointed out to me after a GNUnet
conference. At least one developer there is interested in seeing a fix
reach the archive.)

 1. Not having looked too much at unbound yet, it seems to indeed
support NSS instead of OpenSSL, so one might think about switching
to it to get rid of (possible) OpenSSL license incompatibilities.

 2. A softer way might be to build an NSS variant of the unbound library
alongside with the OpenSSL (current/default) one, so that packages
like GnuTLS can pull it instead, and deliver DANE support.

 3. Yet another way might be to teach unbound to support GnuTLS in
addition to OpenSSL and NSS, so that one can build a GnuTLS variant
instead of an NSS one.

Solution 1 seems harsh and could possibly break rdepends; solution 2
seems safer and only a (small?) matter of packaging; solution 3 might
involve some bits of coding, and might cause tests entanglements in
configure.ac.

Thoughts? Should I look into patching unbound to support solution 2?


Mraw,
KiBi.


signature.asc
Description: Digital signature

Bug#733295: gnutls-bin: please compile GnuTLS with DANE support

[Stephane Mikaty]

help

On 28 Dec 2013, at 13:45, Andreas Metzler ametz...@bebt.de wrote:

 tags 733295 wontfix
 thanks
 
 On 2013-12-28 Marius Gavrilescu mar...@ieval.ro wrote:
 Package: gnutls-bin
 Version: 3.2.8.1-2
 Severity: wishlist
 
 GnuTLS is currently built without DANE support.
 
  [10:49:17] 0 marius@mgvx:~$ danetool --check=www.nic.cz
  This functionality was disabled (GnuTLS was not compiled with support for 
 DANE).
 
 Hello,
 
 libdane requires and links against libunbound. libunbound OTOH is
 linked against OpenSSL's libssl on Debian[1]. Therefore libdane and
 any program using it ends up being dynamically linked against both
 libssl (OpenSSL license) and GnuTLS (LGPLv3+ via gmp).
 
 The result is not very useful, since it is e.g. GPL-incompatible (even
 danetool(1) is GPLv3+). Apart from that it is more than a little bit
 ugly that libdane customers end up being linked against two different
 major TLS toolkits.
 
 cu Andreas
 -- 
 `What a good friend you are to him, Dr. Maturin. His other friends are
 so grateful to you.'
 `I sew his ears on from time to time, sure'
 


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#733295: gnutls-bin: please compile GnuTLS with DANE support

[James Cloos]

 AM == Andreas Metzler ametz...@bebt.de writes:

AM libdane requires and links against libunbound. libunbound OTOH
AM is linked against OpenSSL's libssl on Debian[1].

A possible way forward is to configure unbound --with-nss, which
should provide license compatibility for all libunbound users.

-JimC
--
James Cloos cl...@jhcloos.com OpenPGP: 1024D/ED7DAEA6


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#733295: gnutls-bin: please compile GnuTLS with DANE support

[Marius Gavrilescu]

Package: gnutls-bin
Version: 3.2.8.1-2
Severity: wishlist

GnuTLS is currently built without DANE support.

  [10:49:17] 0 marius@mgvx:~$ danetool --check=www.nic.cz
  This functionality was disabled (GnuTLS was not compiled with support for 
DANE).

-- System Information:
Debian Release: jessie/sid
  APT prefers unstable
  APT policy: (990, 'unstable'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 3.11-2-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages gnutls-bin depends on:
ii  libc62.17-97
ii  libgmp10 2:5.1.3+dfsg-1
ii  libgnutls28  3.2.8.1-2
ii  libhogweed2  2.7.1-1
ii  libidn11 1.28-1
ii  libnettle4   2.7.1-1
ii  libopts251:5.18-2
ii  libp11-kit0  0.20.1-3
ii  libtasn1-6   3.4-2
ii  zlib1g   1:1.2.8.dfsg-1

gnutls-bin recommends no packages.

gnutls-bin suggests no packages.

-- no debconf information


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#733295: gnutls-bin: please compile GnuTLS with DANE support

[Andreas Metzler]

tags 733295 wontfix
thanks

On 2013-12-28 Marius Gavrilescu mar...@ieval.ro wrote:
 Package: gnutls-bin
 Version: 3.2.8.1-2
 Severity: wishlist

 GnuTLS is currently built without DANE support.

   [10:49:17] 0 marius@mgvx:~$ danetool --check=www.nic.cz
   This functionality was disabled (GnuTLS was not compiled with support for 
 DANE).

Hello,

libdane requires and links against libunbound. libunbound OTOH is
linked against OpenSSL's libssl on Debian[1]. Therefore libdane and
any program using it ends up being dynamically linked against both
libssl (OpenSSL license) and GnuTLS (LGPLv3+ via gmp).

The result is not very useful, since it is e.g. GPL-incompatible (even
danetool(1) is GPLv3+). Apart from that it is more than a little bit
ugly that libdane customers end up being linked against two different
major TLS toolkits.

cu Andreas
-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org