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