Discussion: determining about what DANE implementation we care about. #1911

New Issue

2020-05-12T19:18:04Z

blacklight447 commented

2020-05-12 19:18:04 +00:00

(Migrated from github.com)

Today, I was alerted by Daniel Micay that even though we list DANE as a security requirement, we listed some providers which do not support DANE. After talking with him more, he pointed out that he was talking about DANE for outgoing emails.

During our testing, we always used hardenize.com to test for DANE support, but missed the fact this can only test for incoming mails, not outgoing mails. for testing outgoing mail, we will be using havedane.net .

We now have three things to find out and discuss:

find out what provider supports what implementation of dane (dane for incoming, outgoing or both)
discuss whether we require dane on both incoming and outgoing, or only one of these two.
Decide how to proceed. we already know that we will need a PR to clarify in the requirements about which implementation of DANE we care about, but we should also reach out to the listed providers.

Another point of discussion is how we like to see non DANE domains handled (if I email a mail address on a domain without DANE (so not invalid , just absent), should the mail provider still deliver the email?)

Today, I was alerted by Daniel Micay that even though we list DANE as a security requirement, we listed some providers which do not support DANE. After talking with him more, he pointed out that he was talking about DANE for outgoing emails. During our testing, we always used hardenize.com to test for DANE support, but missed the fact this can only test for incoming mails, not outgoing mails. for testing outgoing mail, we will be using havedane.net . We now have three things to find out and discuss: 1. find out what provider supports what implementation of dane (dane for incoming, outgoing or both) 2. discuss whether we require dane on both incoming and outgoing, or only one of these two. 3. Decide how to proceed. we already know that we will need a PR to clarify in the requirements about which implementation of DANE we care about, but we should also reach out to the listed providers. Another point of discussion is how we like to see non DANE domains handled (if I email a mail address on a domain without DANE (so not invalid , just absent), should the mail provider still deliver the email?)

👍 2

ph00lt0 commented

2020-05-12 20:06:36 +00:00

(Migrated from github.com)

This is a pretty inclusive list of what is supported by which providers:

https://dismail.de/serverlist.html

This is a pretty inclusive list of what is supported by which providers: https://dismail.de/serverlist.html

blacklight447 commented

2020-05-12 20:35:03 +00:00

(Migrated from github.com)

This is a pretty inclusive list of what is supported by which providers:

https://dismail.de/serverlist.html

interesting resource, but it does seem a bit out of date. (for example is shows that tutanota does not support dmarc)

> This is a pretty inclusive list of what is supported by which providers: > > https://dismail.de/serverlist.html interesting resource, but it does seem a bit out of date. (for example is shows that tutanota does not support dmarc)

ph00lt0 commented

2020-05-12 21:53:40 +00:00

(Migrated from github.com)

Last update was 2020-01-02 and they allow you to send them corrections.

dngray commented

2020-05-13 04:47:40 +00:00

(Migrated from github.com)

I'm thinking verification to invalid may not actually be that important to us.

We do require MTA-STS as well which is far more common these days. The most important part is incoming DANE verification (for servers which can't check MTA-STS policy), or for servers which haven't got a MTA-STS policy published, but do have DANE.

Using that havedane.net I was able to get these results

ProtonMail

Wed 13 May 2020 03:54:40 UTC

Results
✔ Email to non-DANE domain delivered.
✔ Email to DANE domain delivered.
❌ Email to domain with invalid DANE delivered.

Mailbox.org

Wed 13 May 2020 04:18:40 UTC

✔ Email to non-DANE domain delivered.
✔ Email to DANE domain delivered.
✔ Email to domain with invalid DANE not delivered.

Soverin

Wed 13 May 2020 04:36:00 UTC

✔ Email to non-DANE domain delivered.
✔ Email to DANE domain delivered.
❌ Email to domain with invalid DANE delivered.

Disroot

Wed 13 May 2020 04:30:50 UTC

✔ Email to non-DANE domain delivered.
✔ Email to DANE domain delivered.
❌ Email to domain with invalid DANE delivered.

Tutanota

Tue 12 May 2020 18:30:00 UTC

✔ Email to non-DANE domain delivered.
✔ Email to DANE domain delivered.
✔ Email to domain with invalid DANE not delivered.

StartMail

Wed 13 May 2020 06:34:36 UTC

✔ Email to non-DANE domain delivered.
✔ Email to DANE domain delivered.
✔ Email to domain with invalid DANE not delivered.

I'm thinking verification to invalid may not actually be that important to us. We do require MTA-STS as well which is far more common these days. The most important part is incoming DANE verification (for servers which can't check MTA-STS policy), or for servers which haven't got a MTA-STS policy published, but do have DANE. Using that havedane.net I was able to get these results #### ProtonMail Wed 13 May 2020 03:54:40 UTC Results ✔ Email to non-DANE domain delivered. ✔ Email to DANE domain delivered. ❌ Email to domain with invalid DANE delivered. #### Mailbox.org Wed 13 May 2020 04:18:40 UTC ✔ Email to non-DANE domain delivered. ✔ Email to DANE domain delivered. ✔ Email to domain with invalid DANE not delivered. #### Soverin Wed 13 May 2020 04:36:00 UTC ✔ Email to non-DANE domain delivered. ✔ Email to DANE domain delivered. ❌ Email to domain with invalid DANE delivered. #### Disroot Wed 13 May 2020 04:30:50 UTC ✔ Email to non-DANE domain delivered. ✔ Email to DANE domain delivered. ❌ Email to domain with invalid DANE delivered. #### Tutanota Tue 12 May 2020 18:30:00 UTC ✔ Email to non-DANE domain delivered. ✔ Email to DANE domain delivered. ✔ Email to domain with invalid DANE not delivered. #### StartMail Wed 13 May 2020 06:34:36 UTC ✔ Email to non-DANE domain delivered. ✔ Email to DANE domain delivered. ✔ Email to domain with invalid DANE not delivered.

👍 1

thestinger commented

2020-05-13 05:42:57 +00:00

(Migrated from github.com)

Both MTA-STS and DANE are designed to be checked by the client i.e. the side that's sending mail. So, setting up DNS records, etc. for MTA-STS and DNSSEC + TLSA allows others to send mail to you securely but doesn't secure TLS when you're sending mail.

It's important to have both MTA-STS and DANE due to the fact that some providers only provide one of them. It's not enough to have only DANE because then you can't send and receive email with Gmail securely. It's not enough to only have MTA-STS because then you can't send and receive email with most EU services securely.

There's a very serious issue with most services in that they do not fully implement these features. It's common to only implement MTA-STS and DANE for incoming mail since that's what scans will check.

It's also common to only implement SPF + DKIM + DMARC for sending mail since that's what scans will check. It's very important for mail providers to enforce DMARC for incoming mail since otherwise mail can be spoofed... but many don't do that. DKIM without DMARC is pretty useless since it doesn't have a way to enforce that all mails are signed as you would expect. They can just be optionally signed and refer to the DNS record for the key...

Both MTA-STS and DANE are designed to be checked by the client i.e. the side that's sending mail. So, setting up DNS records, etc. for MTA-STS and DNSSEC + TLSA allows others to send mail to you securely but doesn't secure TLS when you're sending mail. It's important to have both MTA-STS *and* DANE due to the fact that some providers only provide one of them. It's not enough to have only DANE because then you can't send and receive email with Gmail securely. It's not enough to only have MTA-STS because then you can't send and receive email with most EU services securely. There's a very serious issue with most services in that they do not fully implement these features. It's common to only implement MTA-STS and DANE for incoming mail since that's what scans will check. It's also common to only implement SPF + DKIM + DMARC for sending mail since that's what scans will check. It's very important for mail providers to enforce DMARC for incoming mail since otherwise mail can be spoofed... but many don't do that. DKIM without DMARC is pretty useless since it doesn't have a way to enforce that all mails are signed as you would expect. They can just be optionally signed and refer to the DNS record for the key...

thestinger commented

2020-05-13 05:47:05 +00:00

(Migrated from github.com)

Also important to note that havedane.net only verifies that checking TLSA records is enforced. It does not verify if they do proper local DNSSEC verification. I think it's a common issue to enable DANE verification without setting up a validating local resolver like unbound. It's typical to rely on remote recursive resolvers via the unencrypted/unauthenticated DNS protocol which is insecure but can't really be detected by a test. Could detect if there's no DNSSEC validation at all, but there probably is by an upstream server. It would be possible to make a test with a 2nd invalid test case where the DANE record is valid but DNSSEC is not valid, which could at least detect cases with no DNSSEC verification.

Also important to note that `havedane.net` only verifies that checking TLSA records is enforced. It does **not** verify if they do proper local DNSSEC verification. I think it's a common issue to enable DANE verification without setting up a validating local resolver like unbound. It's typical to rely on remote recursive resolvers via the unencrypted/unauthenticated DNS protocol which is insecure but can't really be detected by a test. Could detect if there's no DNSSEC validation at all, but there probably is by an upstream server. It would be possible to make a test with a 2nd invalid test case where the DANE record is valid but DNSSEC is not valid, which could at least detect cases with no DNSSEC verification.

thestinger commented

2020-05-13 06:09:12 +00:00

(Migrated from github.com)

You would need a similar test case like havedane.net for verifying that MTA-STS is enforced for sending email. I'm curious how many providers other than Gmail actually enforce MTA-STS. Having the DANE / MTA-STS setup accomplishes nothing if the sender doesn't enforce them.

You would need a similar test case like `havedane.net` for verifying that MTA-STS is enforced for sending email. I'm curious how many providers other than Gmail actually enforce MTA-STS. Having the DANE / MTA-STS setup accomplishes nothing if the sender doesn't enforce them.

👍 1

blacklight447 commented

2020-05-13 06:15:17 +00:00

(Migrated from github.com)

Thank you for your comments Daniel, they are very much appreciated. I agree personally that DANE for outgoing mail is important. especially since it will take a while before MTA-STS will become a more common feature like STARTTLS. Would you happen to know a way of detecting whether DANE is done with a local resolver instead of an remote one.
Also, would the problem be less severe if one were to use DoH or DoT to connect to their remote resolver?

About MTA-STS, I will do some digging today to find out what methods we can use to test MTA-STS enforcement.

Thank you for your comments Daniel, they are very much appreciated. I agree personally that DANE for outgoing mail is important. especially since it will take a while before MTA-STS will become a more common feature like STARTTLS. Would you happen to know a way of detecting whether DANE is done with a local resolver instead of an remote one. Also, would the problem be less severe if one were to use DoH or DoT to connect to their remote resolver? About MTA-STS, I will do some digging today to find out what methods we can use to test MTA-STS enforcement.

thestinger commented

2020-05-13 06:24:17 +00:00

(Migrated from github.com)

Also, would the problem be less severe if one were to use DoH or DoT to connect to their remote resolver?

Yes, it still trusts the resolver, but it wouldn't be vulnerable to MITM. Ideally, mail servers have unbound to provide local DNSSEC verification and forwarding to a caching resolver via DoT to provide improved privacy. A sample unbound.conf:

server:
    qname-minimisation: yes
    auto-trust-anchor-file: "/var/lib/unbound/root.key"
    tls-cert-bundle: /etc/ssl/certs/ca-certificates.crt

forward-zone:
    name: "."
    forward-tls-upstream: yes
    forward-addr: 1.0.0.1@853#cloudflare-dns.com
    forward-addr: 1.1.1.1@853#cloudflare-dns.com

The system needs to be set up to use 127.0.0.1 as the DNS resolver.

About MTA-STS, I will do some digging today to find out what methods we can use to test MTA-STS enforcement.

Host a mail server with an MTA-STS policy and a self-signed certificate. If a mail provider can send mail to it, they don't enforce MTA-STS. I expect that this is the case for most providers that have an MTA-STS policy for others to use. It's very common with DANE but I expect it's even more common with MTA-STS. For example, Postfix supports a configuration option for enforcing DANE itself with the help of a local DNSSEC validating resolver but MTA-STS has to be done with an external service and it's more painful. So, people using Postfix without DANE verification set up have little excuse but MTA-STS is a whole other service just like enforcing DMARC via opendmarc - need to set up a separate service, configure your MTA to use it and configure that service in a proper enforcing mode without bypasses. There are common issues with DMARC enforcement bypasses too...

> Also, would the problem be less severe if one were to use DoH or DoT to connect to their remote resolver? Yes, it still trusts the resolver, but it wouldn't be vulnerable to MITM. Ideally, mail servers have unbound to provide local DNSSEC verification and forwarding to a caching resolver via DoT to provide improved privacy. A sample `unbound.conf`: ``` server: qname-minimisation: yes auto-trust-anchor-file: "/var/lib/unbound/root.key" tls-cert-bundle: /etc/ssl/certs/ca-certificates.crt forward-zone: name: "." forward-tls-upstream: yes forward-addr: 1.0.0.1@853#cloudflare-dns.com forward-addr: 1.1.1.1@853#cloudflare-dns.com ``` The system needs to be set up to use `127.0.0.1` as the DNS resolver. > About MTA-STS, I will do some digging today to find out what methods we can use to test MTA-STS enforcement. Host a mail server with an MTA-STS policy and a self-signed certificate. If a mail provider can send mail to it, they don't enforce MTA-STS. I expect that this is the case for most providers that have an MTA-STS policy for others to use. It's very common with DANE but I expect it's even more common with MTA-STS. For example, Postfix supports a configuration option for enforcing DANE itself with the help of a local DNSSEC validating resolver but MTA-STS has to be done with an external service and it's more painful. So, people using Postfix without DANE verification set up have little excuse but MTA-STS is a whole other service just like enforcing DMARC via opendmarc - need to set up a separate service, configure your MTA to use it and configure that service in a proper enforcing mode without bypasses. There are common issues with DMARC enforcement bypasses too...

👍 2

thestinger commented

2020-05-13 06:26:04 +00:00

(Migrated from github.com)

So, people using Postfix without DANE verification set up have little excuse but MTA-STS is a whole other service just like enforcing DMARC via opendmarc

(they do have to set up DNSSEC but that's simpler and covers more than just DANE - MTA-STS could be bypassed on the first connection without DNSSEC too)

> So, people using Postfix without DANE verification set up have little excuse but MTA-STS is a whole other service just like enforcing DMARC via opendmarc (they do have to set up DNSSEC but that's simpler and covers more than just DANE - MTA-STS could be bypassed on the first connection without DNSSEC too)

This repo is archived. You cannot comment on issues.