I only found https://github.com/mrisher/smtp-sts so far, but this is just docs. Any implementations in the works?
Internet Draft: SMTP Strict Transport Security
21–30 of 104 posts
Re: Internet Draft: SMTP Strict Transport Security
#22Earlier quoted context omitted.
"SMTP STS relies on the certificate authority (CA) system and a trust-on-first-use (TOFU) approach to avoid interception. The TOFU model allows a degree of security similar to that of HPKP [RFC7469], reducing the complexity but without the guarantees on first use offered by DNSSEC." Also, can be used with DANE for additional security.
If, like me, you believe the only real-world adversary for large-scale mail transport between places like Google and Yahoo is state-level actors and dragnet surveillance, then deploying DANE reduces your security, by tying you to trust anchors controlled by world governments. DANE is generally a bad idea, and it's great that STS is explicitly proposed as an alternative to it, not an application of it.
I agree that DNSSEC is a flawed technology and needs to be replaced, but I thought it can provide additional security (without doing harm) to STS against for example a malicious provider who can otherwise strip/modify the STS related records from the DNS traffic.
Re: Internet Draft: SMTP Strict Transport Security
#23It would be nice to also consider completely dropping support for non-TLS SMTP. Unlike HTTP where connecting to abandoned non-TLS websites can be useful, e-mail is only useful if someone is reading it, and if they are reading it they can take action to enable TLS.
Well, we missed out on mandatory encryption in HTTP/2, despite that requiring the webserver to turn it on, so for some reason we still have a lobby for unsecured communications.
Re: Internet Draft: SMTP Strict Transport Security
#24Earlier quoted context omitted.
"SMTP STS relies on the certificate authority (CA) system and a trust-on-first-use (TOFU) approach to avoid interception. The TOFU model allows a degree of security similar to that of HPKP [RFC7469], reducing the complexity but without the guarantees on first use offered by DNSSEC." Also, can be used with DANE for additional security.
If, like me, you believe the only real-world adversary for large-scale mail transport between places like Google and Yahoo is state-level actors and dragnet surveillance, then deploying DANE reduces your security, by tying you to trust anchors controlled by world governments. DANE is generally a bad idea, and it's great that STS is explicitly proposed as an alternative to it, not an application of it.
[deleted]
Re: Internet Draft: SMTP Strict Transport Security
#25Earlier quoted context omitted.
If, like me, you believe the only real-world adversary for large-scale mail transport between places like Google and Yahoo is state-level actors and dragnet surveillance, then deploying DANE reduces your security, by tying you to trust anchors controlled by world governments. DANE is generally a bad idea, and it's great that STS is explicitly proposed as an alternative to it, not an application of it.
I agree that DNSSEC is a flawed technology and needs to be replaced, but I thought it can provide additional security (without doing harm) to STS against for example a malicious provider who can otherwise strip/modify the STS related records from the DNS traffic.
Importantly, just as with HSTS, once you successfully retrieve a counterparty's STS data, it's no longer straightforward for an ISP to strip that data from the DNS; it's cached, like a cookie. Which means as well that everyone who deploys STS will potentially join a collaborative anti-surveillance surveillance network (also one of the neat things about TLS certificate pinning).
Re: Internet Draft: SMTP Strict Transport Security
#26do the same for the fucking DNS protocol, which is clear-text, it's the weapon of choice for all surveillance/censorship freaks and nobody cares about. And by 'nobody' I am not referring to actual random Joe users, but you - the fucking mastermind developers who create stuff that nobody cares about, hosted on .io domains just because it is cool and looks like some start-up that's about the be the next big thing. Plea…
DNSCurve - https://en.wikipedia.org/wiki/DNSCurve
Nobody is adopting DNSCurve anytime soon. The current two contenders are:
DNSCrypt: https://dnscrypt.org/ (pushed for ages by OpenDNS and supported by PowerDNS's dnsdist among others)
and, DNS over TLS: https://datatracker.ietf.org/doc/draft-ietf-dprive-dns-over-...
Re: Internet Draft: SMTP Strict Transport Security
#27Earlier quoted context omitted.
"SMTP STS relies on the certificate authority (CA) system and a trust-on-first-use (TOFU) approach to avoid interception. The TOFU model allows a degree of security similar to that of HPKP [RFC7469], reducing the complexity but without the guarantees on first use offered by DNSSEC." Also, can be used with DANE for additional security.
If, like me, you believe the only real-world adversary for large-scale mail transport between places like Google and Yahoo is state-level actors and dragnet surveillance, then deploying DANE reduces your security, by tying you to trust anchors controlled by world governments. DANE is generally a bad idea, and it's great that STS is explicitly proposed as an alternative to it, not an application of it.
The CA system already uses the DNS as a trust anchor, and will continue to do so as long as DV certs are the standard. DANE likely would not have enabled any form of attack that isn't already possible.
What DANE would have done is end the madness that allows me to hack your wordpress blog for a day and then go get myself a certificate for your domain, for free, that doesn't expire for three years. A certificate you will never be able to detect the issue thereof and cannot easily revoke if you do.
And STS isn't an 'alternative' to DANE. The two are completely orthogonal
Re: Internet Draft: SMTP Strict Transport Security
#28Earlier quoted context omitted.
If, like me, you believe the only real-world adversary for large-scale mail transport between places like Google and Yahoo is state-level actors and dragnet surveillance, then deploying DANE reduces your security, by tying you to trust anchors controlled by world governments. DANE is generally a bad idea, and it's great that STS is explicitly proposed as an alternative to it, not an application of it.
The CA system already uses the DNS as a trust anchor, and will continue to do so as long as DV certs are the standard. DANE likely would not have enabled any form of attack that isn't already possible. What DANE would have done is end the madness that allows me to hack your wordpress blog for a day and then go get myself a certificate for your domain, for free, that doesn't expire for three years . A certificate you…
Arguments like this presuppose that the TLS security system is exactly as it was in 1999. But, of course, it isn't: major sites all pin certificates now, so that if you're well-equipped enough to subvert a CA and you use it to try to subvert a major site, there's a very good chance that literally all you'll accomplish is getting that entire CA blacklisted.
STS and DANE aren't orthogonal. DNSSEC/DANE offers such marginal value to HTTPS that the browsers that once offered pilot support for it have now eliminated that code; it is off the roadmap for the web. The remaining motivating use case for DNSSEC was SMTP security; DANE was a way to ensure that MTAs used secure transports and avoided downgrade attacks.
But STS does the same thing without requiring the forklift replacement of DNS that DNSSEC requires.
Re: Internet Draft: SMTP Strict Transport Security
#29Why do we need to add support for protocols individually for this? Can't we just introduce a TLS extension and an API for detecting these "always use TLS" requests in OpenSSL etc.?
Re: Internet Draft: SMTP Strict Transport Security
#30Earlier quoted context omitted.
Then you must ask the OS vendors to include it, not startup developers. And in any case, encrypting DNS won't solve the surveillance issue, since the HTTPS handshake sends the domain in clear-text, so that the server knows which certificate to send ( https://en.wikipedia.org/wiki/Server_Name_Indication )
One could use a single certificate that is valid for all domain on the server
The client would still send the domain, since it doesn't known the server only has one certificate (the domain is sent in the first message, the ClientHello).