[WIP] Add MTA-STS

[drwetter]

This PR adds an implementation of MTA-STS (RFC 8461), see also issue #1073

Currently it's a WIP.

What doesn't work

• test a hostname which is not equal to domainname
• test a hostname which has no mx record
• file output
• any compliance parsing of TLS RPT TXT record + .well-known/mta-sts.txt
• when no TXT records or .well-known/mta-sts.txt are there
• colored screen output

Needed:

• More testing and errors to be addressed.
• sub.sub.domain.tld probably doesn't work
• --mx does a check for every single MX instead of keeping the results
• Policy delegation (CNAME?) --> Not tested yet
• A simple unit test would be great. Anybody?

There's a new stub function for DANE too.

Besides: to avoid confusion I changed all GET requests over HTTPS from tm_out to safe_echo. It's actually exactly the same only the name is different but it seems more appropriate here.

[drwetter]

Hi @vdukhovni ,

thanks for you input!

The function above was more a stub thing to signal that some thing is coming. The plan is to check for TLSA records first (as DNSSEC is more a pain) and label it as experimental. Then work on the DNSSEC part. Probably not only for SMTP.

For DANE/TLSA I'll have a PoC which is not good enough to publish. I decided though not to use the bultin -dane* functions of newer openssl, for compatibility reasons.

For DNSSEC I have no clue yet how to that but I think I have good input now. The catch here is probably the resolver which needs to be DNSSEC aware (ad), or can you think of any other way to do a proper test?

[vdukhovni]

For DANE/TLSA I'll have a PoC which is not good enough to publish. I decided though not to use the bultin -dane* functions of newer openssl, for compatibility reasons.

I've seen many naive attempts to implement DANE-TLSA certificate chain validation that fail to implement all the required steps correctly. OpenSSL 1.1.0 is by now broadly available. My advice would be to not build a new validator from the ground up. You can of course do as you see fit.

For DNSSEC I have no clue yet how to that but I think I have good input now. The catch here is probably the resolver which needs to be DNSSEC aware (ad), or can you think of any other way to do a proper test?

Again, instead of reinventing a ground up DNSSEC implementation, keep track of evolving algorithms, keep track of a potentially changing root zone trust anchor, ... your simplest approach would in fact be to use a local validating resolver and to trust its "ad" bit. Otherwise use a library like libunbound that provides all the necessary support, but still depends on a valid trust-anchor, which requires something on the system that keeps that up to date.

For me the focus would be on the end goal, determining wether a given site has a working DANE deployment. Implementing a DNSSEC validator and a DANE TLSA certificate chain validator would be left to the libraries that specialise in that sort of thing...