
Internet Draft: SMTP Strict Transport Security - jlgaddis
https://tools.ietf.org/html/draft-margolis-smtp-sts-00
======
zokier
Very interesting, seems like this would have potential to improve email
transit security quite a bit. It is encouraging to see Google, Microsoft,
Yahoo and Comcast in the authors, that would indicate that this has good
chance of being applied to large portion of internet email.

Of course email at rest security remains an issue, but that another story.

~~~
vonklaus
> encouraging to see Google, Microsoft, Yahoo and Comcast

For all intents and purposes this is most of the English speaking internet. If
you swap Yahoo for Verizon and Apple you'd be pretty close.

So, yeah encouraging to get this standard applied, less so if you think it is
good for the internet to offload an outsize share of control to 5-10
corporations.

~~~
AaronFriel
Is there anything about IETF standards that creates an outsize share of
control for a limited number of corporations?

~~~
dsr_
Only in the sense that larger companies can afford to fund their employees to
work on IETF standards groups, and are thus more likely to end up
contributing, editing and managing IETF groups.

The funding is not large, though: no dues, no grants, just the time that
people spend and airfare/hotels up to three times a year -- usually two of
those being inside the US. And it's possible to have quite a lot of impact
simply by volunteering your time in a group in which you have some expertise.

------
drdaeman
Can't we pretty much please make it reasonably generic and not SMTP-specific?

There are a lot of protocols (say XMPP, IRC or IMAP) around that have
opportunistic encryption with STARTTLS-like semantics. Surely, they could all
benefit from a similar solution.

~~~
userbinator
There are a lot more protocols that would benefit from the more generic and
much simpler solution of "define a standard port where the service listens
over TLS".

IRCS has settled on 6697:
[https://tools.ietf.org/html/rfc7194](https://tools.ietf.org/html/rfc7194)

IMAPS uses 993.

~~~
aexaey
Just having a dedicated port for TLS-wrapped version of the protocol wouldn't
help here. HTTPS has 443, yet we still need HSTS to enforce it.

That said, dedicated SMTPS port would still be beneficial by cutting down at
least 2 RTTs (HELO/EHLO + STARTTLS) from overall transaction time.

------
jcrites
Excellent! Strict transport security for SMTP has been sorely needed. Once
it's widely deployed, it will finally ensure that virtually all email
communication occurs over TLS.

TLS is already widely supported among large ISPs, but until now it has been
far too easy to fall back to plaintext. There wasn't any way for a receiving
ISP to ask all senders to use TLS and not fall back, which meant it happened
occasionally. It's why Google's "Safer Email" transparency report shows many
senders at 99% percent TLS, rather than 100%:

[https://www.google.com/transparencyreport/saferemail/](https://www.google.com/transparencyreport/saferemail/)

As receivers deploy strict TLS policies, and as senders add support, I expect
to see these numbers reach 100% and stay there. I look forward to having
strict TLS support in place in our email systems. Nice job making this happen,
folks who contributed!

~~~
baudehlo
We are working to switch Haraka to use TLS by default in all systems. A big
part of that is adding support for letsencrypt so that we can trivially create
a secure outbound certificate for every mail. This stuff is important and we
need to make email secure.

~~~
wizkkidd
[https://en.m.wikipedia.org/wiki/DNS-
based_Authentication_of_...](https://en.m.wikipedia.org/wiki/DNS-
based_Authentication_of_Named_Entities)

------
devit
It 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.

~~~
zanny
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.

~~~
MichaelGG
Except browsers won't implement non-TLS HTTP2. So for all the use cases that
matter, it's fine. Another good example of implementation trumping
"standards".

------
tptacek
Successful deployment of STS would bring to zero the number of real-world use
cases for DNSSEC/DANE, which would be a very good thing.

~~~
jimktrains2
Why? They solve different problems. DNSSEC/DANE moves the TLS CA into the
hands of the DNS hierarchy from various corporations. STS just says to use TLS
(with this cert, but you can only know the cert is OK to begin with because of
a CA, or DANE).

~~~
tptacek
Because the only remaining reason to deploy DNSSEC is to exploit DANE to allow
SMTP MTAs to force TLS. All the other uses of DNSSEC are already DOA.

It's a little tricky to explain why this is the case without getting into a
lot of gritty detail. A shorthand answer is that browser vendors have, pretty
much as a group, decided not to adopt DANE (the DNSSEC-based alternative to
the X.509 CA system), and DANE is the only reason anyone cares about DNS
security on an Internet where everything is going to be encrypted (usually
with TLS) by default.

~~~
colanderman
Is SSHFP not a legitimate use case for DNSSEC? (Genuinely curious.)

~~~
tptacek
No, SSHFP is pretty silly as a motivating use case for DNSSEC. There's nothing
it does that you can't do (better!) with some other system. It makes sense if
you _already have_ a secure DNS. But that begs the question of _why_ you would
need a secure DNS.

You don't need a secure DNS for the web.

You don't, with STS deployed, need a secure DNS for email.

Is publishing SSH key fingerprints so important that we should do a forklift
upgrade of the DNS? No, of course not.

~~~
AndyMcConachie
STS information is stored in DNS records. Why would you not want to secure
those?

Also, I think you're underestimating the growth of DNSSEC deployments. I've
been watching DNSSEC growth for about 2 years and it is steadily moving up and
to the right.

~~~
tptacek
It has taken _two decades_ to get to this point. The protocol has been
substantially revised _four times_ , and, after each of those four revisions,
DNSSEC proponents said "now, we've got it right, and it's ready for universal
deployment".

It is nowhere near ready for universal deployment today, and, indeed,
virtually nobody relies on it, unlike TLS.

~~~
AndyMcConachie
DNSSEC ain't pretty. I'll agree with you there, but that doesn't mean it isn't
the best thing going for us in terms of securing the DNS. Like it or not it's
important to be able to trust DNS responses.

I guess I don't have some expectation that deployment should take place
quickly. Or that the first go at a protocol is going to always get it right.
Just because a journey is difficult doesn't mean the journey isn't worth
taking.

DNSSEC and TLS are unrelated. They're trying to solve different problems.

~~~
tptacek
There is no point to securing the DNS. There are only downsides.

~~~
yuhong
*using DNSSEC

~~~
tptacek
I don't think there's any point to securing the DNS at all.

------
_RPM
Interesting to see the list of contributors from the various companies:
Google, Inc, Yahoo!, Inc, Comcast, Inc, Microsoft, Inc, LinkedIn, 1&1 Mail &
Media Development & Technology GmbH . One of my goals is to contribute to an
RFC.

~~~
virtuallynathan
Join a working group mailing list and pay very close attention. Most of the
work happens there, as opposed to at the 3x a year meeting.

~~~
_RPM
I'm currently subscribed to the DNSOP mailing list, which is really
interesting, except it's hard to follow since I just joined.

------
rubyfan
Is there a TL;DR version of how adding SSL will make it a whole lot better?
Sorry to be dumb on this subject but my understanding of how email works (in
particular SMTP) seems like the whole model is busted to begin with.

Are we still sending basically plain text unsigned messages using something
akin to the pony express? Does it matter that the pony express carriers
communicates securely so no bad guys can snoop the carriers bag of messages At
least in the old days you could put a wax seal on the letter to know the
letter was legit and not tampered with. With email the entire system is flawed
from the get go.

~~~
baudehlo
Here is my vague attempt at ELI5:

Email is sent via a protocol called SMTP.

SMTP goes over port 25 between major senders (there are other ports but forget
that for now).

Since it uses a single port, you can't distinguish between encrypted and plain
text communication until you know each end supports encryption. A dated
philosophy but people don't upgrade their email servers as often as they do
their web browsers so it made sense at the time.

Since the plain text receiving server says "yes I can do STARTTLS", this is
easy to man in the middle intercept and say "no encryption here" and the mail
goes through anyway.

Even if the receiving end says all mail must arrive over TLS the man in the
middle can currently circumvent that by receiving in plain text and forwarding
onwards via TLS

This is an RFC to try and prevent that happening.

This stuff is hard, and email nerds (via MAAWG and various other places) have
been working on this for years. We don't want to break your current email
service, and bringing things up to speed without breaking a ton of eggs has
been hurting email for a long time, but we spent too long stopping spam
instead of thinking about these problems. Sorry!

~~~
danmarg
I don't think the use of a single port is really at the heart of the problem.
Even if SMTP with TLS ran over port 26 (say), you wouldn't know if a timeout
on port 26 meant the server wasn't listening on port 26 or a MITM had just
chosen to drop your packets.

Discovering if someone supports Protocol++ if the fallback to Protocol is
insecure is a hard problem.

------
rurban
I only found [https://github.com/mrisher/smtp-
sts](https://github.com/mrisher/smtp-sts) so far, but this is just docs. Any
implementations in the works?

~~~
baudehlo
Everyone involved is working on implementations, as well as plenty who aren't
involved.

------
nly
Why 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.?

~~~
baudehlo
SMTP starts in cleartext. That's the problem.

You upgrade to TLS later. But only if the server says it can do that.

A MITM attack can easily say that the receiver can't do TLS and thus can see
everything that passes.

This RFC specifies a way to prevent this, assuming clients abide by the
requirements. It will be a long and slow roll out to get this done. But it is
worth it.

~~~
stonogo
This seems like the slowest possible way to make no useful change. Literally
every SMTP-capable software package on earth supports SMTPS on a dedicated
port, which requires no changes to protocol. Why not just formalize and
mandate this, instead of clinging to a braindead design that requires SMTP to
munge the transport level? STARTTLS is a hack. It is not something to be
preserved. If the goal is 100% TLS coverage, just mandate that (since everyone
already supports it) and move on.

This kind of bureacratic busywork is really, really frustrating. SMTP is nice
and simple and does not benefit from this proposal except in the most abstract
checklist-compliance sense.

~~~
danmarg
If you required TLS on all SMTP, you would in fact end up having to fail a
large number of messages.

Even worse, of the domains that support STARTTLS, a sizable number either
don't present certificates that chain to a widely trusted root, or don't
present certificates that actually match their MX. Worse still, because many
domains' MXs don't match the domain itself, even if the certificate is trusted
for the MX, it may not be trusted for the domain.[1]

So I think unfortunately we're not anywhere near a world where we could
actually just drop email on the floor if TLS-with-a-valid-cert isn't present
("valid" not being clearly defined here, of course). I do think we're slowly
moving in that direction[2].

It's certainly true that retrofitting security makes the whole thing more
complicated, of course. That's a strong argument for ensuring that any
retrofitting we do is itself forward-compatible with what we want to do in 30
years. Or for inventing time machines.

1\.
[http://static.googleusercontent.com/media/research.google.co...](http://static.googleusercontent.com/media/research.google.com/en//pubs/archive/43962.pdf)
2\. e.g. [http://arstechnica.com/information-
technology/2016/02/gmail-...](http://arstechnica.com/information-
technology/2016/02/gmail-to-warn-you-if-your-friends-arent-using-secure-
email/)

~~~
stonogo
>Even worse, of the domains that support STARTTLS, a sizable number either
don't present certificates that chain to a widely trusted root, or don't
present certificates that actually match their MX. Worse still, because many
domains' MXs don't match the domain itself, even if the certificate is trusted
for the MX, it may not be trusted for the domain.

This is madness, though. TLS is _transport-layer_ security. It's not kerberos
and it was never intended to be. The cert produced by the MX should be valid
for the MX. Trust is an illusion, but to the extent that you decide to trust
anything in the CA system, you trust it for the MX _only_ and use SPF etc to
determine if the MX is the correct one.

STARTTLS is a bad idea and should go away entirely. It forces an SMTP server
to care about the transport layer, and that's entirely incorrect. I have
plenty of SMTP servers that communicate on my networks without ever touching
TCP/IP -- forcing them to support STARTTLS specifically is moving _backwards_.

This RFC is strongly dependent on the internet looking pretty much exactly
like it looks today, and enforcing that mode of operation indefinitely. It's
short-sighted and harmful to the entire email world.

~~~
danmarg
But I think the authentication problem is in fact the hard problem. Assuming
we got rid of STARTTLS (the actual verb) and just always did TLS (say, on some
other port), how do you propose to solve it?

~~~
stonogo
Fortunately, we have an extensible protocol that already supports service
advertising and negotiation. There's no reason we can't have an AUTH module
that works both ways (both the client and server mutually authenticate,
independent of the transport-layer encryption).

------
Natanael_L
Those who have taken a close look, how comprehensive is this? Any risk of
downgrade attacks, etc?

~~~
jakobdabo
"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.

~~~
tptacek
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.

~~~
nly
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

~~~
tptacek
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.

~~~
nly
I don't know where to begin.

> Arguments like this presuppose that the TLS security system is exactly as it
> was in 1999

For the majority, it is. The % of sites that deploy _all_ of the latest HTTPS
bells and whistles, even just looking at the minority of sites that actually
enable TLS, is in the low single digits. Only 8% of sites surveyed by Qualys
SSL Labs... sites that are presumably run by people who care about security,
unlike my bank, even bother to enable HSTS.

> major sites all pin certificates now

My bank doesn't. Enabling HPKP and HSTS is just risky from a commercial point-
of-view. People aren't good at key management. If you botch it, you make your
site inaccessible and you lose customers.

People screw it up all the time. I've done it. I was speaking to someone just
today who was over-zealous with 'includeSubdomains' and made their product
blog inaccessible (it was on a blog subdomain, which had an invalid TLS setup
because wordpress.com don't support TLS on custom domains). It happens.

> if you're well-equipped enough to subvert a CA

Strawman, I never held this up as a threat. In any case, it's a bad defence of
PKI. Being able to choose from N CAs doesn't help you. You only have to
subvert _one_ CA to own the world, just like DANE, where an attacker only has
to break your registrar, or the domain registry, and you're toast. The 'world
governments' you fear have the capability and thensome. Irrelevant.

The threat I explicitly mentioned is that if I own your DNS, I can get myself
a cert for you domain. This has the same same threat models as DANE (if
"owning your DNS" involves me compromising your DNS server and getting your
DNSSEC keys, or guessing your domain registrar password), except DANE doesn't
depend on horrible, ineffective, and privacy-invasive, hacks like OSCP... or
allow me to simply keep certificates for domains I no longer own. DNS caching
effectively gives you the equivalent of OCSP stapling for free.

> major sites all pin certificates now

TLSA records have all the configurability and capability of HPKP and more, and
can be applied to any protocol/endpoint. They even cross the isle to work with
the CA system if you so desire, unlike HSTS+HPKP which has become hostile to
anything self-signed.

> STS and DANE aren't orthogonal

They are. DANE relates to key-pinning via TLSA records, not HSTS.

> forklift replacement of DNS that DNSSEC requires.

DNSSEC is backward compatible. You're talking twaddle. Enabling it these days,
if you control your own DNS server, also takes seconds. With EC digital
signatures, it's even sensible. Setting up HPKP+HSTS+OSCP stapling is far more
fiddley...and stuck in the RSA stone age.

~~~
tptacek
TLSA records _do not_ have that capability, and, more importantly, the root of
trust for TLSA records are organizations _controlled by the government_. The
"Five Eyes" partnership can replace signatures for any DNSSEC domain in .COM,
.NET, .ORG, .EDU, .UK, .AU, and .IO.

It seems crazy to me that, after years of hyperventilating about the
implications of the Snowden disclosures, anyone could take DNSSEC seriously.
But people do!

At this point, I'm just recapitulating things I've already written, so:

[http://sockpuppet.org/blog/2015/01/15/against-
dnssec/](http://sockpuppet.org/blog/2015/01/15/against-dnssec/)

~~~
xorcist
Your arguments does not make sense as a coherent whole. Any one may not be
wrong in itself, but the problems described are either not inherent to secure
DNS, or are something that is much worse with every other proposal (including
keeping today's system).

1\. Your main argument is that the NSA and its cohorts have control over a
handful of many top level domains available. But the same control that would
allow them to take control over domains and generate valid DNS signatures for
them does allow them to generate valid certificates in every proposed global
PKI system, including today's. There is literally zero difference in attack
space here.

2\. Several of the current CA institutions are under government control. Any
one can generate a valid certificate for any domain. It can be done without a
trace of evidence. The same active attack against a DNSSEC signed TLD would by
necessity be much more visible.

3\. Given that DV PKI is what TLS relies on, any adversary that can modify DNS
packets in-flight can also create a valid TLS certificate today. We know these
attacks are taking place from the Snowden documents.

4\. An attacker can choose which CA to attack, and pick the one that is
easiest to fool, does not participate in Certificate Transparency etc. There
are literally hundreds to choose from. You can mount an attack in advance.
Stuxnet suggests this is routine.

5\. There are no alternatives that solves what secure DNS does. Key pinning
and HSTS is important, but offer a trust-of-first-use model that can at best
be complementary to a PKI. It is also important to note that HSTS shares the
same deployment problems DNSSEC does. One mistake and your web server and
domain is inaccessible. That is the reason none of the banks offer neither
HSTS nor DANE. At least my bank sign their domain, so their step should be
small.

The smoke-and-mirrors argument that DNSSEC gives governments control over
"their" top level domains, when in fact it makes the scope of their control
much smaller and more well defined, would be expected from someone who wants
to maintain status quo as long as possible.

~~~
tptacek
I don't think many people want to read this deep into a tangent thread, so I'm
going to keep my response very terse.

1\. It's not my main argument, but, no: when a CA misbehaves, it is
blacklisted (Google's done this). Google can't blacklist .com.

2\. No. See FAQ.

3\. No. See FAQ.

4\. They can't do that if the certificate they're after is pinned. All they'll
accomplish is getting the CA killed.

5\. The thing DNSSEC secures simply doesn't need to be secured, any more than
the IP options header does.

~~~
xorcist
1\. That example is not very useful. It's hard to blacklist .com, but it's
even harder to blacklist Verisign. (Which by the way runs all of .com, and
they have full power to delegate any domain and any certificate to anybody.
This is not a theoretical attack.)

2/3\. If you mean the FAQ you wrote yourself, it's misleading at this very
point.

4\. Pinning is useful, but it isn't a PKI. It's equally useful no matter how
you issue certificates.

5\. Domain name delegation are one of the Internet's weakest points today.
Crypographic assurance of domain ownership would be very useful for a number
of reasons.

------
euyyn
Finally!

------
wizkkidd
LOL...bunch of stuff why/why not with DANE when DANE really solves this...

------
wizkkidd
Postfix supports Dane

------
wizkkidd
Disadvantages When Used Without DANE

    
    
       When deployed alone (i.e. without a DANE record, and using Web PKI
       for certificate verification), SMTP STS offers the following
       disadvantages compared to DANE:
    
       o  Infrastructure: DANE may be easier for some providers to deploy.
          In particular, for providers who already support DNSSEC, SMTP STS
          would additionally require they obtain a CA-signed x509
          certificate for the recipient domain.
    
       o  Security: DANE offers an advantage against policy-lookup DoS
          attacks; that is, while a DNSSEC-signed NX response to a DANE
          lookup authoritatively indicates the lack of a DANE record, such
          an option to authenticate policy non-existence does not exist when
          looking up a policy over plain DNS.

------
randomusr
do 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.

Please fix the DNS crap and you will be remembered in the history of those who
gave a damn about totally broken stuff.

~~~
jakobdabo
DNSCurve -
[https://en.wikipedia.org/wiki/DNSCurve](https://en.wikipedia.org/wiki/DNSCurve)

~~~
randomusr
you do realize that not even 0.001% of people use that, right? DNS has to be
encrypted by default for everyone. As in client -> recursor. Without any 3rd
party software.

~~~
icebraining
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](https://en.wikipedia.org/wiki/Server_Name_Indication))

~~~
malka
One could use a single certificate that is valid for all domain on the server

~~~
icebraining
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).

~~~
malka
oh yes very true. Had not thougth of that.

