search

EFForg / starttls-everywhere

A system for ensuring & authenticating STARTTLS encryption between mail servers
Other
371 stars 43 forks source link

Add a "DANE" mode to the policy list #72

Closed jgillula closed 5 years ago

jgillula commented 6 years ago

Some people want to tie their certificates to DANE TLSA DNS RRs. We should support this, by adding an optional "DANE" mode, which would indicate that the given recipient server's cert chains to DANE, not a CA root in some root program.

J0WI commented 5 years ago

I think you mean dane-only, because dane falls back to may (and this can be downgraded to none) in Postfix.

jgillula commented 5 years ago

Good catch!

J0WI commented 5 years ago

See also #94

Snawoot commented 5 years ago

I don't think it is really needed.

I think you mean dane-only, because dane falls back to may (and this can be downgraded to none) in Postfix.

Postfix documentation denies it:

The "dane" level is a stronger form of opportunistic TLS that is resistant to man in the middle and downgrade attacks when the destination domain uses DNSSEC to publish DANE TLSA records for its MX hosts. If a remote SMTP server has "usable" (see section 3 of RFC 7672) DANE TLSA records, the server connection will be authenticated. When DANE authentication fails, there is no fallback to unauthenticated or plaintext delivery.

I think, dane level is a good choice for default TLS security level in Postfix, if system is capable to perform DNSSEC-queries securely.

J0WI commented 5 years ago

http://www.postfix.org/postconf.5.html#smtp_tls_security_level

When DNSSEC-validated TLSA records are not found the effective tls security level is "may".

I'm switched from may to dane a few months ago and up to now I never got any denied connection.

AliceWonderMiscreations commented 5 years ago

I concur with Snawoot. It is not needed. If a client MTA is set up to enforce DNS for SMTP then it does not need this project to discover whether or not the mailbox domain and MX hosts are implementing it.

AliceWonderMiscreations commented 5 years ago

Okay thinking about it - it could be useful for discovering which hosts are committed enough to DANE to request the dane-only mode in the event there is a failure that prevents the TLSA record from being usable, to prevent a fallback to may.

But I think the intent of dane-only is for when your MTA does not deliver to other mailbox domains, but to another MTA that delivers to mailbox domains. In those cases, fingerprints in the config are often used but dane-only provides a way to change the private/public keypair on the server and propagate the change through DNS rather than needing to notify the admins of every MTA that relays through you. I don't think dane-only is intended as an appropriate mode for public mailbox domains.

I believe the MTA-STS specification says not to deliver to if the MX servers implement DANE and it doesn't pass, so DANE can work in combination with MTA-STS to provide the fingerprint verification for servers implementing MTA-STS. They should not fall back to may if the DANE fingerprint fails because the MTA-STS policy is defer delivery if a TLS 1.2 connection with a PKI validating certificate is not used.

I suppose some may want the option of requiring TLS 1.2 with self signed certs secured by DANE outside of MTA-STS but honestly Let's Encrypt is so easy to use to get a PKI validating cert that I don't think that needs to be catered to.

If I am mis-understanding something please enlighten.

sydneyli commented 5 years ago

we've decided this is out-of-scope for the list.