Mailing List Archive

Implementing DANE for qmail
I have been thinking about this and have followed this document

https://www.ietf.org/mail-archive/web/dane/current/pdfk2DbQF0Oxs.pdf

What I have understood is this

For Domain owners
publish a TLSA Resource Record (RR) and enforce your servers to use TLS.

For clients
query the TLSA RR and then decide to connect or not. This will require
modification to qmail-remote. As specified in the DANE protocol RFC,
the TLSA RR resulting from a DNS Query must be validated by DNSSEC. It
is MUST that the zone which has a TLSA RR must be signed by DNSSEC and
the applications which query the domain for TLSA RR validation should
use a DNSSEC aware resolver. This is where I am confused. Do all
resolver setup support DNSSEC?

Is there anyone working on this? If yes, how difficult would this be
to implement?

--
Regards Manvendra - http://www.indimail.org
GPG Pub Key
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xC7CBC760014D250C
Re: Implementing DANE for qmail [ In reply to ]
Hi Manvendra,


> Am 09.04.2017 um 17:52 schrieb Manvendra Bhangui <mbhangui@gmail.com>:
>
> I have been thinking about this and have followed this document
>
> https://www.ietf.org/mail-archive/web/dane/current/pdfk2DbQF0Oxs.pdf
>
> What I have understood is this
>
> For Domain owners
> publish a TLSA Resource Record (RR) and enforce your servers to use TLS.

Mail clients ;-)

>
> For clients
> query the TLSA RR and then decide to connect or not. This will require
> modification to qmail-remote.

Better not too many.

> As specified in the DANE protocol RFC,
> the TLSA RR resulting from a DNS Query must be validated by DNSSEC.

Hm. I doubt it. You will find a good explanation of TLSA/DNSSEC/DJBDNS in my text book 'Technik der IP-Netze' (unfortunately just in German).

> It
> is MUST that the zone which has a TLSA RR must be signed by DNSSEC and
> the applications which query the domain for TLSA RR validation should
> use a DNSSEC aware resolver. This is where I am confused. Do all
> resolver setup support DNSSEC?

No. qmail-remote uses a stub-resolver and DNSSEC/TLS validation could/should be done by means of a proxy.

>
> Is there anyone working on this? If yes, how difficult would this be
> to implement?
>

You can briefly check, that this is on my agenda for s/qmail. The hard part is the validating DNS resolver.
It is easy with DJBDNS. DNSSEC is be definition not secure but depends a X.509 system (not PKI) -- the one to avoid according to TLSA.

Apart from that, PKI still needs to be supported.


Regards.
--eh.

PS. Within s/qmail Cert Pinning is supported which is great on peer-2-peer base, but of course does not scale like TLSA.


> --
> Regards Manvendra - http://www.indimail.org
> GPG Pub Key
> http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xC7CBC760014D250C
>

Dr. Erwin Hoffmann | FEHCom | http://www.fehcom.de | PGP Key-Id: EE00CF65
Re: Implementing DANE for qmail [ In reply to ]
On 9 April 2017 at 23:37, Erwin Hoffmann <feh@fehcom.de> wrote:

>> It
>> is MUST that the zone which has a TLSA RR must be signed by DNSSEC and
>> the applications which query the domain for TLSA RR validation should
>> use a DNSSEC aware resolver. This is where I am confused. Do all
>> resolver setup support DNSSEC?
>
> No. qmail-remote uses a stub-resolver and DNSSEC/TLS validation could/should be done by means of a proxy.
>

Found this and it was helpful to me in understanding
http://wiki.halon.io/DANE


> PS. Within s/qmail Cert Pinning is supported which is great on peer-2-peer base, but of course does not scale like TLSA.
>

Will look forward to your implementation. BTW, another question. Do
folks still use djbdns? There is a DNSSEC patch for djbdns -
http://www.tinydnssec.org/ and has been implemented below

https://blog.ploetzli.ch/2014/tinydns-dnssec/


--
Regards Manvendra - http://www.indimail.org
GPG Pub Key
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xC7CBC760014D250C
Re: Implementing DANE for qmail [ In reply to ]
Op 10-04-17 om 06:36 schreef Manvendra Bhangui:
> On 9 April 2017 at 23:37, Erwin Hoffmann <feh@fehcom.de> wrote:
>
>
> Will look forward to your implementation. BTW, another question. Do
> folks still use djbdns? There is a DNSSEC patch for djbdns -
> http://www.tinydnssec.org/ and has been implemented below
>
> https://blog.ploetzli.ch/2014/tinydns-dnssec/
>


We switched to unbound as dns-resolver
https://www.unbound.net/
Re: Implementing DANE for qmail [ In reply to ]
On 9 April 2017 at 23:37, Erwin Hoffmann <feh@fehcom.de> wrote:
>
> You can briefly check, that this is on my agenda for s/qmail. The hard part is the validating DNS resolver.
> It is easy with DJBDNS. DNSSEC is be definition not secure but depends a X.509 system (not PKI) -- the one to avoid according to TLSA.
>
> Apart from that, PKI still needs to be supported.

Today was a good day. Spent some time demystifying DANE. It does not
look difficult. Here is small tutorial explaining how it works. I am
using TLSA RR records for ietf.org as an example

Get the mx record for ietf.org
---------------------------------------
$ host -tmx ietf.org
ietf.org mail is handled by 0 mail.ietf.org.

Get the TLSA Resource Record by appending _25._tcp. to the mx record
------------------------------------------
$ host -ttlsa _25._tcp.mail.ietf.org
_25._tcp.mail.ietf.org has TLSA record 3 1 1
0C72AC70B745AC19998811B131D662C9AC69DBDBE7CB23E5B514B566 64C5D3D6

The above shows the fingerprint
0C72AC70B745AC19998811B131D662C9AC69DBDBE7CB23E5B514B566 64C5D3D6


Capture the Certificate in a file test.pem
-----------------------------------------------------
$ echo QUIT | openssl s_client -starttls smtp -crlf -connect mail.ietf.org:25
(
echo -----BEGIN CERTIFICATE-----
sed -e '1,/^-----BEGIN CERTIFICATE-----/d' \
-e '/^-----END CERTIFICATE-----/,$d' < /tmp/cert.tmp
echo -----END CERTIFICATE-----
) > test.pem

$ openssl x509 -pubkey -noout < test.pem | grep -v 'PUBLIC KEY' |
base64 -d | sha256sum
0c72ac70b745ac19998811b131d662c9ac69dbdbe7cb23e5b514b56664c5d3d6 -

Other than the output in lower case, it shows that the fingerprint for
the certificate matches with the fingerprint in the DNS TLSA record

Hope that the above example is useful for someone trying to understand DANE.
--
Regards Manvendra - http://www.indimail.org
GPG Pub Key
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xC7CBC760014D250C
Re: Implementing DANE for qmail [ In reply to ]
* Erwin Hoffmann <feh@fehcom.de> [2017-04-09 20:15]:
> > Am 09.04.2017 um 17:52 schrieb Manvendra Bhangui <mbhangui@gmail.com>:
> > It
> > is MUST that the zone which has a TLSA RR must be signed by DNSSEC and
> > the applications which query the domain for TLSA RR validation should
> > use a DNSSEC aware resolver. This is where I am confused. Do all
> > resolver setup support DNSSEC?
> No. qmail-remote uses a stub-resolver and DNSSEC/TLS validation
> could/should be done by means of a proxy.=20

huh? no proxy.

it should use the regular resolver. dnssec-validated answers are
indicated by the ad flag.

; <<>> DiG 9.4.2-P2 <<>> +dnssec quigon.bsws.de
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 17183
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 3, AUTHORITY: 5, ADDITIONAL: 1
^^
here

> You can briefly check, that this is on my agenda for s/qmail. The
> hard part is the validating DNS resolver.=20

you don't rewrite that.

> It is easy with DJBDNS.

err, no. it is easy with unbound. and probably even bind.

> DNSSEC is be definition not secure

unfounded (and wrong) claim.

> but depends a X.509 system (not PKI) -- the one to avoid according to TLS=
A.

there are no certs indeed, just keys. current dnssec is relatively
straightforward, it isn't the mess the early proposals were any more.

> Apart from that, PKI still needs to be supported.

sigh. if your agenda is "reinventing the wheel, again", then yes, probably.

But really, that is everything but smart. You just make qmail-remote
understand the AD flag, and call into LibreSSL's libtls for certificate
verification. Or another TLS lib if you like pain.
Add a little glue and done.

--
Henning Brauer, hb@bsws.de, henning@openbsd.org
BS Web Services GmbH, AG Hamburg HRB 128289, http://bsws.de
Full-Service ISP - Secure Hosting, Mail and DNS Services
Dedicated Servers, Rootservers, VMs/VPS, Application Hosting
Re: Implementing DANE for qmail [ In reply to ]
On 9 April 2017 at 21:22, Manvendra Bhangui <mbhangui@gmail.com> wrote:
>
> I have been thinking about this and have followed this document
>
> https://www.ietf.org/mail-archive/web/dane/current/pdfk2DbQF0Oxs.pdf
>
> What I have understood is this
>
> For Domain owners
> publish a TLSA Resource Record (RR) and enforce your servers to use TLS.
>
> For clients
> query the TLSA RR and then decide to connect or not. This will require
> modification to qmail-remote. As specified in the DANE protocol RFC,
> the TLSA RR resulting from a DNS Query must be validated by DNSSEC. It
> is MUST that the zone which has a TLSA RR must be signed by DNSSEC and
> the applications which query the domain for TLSA RR validation should
> use a DNSSEC aware resolver. This is where I am confused. Do all
> resolver setup support DNSSEC?
>
> Is there anyone working on this? If yes, how difficult would this be
> to implement?


So an entire year went by and I almost gave up. In this time I managed
to write and test all validation routines for DANE minus the part
where I get the actual TLSA RR records. The one thing that I have
succeeded is calculating the fingerprints for X509 certificates and
X509 PublicKey. For doing DNSSEC in qmail-remote, I had these 3
choices

1. Implement the DNSSEC verification myself
2. Use an existing DNS resolver library with DNSSEC support.
3. Have a trusted validating resolver running locally on the client device.
Use it for all DNS queries and check the AD (Authenticated Data) flag
in the DNS response.

The difficulty I had was that not being someone with a absolute good
knowledge about DNS, it was impossible for me to do (1). The third (3)
option relies on a specific system configuration which may not be
fulfilled on every system installation. Hence I decided on option (2).
That too proved difficult but with the help of getdns libary I have
finally managed to get the TLSA RR with just one function

do_dns_queries(mxhost, port, recursive_or_not);

The issue I have with getdns library is that it has too many
dependencies (libevent, libunbound, etc). No problem with source
compilation but lack of binary RPM/DEBs on many distros like RHEL7,
SLE and older distros is hampering my effort to automate qmail &
indimail build for few distros.

Is there a simple function that I can just call and get the TLSA
resources records?

For those interested I am including the sources for the above
do_dns_query() function implemented in a program tlsarr. To compile
it,, following are the steps

1. Install getdns library from https://getdnsapi.net/
2. Compile the sources included in this email like this

$ gcc -DHAVE_CONFIG_H -c danetlsa.c
$ gcc -c tlsa_variables.c
$ gcc -c tlsarr.c
$ gcc -o tlsarr tlsarr.o danetlsa.o tlsa_variables.o -lgetdns
-lgetns_ext_event -lssl -lcrypto -levent

Example Usage

$ ./tlsarr mail.ietf.org
TLSA records found: 1
TLSA: 3 1 1 0c72ac70b745ac19998811b131d662c9ac69dbdbe7cb23e5b514b56664c5d3d6

The source code for tlsarr is in
https://sourceforge.net/projects/indimail/files/dane/

Examples on how to calculate the fingerprints of the X509 certs / X509
cert chain are in try1.c and try2.c. I will be using those methods in
qmail-remote to do the actual DANE verification.

I have also included qmail-remote.c (which is WIP). The function
dane_verify() in qmail-remote is almost complete. I need to call
do_dns_queries() and cycle through all the resource records and do the
dane verification. However I am not happy with the getdns lib as it is
adding too many dependencies (libunbound, libevent, etc). So If any
one can point me in the right direction - that is -

How to write an application (qmail-remote) that can do DNSSEC and
fetch the TLSA resource records without losing simplicity and
portability?
Re: Implementing DANE for qmail [ In reply to ]
Hi Manvendra,

thanks for continuously supporting Qmail.

While I am working on DJBDNSCurve6 ....

> Am 10.05.2018 um 16:35 schrieb Manvendra Bhangui <mbhangui@gmail.com>:
>
> On 9 April 2017 at 21:22, Manvendra Bhangui <mbhangui@gmail.com> wrote:
>>
>> I have been thinking about this and have followed this document
>>
>> https://www.ietf.org/mail-archive/web/dane/current/pdfk2DbQF0Oxs.pdf
>>
>> What I have understood is this
>>
>> For Domain owners
>> publish a TLSA Resource Record (RR) and enforce your servers to use TLS.
>>
>> For clients
>> query the TLSA RR and then decide to connect or not. This will require
>> modification to qmail-remote. As specified in the DANE protocol RFC,
>> the TLSA RR resulting from a DNS Query must be validated by DNSSEC. It
>> is MUST that the zone which has a TLSA RR must be signed by DNSSEC and
>> the applications which query the domain for TLSA RR validation should
>> use a DNSSEC aware resolver.

TLSA records are welcome to improve TLS negotiation with the receiving MX.
They -- and that's all about -- provide Trust while transmitting the TLS encrypted SMTP mail.
TLSA are a matter of MX-to-MX trust dependency. They don't improve confidentiality (except in rejection mode).


>> This is where I am confused. Do all
>> resolver setup support DNSSEC?

Two answers:

a) Not all resolvers support DNSSec (we are talking about a 'full resolver', not a 'stub resolver').
b) TLSA records don't need to be signed by DNSSec.

Given DNSSec, you just confirm by means of the signature evaluation the TLSA record received is correct (whatever that means).


>>
>> Is there anyone working on this? If yes, how difficult would this be
>> to implement?
>
>
> So an entire year went by and I almost gave up. In this time I managed
> to write and test all validation routines for DANE minus the part
> where I get the actual TLSA RR records. The one thing that I have
> succeeded is calculating the fingerprints for X509 certificates and
> X509 PublicKey. For doing DNSSEC in qmail-remote, I had these 3
> choices
>
> 1. Implement the DNSSEC verification myself
> 2. Use an existing DNS resolver library with DNSSEC support.
> 3. Have a trusted validating resolver running locally on the client device.
> Use it for all DNS queries and check the AD (Authenticated Data) flag
> in the DNS response.
>
> The difficulty I had was that not being someone with a absolute good
> knowledge about DNS, it was impossible for me to do (1). The third (3)
> option relies on a specific system configuration which may not be
> fulfilled on every system installation. Hence I decided on option (2).
> That too proved difficult but with the help of getdns libary I have
> finally managed to get the TLSA RR with just one function
>
> do_dns_queries(mxhost, port, recursive_or_not);
>
> The issue I have with getdns library is that it has too many
> dependencies (libevent, libunbound, etc). No problem with source
> compilation but lack of binary RPM/DEBs on many distros like RHEL7,
> SLE and older distros is hampering my effort to automate qmail &
> indimail build for few distros.
>
> Is there a simple function that I can just call and get the TLSA
> resources records?
>
> For those interested I am including the sources for the above
> do_dns_query() function implemented in a program tlsarr. To compile
> it,, following are the steps
>
> 1. Install getdns library from https://getdnsapi.net/
> 2. Compile the sources included in this email like this
>
> $ gcc -DHAVE_CONFIG_H -c danetlsa.c
> $ gcc -c tlsa_variables.c
> $ gcc -c tlsarr.c
> $ gcc -o tlsarr tlsarr.o danetlsa.o tlsa_variables.o -lgetdns
> -lgetns_ext_event -lssl -lcrypto -levent
>
> Example Usage
>
> $ ./tlsarr mail.ietf.org
> TLSA records found: 1
> TLSA: 3 1 1 0c72ac70b745ac19998811b131d662c9ac69dbdbe7cb23e5b514b56664c5d3d6
>
> The source code for tlsarr is in
> https://sourceforge.net/projects/indimail/files/dane/
>
> Examples on how to calculate the fingerprints of the X509 certs / X509
> cert chain are in try1.c and try2.c. I will be using those methods in
> qmail-remote to do the actual DANE verification.
>
> I have also included qmail-remote.c (which is WIP). The function
> dane_verify() in qmail-remote is almost complete. I need to call
> do_dns_queries() and cycle through all the resource records and do the
> dane verification. However I am not happy with the getdns lib as it is
> adding too many dependencies (libunbound, libevent, etc). So If any
> one can point me in the right direction - that is -
>
> How to write an application (qmail-remote) that can do DNSSEC and
> fetch the TLSA resource records without losing simplicity and
> portability?

Currently, Kai Peter and me building Qlibs including a DNS Stub Resolver (based on DJBDNS) included into aQmail.
While I've solved most of the IPv6 dependencies, it makes pretty little sense to include TLS support (for transportation) or even DNSSec support (for evaluation) here.

Triggering TLSA record fetching (and verification of the received information) should be done at the stub resolve, without depending to verify the entire received information by DNSSec.
DNSCurve could do as well.

I'll put this point onto my agenda for aQmail using a portable solution (actually in scope for s/qmail).

Regards.
--eh.

See:

https://www.fehcom.de/ipnet/djbdnscurve6.html
https://www.fehcom.de/sqmail/sqmail.html##download

Dr. Erwin Hoffmann | FEHCom | http://www.fehcom.de | PGP Key-Id 7E4034BE
Re: Implementing DANE for qmail [ In reply to ]
On 11 May 2018 at 01:54, Erwin Hoffmann <feh@fehcom.de> wrote:
> Currently, Kai Peter and me building Qlibs including a DNS Stub Resolver (based on DJBDNS) included into aQmail.
> While I've solved most of the IPv6 dependencies, it makes pretty little sense to include TLS support (for transportation) or even DNSSec support (for evaluation) here.
>
> Triggering TLSA record fetching (and verification of the received information) should be done at the stub resolve, without depending to verify the entire received information by DNSSec.
> DNSCurve could do as well.
>

Great. Looking forward to it. Any approximate dates for release?

> I'll put this point onto my agenda for aQmail using a portable solution (actually in scope for s/qmail).
>

Thank you. A portable solution is the need of the hour. All the
libraries I have taken a look at, are horribly bloated. Also not
portable because of multiple dependencies on other libraries.