Re: Implementing DANE for qmail

Erwin Hoffmann <[email protected]> Thu, 10 May 2018 22:24:37 +0200
Newsgroups	gmane.mail.qmail.general
Message-ID	<[email protected]>
Hi Manvendra,

thanks for continuously supporting Qmail.

While I am working on DJBDNSCurve6 ....

> Am 10.05.2018 um 16:35 schrieb Manvendra Bhangui <[email protected]>:
> 
> On 9 April 2017 at 21:22, Manvendra Bhangui <[email protected]> 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
signature.asc (application/pgp-signature, 833 B)