
Ask HN: Why is there no common standard secure replacement for email? - parvenu74
It doesn’t seem like this should be difficult. HTTPS is the default now for web traffic; why don’t we have a secure-in-transit, secure-at-rest replacement for email?
======
twunde
Most email providers do offer encryption in transit and at rest email. Email
sent by any modern provider is sent over TLS. As proof both Gmail and
office365 are HIPAA compliant. There are also additional protections such as
DKIM that can be enabled. Or as otherwise mentioned, you can encrypt your
emails with an additional layer of encryption using keys that you manage so
that if Google/Microsoft/etc are exploited your emails are still encrypted.

------
fsecond722
With ur use of so many technical terms I guess u are a real IT guru. I would
like us to be friends. I think we will fit together well

------
crooked-v
Because everybody else is using email.

------
userbinator
PGP is the standard but most people don't use it, because it is not so easy to
use.

------
md_
The one-word answer is "federation."

What makes email (by which, here and below, I mean SMTP) universal is what
makes it hard to retrofit (with new protocols or standards): it's federated,
relying only on DNS for namespacing (i.e., for discovering the authoritative
owner for a given user identifier), and it's widely implemented.

Skipping over the "secure-at-rest" statement for a moment, the difference
between HTTPS and email is that HTTPS has _user-facing_ security: the choice
to use encryption is user-facing (if the user manually typed "HTTPS"), the
actual use of encryption is user-visible (in the URL bar), and what to do if
authentication fails can be decided by the user (with an error message and a
possible user override).

Email does not have this, which results in a few distinct problems:

1\. Users do not, typically, know if they are going to be using secure
transport, so there's no market incentive at work here (to use a provider who
offers, say, STARTTLS or DANE). Hypothetically, a provider could offer users
the ability to require STARTTLS on a sent message (see
[https://datatracker.ietf.org/doc/draft-fenton-smtp-
require-t...](https://datatracker.ietf.org/doc/draft-fenton-smtp-require-tls)
and associated discussions in the working group for arguments against this
approach) or could try to expose DANE or MTA-STS
([https://datatracker.ietf.org/doc/draft-ietf-uta-mta-
sts/](https://datatracker.ietf.org/doc/draft-ietf-uta-mta-sts/)) status at
message compose-time, but since delivery time and compose time are different,
and delivery happens asynchronously in the background (from the user's
perspective), it's hard to really make this a UI feature.

2\. Absent something like "require-tls", MTAs can't always determine
encryption support for a given recipient. Because recipient MX resolution
ultimately has to support unencrypted DNS, senders _always_ have to support
falling back to unauthenticated MX records and, consequently, unauthenticated
delivery. One of the few (or, as tptacek says, only) useful applications of
DNSSEC is solving this problem: by allowing authenticated discovery of
_DNSSEC_ _support_ from the root server on down, DNSSEC allows senders to see
if a recipient domain _should_ support DNSSEC, _does_ support DNSSEC, and, via
DNSSEC, what the authenticated MX (and, optionally,TLSA) records are for that
domain and the MX. But DNSSEC has a host of its own problems, is not widely
deployed, and would not fix #1 above, so senders still wouldn't know _if_
their message would be encrypted in transit!

3\. PGP and S/MIME are the standards for end-to-end encryption and can be
layered on top without support from the MTA or host, but both suck for a
variety of reasons: they're often hard to use, they break webmail (which is by
far the most common usage), they often break multi-device or multi-client
usage (e.g. webmail and smartphone), they don't provide modern cryptographic
features (like PFS), they often have no good/secure means of automated key
discovery (unless you want to meet a bunch of beardy men at a party), etc.

If all of that is too longwinded, I think the simple explanation is
federation, without a resource locator that indicates preference for or
support of secure delivery, resulting in a protocol that is hard to retrofit
against downgrade attacks.

~~~
fsecond722
With ur use of so many technical terms I guess u are a real IT guru. I would
like us to be friends. I think we will fit together well

~~~
md_
For sure. DM me your ICQ and we will chat.

