4 ms·

Notice I never mentioned browsers. Breaking news: there are other applications on the internet other than browsers. And some of them use TLSA records. It’s th

Notice I never mentioned browsers. Breaking news: there are other applications on the internet other than browsers. And some of them use TLSA records. It’s the de facto standard for for secure email, especially if you want guaranteed protection from downgrade attacks.

tptacek 7y ago
Virtually no email sent on the Internet is protected by DANE, DNSSEC, or TLSA. Nor is it likely ever to be, since the major email providers standardized MTA-STS specifically to avoid DNSSEC, as you can see from the opening paragraphs of the standard.
- alwillis 7y ago
  This is provably false. DNSSEC, DANE and TLSA are widely used to secure SMTP servers. From the web page showing the nearly 2 million domains with signed MX and DANE records [1]: The following graph depicts the number of domains that have deployed DANE/SMTP. Specifically, their zone is signed, their MX records all point to hosts that have DANE TLSA records. Regarding MTA-STS, it's a work-around for the large global email providers that can’t implement DNSSEC for a variety of reasons. Again, MTA-STS has problems, the main one is being susceptible to downgrade attacks because MTA-STS doesn’t use DNSSEC. An attacker can MiTM a connection preventing a TLS connection. The MTA-STS RFC [2] confirms this: The DNS-Based Authentication of a Named Entities (DANE)TLSA record [RFC7672] is similar, in that DANE is also designed to upgrade unauthenticated encryption or plaintext transmission into authenticated, downgrade-resistant encrypted transmission. DANE requires DNSSEC [RFC4033] for authentication; the mechanism described here instead relies on certification authorities (CAs) and does not require DNSSEC, at a cost of risking malicious downgrades. There’s no dispute about any of this, so it’s not clear why you continue to make false and misleading statements about these technologies, regardless of your opinions about them. You know the old saying: you’re entitled to your own opinion but not your own facts. [1]: https://stats.dnssec-tools.org/#dnssec https://stats.dnssec-tools.org/#dnssec [2]: https://tools.ietf.org/html/rfc8461#section-2 https://tools.ietf.org/html/rfc8461#section-2 A more complete description I posted previously: https://news.ycombinator.com/item?id=22338742 https://news.ycombinator.com/item?id=22338742
  - tptacek 7y ago
    As you well know, since this is the third time you've tried to make this point, the overwhelming majority of those zones were signed automatically by their European registrars; these counts have no relationship to actual emails sent. The entire idea behind STS protocols is to use continuity schemes to defeat downgrades. It's literally the only threat model.
    - alwillis 7y ago
      these counts have no relationship to actual emails sent These domains wouldn’t have MX or TLSA records unless they were doing email. Even if a zone is pre-signed, an admin has to intentionally create DANE records, which they wouldn’t do unless they were hosting SMTP servers. But it does show the statement that DNSSEC, DANE and TLSA aren’t used for secure email to be utterly untrue. MTA-STS has other issues: * Authenticates domain control via CA leap of faith * Vulnerable to MiTM at cert bootstrap * Vulnerable to weakest root CA, and unauthorized certs * Open to downgrade on first (or irregular) contact * Complex mix of HTTPS, unsigned DNS and SMTP
      - tptacek 7y ago
        Horseshit. I have something like 50 domains on a popular retail registrar and every single one of them has an MX record, despite me never doing a single thing other than claiming the name; they come by default with new domains. If I was in the Netherlands, every one of them would have DNSSEC signatures too, because European registrars opt domains into DNSSEC by default. I'm having a hard time articulating how silly it is to try to dunk on MTA-STS for being "vulnerable" to downgrade attacks; it's like trying to say that HSTS is vulnerable to SSL-stripping attacks. You have to not understand the idea behind the attack or the countermeasure to lead with that argument.
- alwillis 7y ago
  Virtually no email sent on the Internet is protected by DANE, DNSSEC, or TLSA. Here's a short list of domains that are using DNSSEC, DANE and TLSA to protect their email. I also provide a transcript of a utility that connects to and verifies the SMTP server and the DANE/TLSA records for openssl.org and could have done so for every domain on this list but there's no reason to get carried away. * geektimes.com * gmx.com * mail.com * comcast.net * dd24.net * debian.org * freebsd.org * gentoo.org * ietf.org * isc.org * netbsd.org * openssl.org * samba.org * torproject.org There's a DANE TLS SMTP server checking tool: https://www.huque.com/bin/danecheck-smtp https://www.huque.com/bin/danecheck-smtp Here's what it does: This application checks a DANE SMTP Service. It queries the MX record set for the given domain, looks up DANE TLSA records at the MX targets, connects to the target servers, negotiates STARTTLS, and then attempts to verify the TLS server certificate against the TLSA records. Lets test openssl.org: Domain Name: openssl.org MX host: 50 mta.openssl.org ################################################################# ### CHECKING MX HOST: mta.openssl.org ################################################################# TLSA records found: 1 TLSA: 3 1 1 6cf12d78fbf242909d01b96ab5590812954058dc32f8415f048fff064291921e Connecting to IPv6 address: 2001:608:c00:180::1:e6 port 25 recv: 220-mta.openssl.org ESMTP Postfix recv: 220 mta.openssl.org ESMTP Postfix send: EHLO cheetara.huque.com recv: 250-mta.openssl.org recv: 250-PIPELINING recv: 250-SIZE 36700160 recv: 250-VRFY recv: 250-ETRN recv: 250-STARTTLS recv: 250-ENHANCEDSTATUSCODES recv: 250-8BITMIME recv: 250 DSN send: STARTTLS recv: 220 2.0.0 Ready to start TLS TLSv1.2 handshake succeeded. Cipher: TLSv1.2 ECDHE-RSA-AES256-GCM-SHA384 Peer Certificate chain: 0 Subject CN: mta.openssl.org Issuer CN: Let's Encrypt Authority X3 1 Subject CN: Let's Encrypt Authority X3 Issuer CN: DST Root CA X3 SAN dNSName: mta.openssl.org DANE TLSA 3 1 1 [6cf12d78fbf2...] matched EE certificate at depth 0 Validated Certificate chain: 0 Subject CN: mta.openssl.org Issuer CN: Let's Encrypt Authority X3 SAN dNSName: mta.openssl.org Connecting to IPv4 address: 194.97.150.230 port 25 recv: 220-mta.openssl.org ESMTP Postfix recv: 220 mta.openssl.org ESMTP Postfix send: EHLO cheetara.huque.com recv: 250-mta.openssl.org recv: 250-PIPELINING recv: 250-SIZE 36700160 recv: 250-VRFY recv: 250-ETRN recv: 250-STARTTLS recv: 250-ENHANCEDSTATUSCODES recv: 250-8BITMIME recv: 250 DSN send: STARTTLS recv: 220 2.0.0 Ready to start TLS TLSv1.2 handshake succeeded. Cipher: TLSv1.2 ECDHE-RSA-AES256-GCM-SHA384 Peer Certificate chain: 0 Subject CN: mta.openssl.org Issuer CN: Let's Encrypt Authority X3 1 Subject CN: Let's Encrypt Authority X3 Issuer CN: DST Root CA X3 SAN dNSName: mta.openssl.org DANE TLSA 3 1 1 [6cf12d78fbf2...] matched EE certificate at depth 0 Validated Certificate chain: 0 Subject CN: mta.openssl.org Issuer CN: Let's Encrypt Authority X3 SAN dNSName: mta.openssl.org [0] Authentication succeeded for all (2) peers.

tptacek 7y ago

Virtually no email sent on the Internet is protected by DANE, DNSSEC, or TLSA. Nor is it likely ever to be, since the major email providers standardized MTA-STS specifically to avoid DNSSEC, as you can see from the opening paragraphs of the standard.

alwillis 7y ago
This is provably false. DNSSEC, DANE and TLSA are widely used to secure SMTP servers. From the web page showing the nearly 2 million domains with signed MX and DANE records [1]: The following graph depicts the number of domains that have deployed DANE/SMTP. Specifically, their zone is signed, their MX records all point to hosts that have DANE TLSA records. Regarding MTA-STS, it's a work-around for the large global email providers that can’t implement DNSSEC for a variety of reasons. Again, MTA-STS has problems, the main one is being susceptible to downgrade attacks because MTA-STS doesn’t use DNSSEC. An attacker can MiTM a connection preventing a TLS connection. The MTA-STS RFC [2] confirms this: The DNS-Based Authentication of a Named Entities (DANE)TLSA record [RFC7672] is similar, in that DANE is also designed to upgrade unauthenticated encryption or plaintext transmission into authenticated, downgrade-resistant encrypted transmission. DANE requires DNSSEC [RFC4033] for authentication; the mechanism described here instead relies on certification authorities (CAs) and does not require DNSSEC, at a cost of risking malicious downgrades. There’s no dispute about any of this, so it’s not clear why you continue to make false and misleading statements about these technologies, regardless of your opinions about them. You know the old saying: you’re entitled to your own opinion but not your own facts. [1]: https://stats.dnssec-tools.org/#dnssec https://stats.dnssec-tools.org/#dnssec [2]: https://tools.ietf.org/html/rfc8461#section-2 https://tools.ietf.org/html/rfc8461#section-2 A more complete description I posted previously: https://news.ycombinator.com/item?id=22338742 https://news.ycombinator.com/item?id=22338742
- tptacek 7y ago
  As you well know, since this is the third time you've tried to make this point, the overwhelming majority of those zones were signed automatically by their European registrars; these counts have no relationship to actual emails sent. The entire idea behind STS protocols is to use continuity schemes to defeat downgrades. It's literally the only threat model.
  - alwillis 7y ago
    these counts have no relationship to actual emails sent These domains wouldn’t have MX or TLSA records unless they were doing email. Even if a zone is pre-signed, an admin has to intentionally create DANE records, which they wouldn’t do unless they were hosting SMTP servers. But it does show the statement that DNSSEC, DANE and TLSA aren’t used for secure email to be utterly untrue. MTA-STS has other issues: * Authenticates domain control via CA leap of faith * Vulnerable to MiTM at cert bootstrap * Vulnerable to weakest root CA, and unauthorized certs * Open to downgrade on first (or irregular) contact * Complex mix of HTTPS, unsigned DNS and SMTP
    - tptacek 7y ago
      Horseshit. I have something like 50 domains on a popular retail registrar and every single one of them has an MX record, despite me never doing a single thing other than claiming the name; they come by default with new domains. If I was in the Netherlands, every one of them would have DNSSEC signatures too, because European registrars opt domains into DNSSEC by default. I'm having a hard time articulating how silly it is to try to dunk on MTA-STS for being "vulnerable" to downgrade attacks; it's like trying to say that HSTS is vulnerable to SSL-stripping attacks. You have to not understand the idea behind the attack or the countermeasure to lead with that argument.
alwillis 7y ago
Virtually no email sent on the Internet is protected by DANE, DNSSEC, or TLSA. Here's a short list of domains that are using DNSSEC, DANE and TLSA to protect their email. I also provide a transcript of a utility that connects to and verifies the SMTP server and the DANE/TLSA records for openssl.org and could have done so for every domain on this list but there's no reason to get carried away. * geektimes.com * gmx.com * mail.com * comcast.net * dd24.net * debian.org * freebsd.org * gentoo.org * ietf.org * isc.org * netbsd.org * openssl.org * samba.org * torproject.org There's a DANE TLS SMTP server checking tool: https://www.huque.com/bin/danecheck-smtp https://www.huque.com/bin/danecheck-smtp Here's what it does: This application checks a DANE SMTP Service. It queries the MX record set for the given domain, looks up DANE TLSA records at the MX targets, connects to the target servers, negotiates STARTTLS, and then attempts to verify the TLS server certificate against the TLSA records. Lets test openssl.org: Domain Name: openssl.org MX host: 50 mta.openssl.org ################################################################# ### CHECKING MX HOST: mta.openssl.org ################################################################# TLSA records found: 1 TLSA: 3 1 1 6cf12d78fbf242909d01b96ab5590812954058dc32f8415f048fff064291921e Connecting to IPv6 address: 2001:608:c00:180::1:e6 port 25 recv: 220-mta.openssl.org ESMTP Postfix recv: 220 mta.openssl.org ESMTP Postfix send: EHLO cheetara.huque.com recv: 250-mta.openssl.org recv: 250-PIPELINING recv: 250-SIZE 36700160 recv: 250-VRFY recv: 250-ETRN recv: 250-STARTTLS recv: 250-ENHANCEDSTATUSCODES recv: 250-8BITMIME recv: 250 DSN send: STARTTLS recv: 220 2.0.0 Ready to start TLS TLSv1.2 handshake succeeded. Cipher: TLSv1.2 ECDHE-RSA-AES256-GCM-SHA384 Peer Certificate chain: 0 Subject CN: mta.openssl.org Issuer CN: Let's Encrypt Authority X3 1 Subject CN: Let's Encrypt Authority X3 Issuer CN: DST Root CA X3 SAN dNSName: mta.openssl.org DANE TLSA 3 1 1 [6cf12d78fbf2...] matched EE certificate at depth 0 Validated Certificate chain: 0 Subject CN: mta.openssl.org Issuer CN: Let's Encrypt Authority X3 SAN dNSName: mta.openssl.org Connecting to IPv4 address: 194.97.150.230 port 25 recv: 220-mta.openssl.org ESMTP Postfix recv: 220 mta.openssl.org ESMTP Postfix send: EHLO cheetara.huque.com recv: 250-mta.openssl.org recv: 250-PIPELINING recv: 250-SIZE 36700160 recv: 250-VRFY recv: 250-ETRN recv: 250-STARTTLS recv: 250-ENHANCEDSTATUSCODES recv: 250-8BITMIME recv: 250 DSN send: STARTTLS recv: 220 2.0.0 Ready to start TLS TLSv1.2 handshake succeeded. Cipher: TLSv1.2 ECDHE-RSA-AES256-GCM-SHA384 Peer Certificate chain: 0 Subject CN: mta.openssl.org Issuer CN: Let's Encrypt Authority X3 1 Subject CN: Let's Encrypt Authority X3 Issuer CN: DST Root CA X3 SAN dNSName: mta.openssl.org DANE TLSA 3 1 1 [6cf12d78fbf2...] matched EE certificate at depth 0 Validated Certificate chain: 0 Subject CN: mta.openssl.org Issuer CN: Let's Encrypt Authority X3 SAN dNSName: mta.openssl.org [0] Authentication succeeded for all (2) peers.