Subject: [ietf-smtp] guidance on how to secure against sniffing and paid backdoors

From: [email-masked]
Date: Sat, 14 Sep 2013 03:56:49 +0200

Recently there has been reports in newspapers about powerful organisations that
can sniff on wires and has paid for backdoors and compromising cryptographic implementations.

Would it be a good idea to make a document describing best practices trying
to protect against such actions, to guide implemetors and service providers?

best regards
keld

---

From: Timo Sirainen <[email-masked]>
Date: Sat, 14 Sep 2013 05:37:36 +0300

> to protect against such actions, to guide implemetors and service providers?

I've been considering an SMTP client extension (especially for submission clients) where they can require that the mail be delivered via TLS, and have the server reject/bounce it if that's not possible. The main problem I see is relay servers that can accept the mail via TLS and then happily forward the mail over plaintext connection to the other side of the world.. Then again, there may be other ways to handle this, for example Germany has already started something like this with their "Email made in Germany" project. Other countries have expressed similar interests. Maybe something more standard could be developed..

---

From: "Carl S. Gutekunst" <[email-masked]>
Date: Fri, 13 Sep 2013 20:33:39 -0700

> I've been considering an SMTP client extension (especially for submission clients) where they can require that the mail be delivered via TLS, and have the server reject/bounce it if that's not poss…

It's an appealing idea, and several vendors already have proprietary 
implementations to do this. Obviously it only works end-to-end when 
every hop uses the same vendor; but in the case of cloud vendors that's 
all they feel they need. I wanted to publish a standard around it, but 
my employer at the time totally killed the idea, in part (I suspect) 
because they wanted to claim it as a competitive advantage.

The "must use TLS" flag does not, however, add that much in the way of 
real security. The message is still exposed in the clear at the relays, 
DSNs create all kinds of opportunities for leakage, and most SMTP hops 
are still trivially hijackable. My customers that actually were serious 
about using TLS for Email security essentially created Email VPNs, with 
rigorous certificate checking on every hop and regular probes that 
verified all paths were still secure. They viewed the "must use TLS" 
flag is one more layer on the onion, not a solution of itself.

Perhaps this is the time to revive Chris Newman's idea for combining 
S/MIME or PGP with the Batch SMTP content type. That technique encrypted 
the envelope as well as the message content. I think the patent troll 
that was in this space has finally gone away.

<csg>

---

From: Sabahattin Gucukoglu <[email-masked]>
Date: Sat, 14 Sep 2013 08:18:41 +0100

> I've been considering an SMTP client extension (especially for submission clients) where they can require that the mail be delivered via TLS, and have the server reject/bounce it if that's not poss…

We can already do that, by just configuring SMTP servers properly to do the required levels of TLS verification and choosing submission servers that are known to trust a set of verified recipient domains.  We just need a way to extend that to the whole Internet, using DNSSEC (which does introduce a vulnerability in the form of the registries, it's true).  Sadly, in either case, the user does not know which domains are truly end-to-end secure, though tools could be invented to look it up in DNS and ISPs could publish lists of the known domains, so the user knows before sending email which would otherwise be compromised if the next hop was not using TLS.  That is, if the user realistically cares, or is willing to check for every email, or is willing to send a message twice to find out …

But really, PGP is the answer you're looking for. :)

Cheers,
Sabahattin

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Sat, 14 Sep 2013 16:32:31 +0200

Timo Sirainen <[email-masked]> writes:
> I've been considering an SMTP client extension (especially for
> submission clients) where they can require that the mail be delivered
> via TLS, and have the server reject/bounce it if that's not possible.

This is exactly how EAI makes sure mail doesn't leave the subset of MTAs
that support EAI, and AFAICT it works. For the few people who have EAI
deployed, I mean.

I like it. Some naysayers will tell you it's worthless because it only
guards against snooping (and perhaps MITM attacks to some degree), not
against subverted MTAs or MUAs. Don't listen to them. Snooping is the
only attack that scoops up many, many people's email with O(1) effort
for the attacker, so a mechanism that stops snooping forces up the
attacker's cost drastically.

Arnt

---

From: Martijn Grooten <[email-masked]>
Date: Sat, 14 Sep 2013 15:31:17 +0000 (UTC)

On Sat, 14 Sep 2013, keld wrote:
> Recently there has been reports in newspapers about powerful 
> organisations that can sniff on wires and has paid for backdoors and 
> compromising cryptographic implementations.
>
> Would it be a good idea to make a document describing best practices 
> trying to protect against such actions, to guide implemetors and service 
> providers?

If "such actions" involve backdoors in implementations and standards, and 
possibly secret mathematical knowledge that can help crack cryptography, 
then protecting against them is beyond the scope of email. (In this 
particular case, it's probably beyond the technical realm.)

A separate question, that others are trying answer in this thread, is: 
assuming we have working cryptography, how can we use that to make email 
more secure? That's a tough question and I think that ultimately, if 
information is to be kept really secret, it shouldn't be sent over email.

In cases where the fact that communication takes place is not a secret, 
and you're not worried about metadata leaking, something like PGP would 
probably work. But that doesn't scale. And in many cases metadata does 
matter.

Of course, the fact that certain agencies can, in principle, read all your 
emails shouldn't stop you from protecting it from the prying eyes of 
others. So using SSL/TLS wherever possible is a good thing. But a few 
commercial providers offering what's been standard in many other systems 
for years, like the "email made in Germany" project, is a marketing stunt 
at best.

Martijn.

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Sat, 14 Sep 2013 16:45:44 +0200

> But really, PGP is the answer you're looking for. :)

I hate to say this, but this is the kind of thing NSA shills say: Point
out some magnificent foobar that certainly will not be deployed, focus
on it, and hope that nothing merely good will get traction.

I have some ideas about why PGP fails so miserably, but that doesn't
really matter. Whatever the reason is, PGP has a twenty-year history of
disuse, so I'm fairly sure that in five years, only a very few people
will use it and its users will not be able to hide in a crowd.

Arnt

---

From: [email-masked]
Date: Sat, 14 Sep 2013 17:02:12 +0200

> will use it and its users will not be able to hide in a crowd.

Yes, PGP has not been thta successful.

Furthermore pgp still leaves metadata in the clear for sniffers.
starttls does not. That is the To: and From: headers are only transmitted
after the TLS handshake has taken place, and thus the metadata is sent encrupted.

I am thinking of an advice to application developers to always
have TLS on by default, and til service providers to
always have TLS enabled by default. Still they should in my mind
communicate with non-TLS enabled MTAs - and then over some tile everybody
will have migrated to TLS, just like we did with the SMTP -> ESMTP 
migration.

best regards
keld

---

From: "John Levine" <[email-masked]>
Date: 14 Sep 2013 15:17:20 -0000

>on it, and hope that nothing merely good will get traction.

It seems to me quite a leap of faith to believe that people who don't
use S/MIME or PGP would or could persuade all the intermediate MTA
operators that might handle their mail to implement an extension that
doesn't even exist yet.

Anyone who wants to do opportunistic STARTTLS can do so right now, but
the fraction who do appears no greater than the fraction of users who
use PGP or S/MIME.

R's,
John

---

From: Sabahattin Gucukoglu <[email-masked]>
Date: Sat, 14 Sep 2013 16:24:55 +0100

> will use it and its users will not be able to hide in a crowd.

Yes.  Absolutely correct; PGP will remain the clique solution exclusive to fumbling Guardian journalists and tinfoil hat-wearing conspiracy nutters.

I don't know that I could confidently say that it is PGP's implicit trust model that's FUBAR for ordinary use.  I definitely think, though, that the "Defence in depth" strategy of eventual upgrade to TLS has a better chance of providing useful results (second place in my mind goes to S/MIME with web-based automatic provisioning).

But, and this is the reason I made the comment, PGP right now provides useful security.  It's not easy, but it does *EXACTLY* what it proposes to do.  That's a whole lot better than the uncertainty of anything dependent on hop-by-hop message transfers, at least at the moment.

Cheers,
Sabahattin

---

From: [email-masked]
Date: Sat, 14 Sep 2013 17:40:23 +0200

> But, and this is the reason I made the comment, PGP right now provides useful security.  It's not easy, but it does *EXACTLY* what it proposes to do.  That's a whole lot better than the uncertainty…

Well STARTTLS does not preclude use pf PGP.  You can just use both.

There are not that many MTA implementations out there so if we can persuade
implementers to provide STARTTLS per default, I see this as a path
with good chances to succeed. We could even advise implementers to generate an auto-signed 
certificate. This guidance could be done in an RFC.

best regards
keld

---

From: Sabahattin Gucukoglu <[email-masked]>
Date: Sat, 14 Sep 2013 16:55:56 +0100

> certificate. This guidance could be done in an RFC.

How do you propose that receivers verify self-signed certificates?

Note that many MTAs (Exchange, notably) will fail delivery if STARTTLS is offered, but verification does not succeed.  This is stupid because Exchange will happily deliver to hosts if STARTTLS is not advertised, so it's an inconsistent policy.  (The solution for postmasters is then to either maintain a table of known stupid hosts, or [as in my case] just turn off server TLS.)

Cheers,
Sabahattin

---

From: [email-masked]
Date: Sat, 14 Sep 2013 21:31:40 +0200

> How do you propose that receivers verify self-signed certificates?

They should not verify the self-signed certificates, per default.
As you say below, a self-signed certificate is much more secure than
a server without any certificate.
Furthermore, admins could install a proper certificate on top of default installation.

> Note that many MTAs (Exchange, notably) will fail delivery if STARTTLS is offered, but verification does not succeed.  This is stupid because Exchange will happily deliver to hosts if STARTTLS is n…

Well, it is expected that there are implementations that are counter-productive to enhancing security,
also from big companies.  We will probably also meet resistance from security experts trying to
diverge succesful specifications. 

Yes, we could meintain a table of known stupid hosts. This could be in the form of a RBL, 
and it could be generated by periodically traversing the full DNS tree and try to send  a message to all
of the hosts with a port 25 open.

Best regards
Keld

---

From: Mark Andrews <[email-masked]>
Date: Sun, 15 Sep 2013 08:41:42 +1000

In message <[email-masked]>, Sabahattin Gucukoglu 
> How do you propose that receivers verify self-signed certificates?

Truly, to stop sniffing you don't have to verify you just have to encrypt.

As for verifying, DNSSEC and TLSA will provide a framework to do just that.
If there is a TLSA record and you have securely verified it then you close
the connection on TLS failure to verify.  If you can securely verify that
there isn't a TLSA record or securely verify the TLSA response is insecure
then you just accept the offered CERT unless you have other knowledge the
CERT is invalid.
 
> Note that many MTAs (Exchange, notably) will fail delivery if STARTTLS is off
> ered, but verification does not succeed.  This is stupid because Exchange wil
> l happily deliver to hosts if STARTTLS is not advertised, so it's an inconsis
> tent policy.  (The solution for postmasters is then to either maintain a tabl
> e of known stupid hosts, or [as in my case] just turn off server TLS.)
> 
> Cheers,
> Sabahattin
> 
> _______________________________________________
> ietf-smtp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf-smtp
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: John C Klensin <[email-masked]>
Date: Sat, 14 Sep 2013 21:37:38 -0400

--On Saturday, September 14, 2013 17:02 +0200 [email-masked]
wrote:

>...
> always have TLS enabled by default. Still they should in my
> mind communicate with non-TLS enabled MTAs - and then over
> some tile everybody will have migrated to TLS, just like we
> did with the SMTP -> ESMTP  migration.

Maybe.   How useful it is depends tremendously on the threat
model.  If the threat is, for example, a government body that
can compel email providers to hand over whatever is stored on
their servers (or even worse to capture and store things passing
through those servers so that it can be handed over) then TLS or
anything else that protects links on a hop by hop basis is
completely useless and will remain so.  If the concern is
protecting content that leaves end to end encryption methods and
we can amuse ourselves arguing and which of the PGP or S/MINE
models have more issues and if we can devise something better.
If the concern is protecting information about who is sending
messages to whom (i.e., hiding the forward and backward-pointing
addresses), I think we are in big trouble and that it is
unlikely that TLS is really the answer (although it can
certainly help in non-relay transmissions between mutually known
and trusted senders and receivers.

   john

---

From: [email-masked]
Date: Sun, 15 Sep 2013 14:41:45 +0200

On Sat, Sep 14, 2013 at 09:37:38PM -0400, John C Klensin wrote:
> > have TLS on by default, and to service providers to
> > some time everybody will have migrated to TLS, just like we
> completely useless and will remain so. 

Well, it is probably not all governments that has this ability.
Aware customers could then change to service providers in countries that
don't have such legal provisions. Even unaware customers could do
so, when eg. "German mail" becomes a big household name.

> If the concern is

Wouldn't STARTTLS prevent the address sniffing, as the
receiver and sender addresses will be encrypted?
You can only see which MTA is communicating which MTA, and for 
bigger MTAs that would certainly cover for which individuals 
that are communicating with which other individuals. One could
even introduce a random small delay for relayed email.

best regards
keld

---

From: John C Klensin <[email-masked]>
Date: Sun, 15 Sep 2013 16:46:43 -0400

--On Sunday, September 15, 2013 14:41 +0200 [email-masked]
wrote:

>> their servers (or even worse to capture and store things
>> passing through those servers so that it can be handed over)
>> then TLS or anything else that protects links on a hop by hop
>> basis is completely useless and will remain so. 

> Aware customers could then change to service providers in
> countries that don't have such legal provisions. Even unaware
> customers could do so, when eg. "German mail" becomes a big
> household name.

This is moving into the space that is probably not appropriate
for this list, but...    Just as we have moved into an age in
which a would-be spammer, online thief, or cracker no longer
needs the technical sophistication do invent and implement the
needed techniques but can buy a kit or subcontract the work, a
government that don't have the capability doesn't either because
they don't care enough to participate in large-scale snooping or
don't feel like making the investment.  And "legal provisions"
are somewhat the same.  It is, for example, fairly widely
believed that nearly indiscriminate data interception and
storage isn't legal in the US either.  

Worse, under US law (and, I understand, equivalent laws in many
other countries), it is illegal to intercept my communications
with other US citizens within the US without specific evidence
that we are breaking the law but entirely legal to intercept
communications with people or servers in other countries.  There
is a very common government mentality of "if you had nothing to
hide, why are you doing that?".  It has even led to some
governments that are not obviously repressive banning encryption
with the claim that honest people in open societies don't need
it and therefore only criminals and other evil people will want
to encrypt.

In that regard, one would actually have to intercept and inspect
this message to know whether it is encrypted.  If it were going
through an encrypted tunnel to a far-away submission or
distribution server, finding that out would merely require
detecting and compromising the target of the tunnel connection.  

I want to stress that I'm not arguing against either encrypted
tunnels (TLS or otherwise) or content encryption (PGP, S/MIME,
or otherwise) if they seem to make sense.  And there is no doubt
that any of them would contribute, in different ways, to making
indiscriminate surveillance of different types harder and more
expensive.  I'm just suggesting that we need to be careful about
our threat models and the responses to them and that we
understand that there are unlikely to be any magic and
all-conquering bullets in either particular technologies or
particular types of government policies and initiatives.

>> If the concern is
>> protecting content that leaves end to end encryption methods
>> and we can amuse ourselves arguing and which of the PGP or
>> S/MINE models have more issues and if we can devise something
>> better. If the concern is protecting information about who is
>> sending messages to whom (i.e., hiding the forward and
>> backward-pointing addresses), I think we are in big trouble
>> and that it is unlikely that TLS is really the answer
>> (although it can certainly help in non-relay transmissions
>> between mutually known and trusted senders and receivers.
> 

Again, two answers: "yes" and "it depends".  If an attacker,
especially a governmental one, can compromise the paths between
transport server and transport server, they can probably
compromise the paths between at least one of those servers and
the submission process or the other and the delivery one.  That
lets them at least figure out who is using which mail systems
and mail-routing systems.   If they are suspicious of those
people to the extent needed to overcome whatever practical
restrictions exist in national law, I can use that information
to seek court orders (or equivalent) to get that mail exposed by
the server operator.  My best protection about that type of
attack is to use a lot of different submission and relay
servers, but that considerably raises my operational and
aggravation costs. 

FWIW, I note that,  a very long time ago, we deprecated the
explicit source routing for email that would have permitted my
MUA to specify where the message is to be submitted or what the
submission server is to use as a next hop on a per-message basis
and that we've discouraged arbitrary relaying.  If we hadn't
imposed those restrictions on ourselves (however good the
reasons), it would be relatively easy to design an MUA that
would be able to utilize a dozen different submission servers,
each of which could distribute to a dozen other first-hop relay
servers, all more or less at random and under MUA control and
all with encrypted tunnels.  It wouldn't be hard (e.g., by use
LMTP streams over TLS) to use content encryption up to the
second server in the path to prevent the submission server from
storing clear-text content without having to deal with the PKI
or PGP scaling problems in significant ways.   That would make
the protection you expect to get from TLS vastly stronger
because many courts that might issue orders for particular
messages or message groups on one particular server (or servers
operated by one company) are loathe to issue orders to multiple
server operators for messages that _might_ have passed through
there.

Along those same lines, if one really wanted to secure messages
in this sort of environment, the easiest way would be to abandon
SMTP and all of that relaying entirely and go to a centralized
email model in which I submit messages to a server (or
commonly-controlled and trusted server collection) over a
strongly-encrypted connection and the recipient picks it up
using POP, IMAP, or direct login, again over strongly-encrypted
connections.  Then one would only need to insure that the
servers/ mail stores were adequately protected against being
compromised and out of the reach of the courts or intelligence
apparatus of any country one were worried about.    That model
would essentially kill email to arbitrary people on arbitrary
hosts and mailing lists as we know them, but it is rare that
those communications need to be highly protected. 

It is worth noting that traditional postal mail, especially
postal mail in which senders have to drop messages off at the
post office and recipients have to pick messages up from the
post office after appropriately identifying themselves, is
essentially equivalent to that centralized mail system model,
usually with the added advantage of unauthenticated senders, as
long as one is willing to accept the "you can trust me, I'm the
government" assumption.  But perhaps "German mail" ultimately
comes down to that too.

So, again, let's try to understand the threat model and what
problems we are solving.  If the goal is simply to make random
snooping enough harder to increase costs and aggravation for the
snooper (as others have suggested) we have to do more than we
have been doing but it probably isn't really hard.   If the goal
is to protect particular messages (or all messages) against a
determined attacker with legal and financial resources.. well,
that is a different problem.

 best,
    john

---

From: Paul Smith <[email-masked]>
Date: Mon, 16 Sep 2013 09:25:40 +0100

On 14/09/2013 03:37, Timo Sirainen wrote:
> The main problem I see is relay servers that can accept the mail via 
> TLS and then happily forward the mail over plaintext connection to the 
> other side of the world..
You could have an extension which passes on the 'must use TLS extension' 
flag with the message (similar to the DSN extension).

You would have to treat the onward mail server as not supporting TLS if 
it doesn't support your extension, because, as you say, that server may 
well send the message over a plaintext connection if it has to, without 
letting you know.

However, a big problem would be what to do if you can't send mail using 
TLS. Most recipients won't know that their mail server doesn't support 
TLS, or that a mandatory upstream mail server doesn't support TLS.

Also, I'm not really sure that this would achieve much, depending on 
what you think the threat signature is.

For instance, theoretically a government could compromise servers 
belonging to big providers or implement MITM attacks (eg by faking DNS 
data sent across international links) to intercept messages. These would 
"bypass" any TLS encryption, and not be that hard to do if they have 
compromised international links.

End-to-end encryption (eg PGP) would help here, or (possibly) a 
centralised mail system held in a 'safe' location (if such a thing exists).

How secure do you want to be?

TBH, I don't care except on a philosophical level. I never send anything 
private by email (I've always understood that an email is as secure as a 
postcard). If I was to want to send something so private I didn't want a 
government to know, I wouldn't rely on TLS.

If a government wants to spy on my messages about DIRTY spam BOMBs on 
people in families which may or may not be NUCLEAR, then that's up to 
them, I really don't care.

-

Paul Smith Computer Services
Tel: 01484 855800
Vat No: GB 685 6987 53

---

From: [email-masked]
Date: Mon, 16 Sep 2013 12:32:02 -0400

> server operators for messages that _might_ have passed through

That's basically re-inventing SMTP-over-TOR.

And I suspect the court order issue is a total red herring, as it's
pretty clear that many of the big players in the threat model don't
actually bother worrying about whether they can get a court order
or not.

---

From: James Cloos <[email-masked]>
Date: Mon, 16 Sep 2013 14:41:52 -0400

>>>>> "SG" == Sabahattin Gucukoglu <[email-masked]> writes:

SG> We just need a way to extend that to the whole Internet, using DNSSEC

If the recipient domain publishes TLSA RRs for its MXs, and if the MX,
address and TLSA lookups are all dnssec-verified, DANE-complient MTAs
will insist on TLS (including that the tls cert provided by the MX
matches the TLSA RR) to deliver the mail.

An example of such an mta is postfix 2.11 with the configuration:

smtp_use_tls = yes
smtp_dns_support_level = dnssec
smtp_tls_security_level = dane

That config will fall back to unverified tls or to unencrypted smtp if
necessary in the absense of dnssec or tlsa records.  But if the dns
results are bogus (per dnssec), if the tlsa does not match the offered
cert, or of anything else prevents the tls negotiation, then it will
defer delivery until it works or until the mail times out and bounces.

-JimC
-- 
James Cloos <[email-masked]>         OpenPGP: 1024D/ED7DAEA6

---

From: [email-masked]
Date: Wed, 18 Sep 2013 16:11:47 +0200

> storage isn't legal in the US either.  

Well, which other lists would you suggest for dealing with 
security issues for the SMTP/ESMTP protocols?
I am happy to leave out all the political discussions and
focussing on the technical issues.

> particular types of government policies and initiatives.

Yes, we are only improving some aspects of SMTP, and we probably
cannot deal with all problems. I think, however, that we 
as IETF can make a reasonable impact to improve the situation.

I also agree that in many nations it is illegal to generally
sniff on domestic communications, but when traffic crosses national
borders this is a different situation. Furthermore sniffing
can be done also by individual criminals, eg on wireless connections.

> that is a different problem.

Well, we all know that we cannot make email completely secure.
I want to enhance want to enhance general SMTP transmission
to run on TLS, and to make a model for transition to that
state. The problem that we can solve in this way is a partly one.
I do not expect that we can make commercial vendors follow us.
Some of them ar paid to make email insecure and even if they
promise to follow our new guidelines, I think in general
they have lost their credibility by selling out their customers'
security for money or for other threats.

The problems to solve are known for a long time, snooping on lines. 
We can rebuild a part of the internet in a safer version.
To have a chance to make some impact, I believe
it is necesary to build safer defaults into major MTAs like
postfix and sendmail. And as these are general, we need that 
the defaults are not harmful to exising mail in the transition period.
Also we need to communicate with inherenly unsafe commercial MTAs.

Then we can build some stricter flags into the specifications, but in my mind
that cennot be part of the advised defaults.

Best regards
Keld

---

From: Paul Smith <[email-masked]>
Date: Wed, 18 Sep 2013 15:32:17 +0100

On 18/09/2013 15:11, [email-masked] wrote:
> We can rebuild a part of the internet in a safer version. To have a 
> chance to make some impact, I believe it is necesary to build safer 
> defaults into major MTAs like postfix and sendmail.
My concern is that while something like TLS will have an effect on 
criminals snooping on wireless networks etc, I can't see how it would 
definitely help against governments.

The issue is - how do I know that the mail server I am sending the 
message to is the one I should be sending the message to? If I don't 
know that with a good degree of certainty, then using TLS won't achieve 
security, because I could simply be dumping my messages on a compromised 
server.

DNS, IP addresses and certificates could all be subverted by a 
government at a 'choke point' such as an international link. Even if I 
knew for certain that '123.123.123.123' was the IP address I should be 
talking to (which is unlikely), it would be trivial for a router at a 
choke point to redirect that IP address to another machine instead of 
the one it was supposed to go to. If I am allowed to validate 
certificates (which is currently doubtful), then I'd have a bit more 
certainty, but, to be honest, can I trust that a CA won't issue fake 
certificates to a government?

Yes, use TLS where you can - it won't do any harm, and is better than 
not using TLS - but don't expect it to do anything significant to stop a 
government from snooping if it wants to, except with pre-known 
certificate fingerprints. I'd be reluctant to risk breaking 
interoperability to force TLS usage, because of the dubious benefit.

-

---

From: John C Klensin <[email-masked]>
Date: Wed, 18 Sep 2013 11:24:52 -0400

I will probably reply in more detail to Keld's note later, but I
Paul's comment is an important part of the puzzle.  

Inline...

--On Wednesday, September 18, 2013 15:32 +0100 Paul Smith
<[email-masked]> wrote:

>>  The problems to solve are known for a long time, snooping on
>>  lines.  We can rebuild a part of the internet in a safer
>> version. To have a  chance to make some impact, I believe it
>> is necesary to build safer  defaults into major MTAs like
>> postfix and sendmail.
> My concern is that while something like TLS will have an
> effect on criminals snooping on wireless networks etc, I can't
> see how it would definitely help against governments.
> 
> The issue is - how do I know that the mail server I am sending
> the message to is the one I should be sending the message to?
> If I don't know that with a good degree of certainty, then
> using TLS won't achieve security, because I could simply be
> dumping my messages on a compromised server.

And, even if you know that it is the "right" server, how do you
know that the server itself has not been subverted by whatever
government (or criminal) you are concerned about?  I hope it is
obvious that subversion by cooperating governments is the same
problem from our point of view.

If one is concerned about governments or entities that can
adequately disguise themselves as a relevant government (legally
or not), how does one distinguish whether "Slobbovian email"[1]
is "safe from snooping" or just "safe from snooping from
everyone but us (and whomever can subvert us or issue secret
court orders to us)".
 
> government at a 'choke point' such as an international link.
> Even if I knew for certain that '123.123.123.123' was the IP
> address I should be talking to (which is unlikely), it would
> be trivial for a router at a choke point to redirect that IP
> address to another machine instead of the one it was supposed
> to go to. If I am allowed to validate certificates (which is
> currently doubtful), then I'd have a bit more certainty, but,
> to be honest, can I trust that a CA won't issue fake

Or that a CA that gets its hands on or generates the private key
won't supply it to the government or somehow create a back door?

> Yes, use TLS where you can - it won't do any harm, and is
> better than not using TLS - but don't expect it to do anything
> significant to stop a government from snooping if it wants to,
> except with pre-known certificate fingerprints. I'd be
> reluctant to risk breaking interoperability to force TLS
> usage, because of the dubious benefit.

Right.  And that is both the strength and weakness of using an
EAI-like approach.  There is no problem with using the
readily-available and widely deployed extension tools to do a
handshake.  In the EAI case, if the handshake fails, it is
reasonably obvious that one either has to radically transform
the message or bounce/refuse it.  But here, it seems to me that
Paul's argument is important and the tradeoffs about what do to
if TLS is not available, or not available with a cert that the
sender considers reasonable, get complicated with no one rule
being right for all cases

best,
   john

[1] No slur on Germany intended in part because the ideas behind
"German email", as I understand them, are nothing new.  In
particular, the US Postal Service tried to set up a "we will
handle the email traffic and you can trust us" system many years
ago.   They also proposed to operate a CA. Independent of the
administrative and technical difficulties with that proposal, I
think we would have to assume that, if that system existed
today, it would be at least as subject to server data compromise
as the usual private sector large provider suspects.

---

From: "Carl S. Gutekunst" <[email-masked]>
Date: Wed, 18 Sep 2013 12:39:31 -0700

> know that with a good degree of certainty, then using TLS won't 
> achieve security, because I could simply be dumping my messages on a 
> compromised server.
>

Which is exactly what's already happening in many countries, e.g., 
Syria. Go ahead and use TLS all you want -- it won't help, because all 
the servers to which you can get IP-level connectivity are government run.

<csg>

---

From: [email-masked]
Date: Thu, 19 Sep 2013 02:42:59 +0200

> the servers to which you can get IP-level connectivity are government run.

But surely this is not the case all over the world.
At least the EU is working for net neutrality.
We could also just refine the problem to making a secure email service
for the EU, if that seems more realistic (tounge in cheek:-).

best regards
keld

---

From: [email-masked]
Date: Thu, 19 Sep 2013 03:01:15 +0200

> security, because I could simply be dumping my messages on a compromised 

Yes, and that could even be done with plain SMTP.
Come on, TLS would be safer than plain unencrypted SMTP.

But you are right, we cannot be sure we are talking to the right server.
Governments have lots of ressources, and even for big countries it is 
feasible to set up fake servers for every SMTP server in the country.

> certificates to a government?

There are friends out there. Eg CAcert. Good certificates are an orthogonal issue.
We can migrate SMTP to TLS, and we can at the same time one by one
get bad certificates replaced with good ones.
We can advise how to get good certificates too.

> interoperability to force TLS usage, because of the dubious benefit.

Agreed, We cannot trust a big part of the internet, and we should not
break the interoperability we have now. But TLS would not do any harm, and it could
improve security in some areas of the world.

best regards
Keld

---

From: [email-masked]
Date: Thu, 19 Sep 2013 03:23:03 +0200

> problem from our point of view.

True. There are many issues in networking security,
and we need to deal with kind of all of them.
The chain is not stronger than the weakest link.
But this is networking security as we have always known it.

> everyone but us (and whomever can subvert us or issue secret

Well, there is a lot to do about these issues.
Some of it would be political.
Some will be customers moving away from contaminated services.
We cannot do it all, but we can take care of our part.

> won't supply it to the government or somehow create a back door?

That is a matter of trust:-)
I would believe in CAcert.
I would believe in self-signed certificates, generated by open source software.

> being right for all cases

I answered Pauls concerns separately. I think the default should be to preserve
current interoperability with enhanced use of TLS, and then with
optional provisions to individually demand an encrypted passage.

Best regards
keld

---

From: Mark Andrews <[email-masked]>
Date: Thu, 19 Sep 2013 11:32:41 +1000

> feasible to set up fake servers for every SMTP server in the country.

Well one could start by looking at the reponse to the HELO/EHLO and
comparing the offered server name to the expected server name.  That
doesn't ever require TLS and is something that you need to fix when
deploying TLS.

Even RFC 821 suggested that one should be checking to ensure that
you are talking to whom you think you should be talking to.

   3.5.  OPENING AND CLOSING

      At the time the transmission channel is opened there is an
      exchange to ensure that the hosts are communicating with the hosts
      they think they are.

Lots of MITM attacks would be prevented by doing just such a check.

DANE can also be used secure TLS against fake CERTs.  Even governments
don't have the ability to fake the entire DNS.  They may be able
to inject false data for the CC they control by getting access to
the private keys for the CC but they don't have the ability for
other CCs.

If your CC doesn't support DNSSEC you need to ask your government
why.

---

From: Paul Smith <[email-masked]>
Date: Thu, 19 Sep 2013 07:42:09 +0100

On 19/09/2013 02:32, Mark Andrews wrote:
> comparing the offered server name to the expected server name.
Not really. It would be trivial to set up SMTP servers which respond 
with different server names (even different capability responses etc) 
depending on the IP address which the connection comes in on.

> don't have the ability to fake the entire DNS.
Really? Given that over half the DNS in the world is probably run on 
servers operated by a handful of companies, I find it difficult to 
believe that a determined government couldn't 'mirror' that with their 
own servers with different data - if it wanted to.

(BTW, I am not usually a conspiracy theorist, but if you are discussing 
finding a way to defend against government snooping, you have to think 
as one).

> They may be able
They could subvert any DNS data crossing their international data links, 
TLD doesn't matter, where the DNS servers are hosted matters.

"All" they have to do is intercept DNS data (relatively easy to detect) 
as it goes through choke points and alter it as they wish. If they have 
the resources to capture all SMTP data passing through choke points, 
they certainly have the resources to modify DNS data at those same places.

(Again, I'm not saying they have done any of this, but for the scenarios 
we're trying to defend against, we have to consider it).

-

---

From: Mark Andrews <[email-masked]>
Date: Thu, 19 Sep 2013 17:12:23 +1000

> depending on the IP address which the connection comes in on.

Which requires large blocks of addresses.

> own servers with different data - if it wanted to.

You not only have to "mirror" the data you have to replace the DS
records and their signatures in the parent zones over which you
have no control.

CA doesn't have control over .US, US doesn't have control over .CA.

> TLD doesn't matter, where the DNS servers are hosted matters.

Actually it does matter as DNSSEC was designed protect the data from
just such attacks.
 
> they certainly have the resources to modify DNS data at those same places.

They have the ability to change the data but not the signatures.  Note
stripping signatures is not effective as the validator knows that there
should be signatures.

---

From: "Rolf E. Sonneveld" <[email-masked]>
Date: Thu, 19 Sep 2013 09:37:18 +0200

>> we're trying to defend against, we have to consider it).

"...scenarios we're trying to defend against..."

This brings us back to what John (Klensin) wrote on Sep 15th:

[...] How useful it is depends tremendously on the threat model. [...]

I have yet to see the threat analysis. IMHO it makes little sense 
discussing all sorts of possible scenario's and solutions without first 
determining what data/information to protect and what the threat is in 
case data/information is disclosed to third parties. In that respect, 
mail from a marketeer to his customer base is different from mail that 
is sent by a whistle-blower.

Likewise, integrity of data, confidentiality of data and authenticity of 
server/client are all different things and each of them need to be 
addressed in:

a) the threat analysis
b) the solution to address these threats

So first things first, let's start with a proper threat analysis.

/rolf

---

From: Paul Smith <[email-masked]>
Date: Thu, 19 Sep 2013 09:34:09 +0100

> Which requires large blocks of addresses.

They have access to the whole IPv4/v6 address ranges.

Just because ARIN or whoever has assigned an IP address to someone 
doesn't mean that anyone with strategically placed routers can't send 
packets to that IP address somewhere else.

If someone has control of routers at an international link, then they 
can trivially send incoming packets meant for any IP address they choose 
to any other host they want.

> Actually it does matter as DNSSEC was designed protect the data from
Only if you can trust the signing authorities and the trust anchors you 
have received about them and can trust that someone else hasn't obtained 
the private keys (which is very difficult to do with complete certainty).

It all comes down to - who can you trust sufficiently?

If you can't absolutely trust anything except yourself, then, if you 
have anything top secret, only use encryption methods which you have 
total control over, or can trust sufficiently.

Registries, CAs, backbone providers, etc, are all 'closed' entities and 
we have no way of knowing that they aren't regularly cooperating with 
various governments. In fact, we have reason to believe that they may be.

My 'conclusion' is that email can't be trusted to be secret, so treat it 
that way, and all's fine. I'm not going to send my plans for world 
domination to my co-conspirators using plain text email (over TLS or 
not); I'll use a one-time key which I've transmitted to my accomplices 
in person, and then I don't care whether it's sent over TLS or not.

Forcing sending regular email over TLS using 'trustable' (for some 
definition) certificates will break email in ways which neither senders 
nor recipients will understand, and is not *guaranteed* to add security. 
By all means, have a BCP document saying 'we recommend mail servers 
support TLS with a CA provided certificate and we recommend mail senders 
use TLS where available as this will reduce the possibility of snooping 
on email en-route', but that's as far as I'd feel happy going.

Even something as 'simple' as making the default of, say, Sendmail being 
to support TLS on the server-side causes issues? Do you refuse to work 
until someone has manually installed a suitable (for some definition) 
certificate? Do you generate a self-signed certificate? (which may make 
people think they're safe when, in fact, a MITM attack would be 
trivial). Or what?

It's more dangerous to make people think they're safer than they are 
than it is to educate them about the risks. Telling them that email 
isn't private is better than claiming to make it private when you can't 
guarantee it.

-

---

From: [email-masked]
Date: Thu, 19 Sep 2013 15:02:01 +0200

> the private keys for the CC but they don't have the ability for

I think further checking of the MTA would be counterproductive.
I run a number of postfix servers, and one way or another 
doing checks on them would invalidate them.
And they do run quite esteemed services.
Fortunately there is very seldomly any problems with them.
One runs on an IP-number where I do not control the reverse lookup name.
Several run services for a number of domains. 

I believe there are already hooks in some MTAs to do further checking,
so people can already do it, if they want (and very few
do that because it will hurt legit email.)

best regards
keld.

---

From: [email-masked]
Date: Thu, 19 Sep 2013 18:33:03 +0200

> So first things first, let's start with a proper threat analysis.

I don't know how to write such an analysis, and it seems like red tape to me.
I am just advocating that we migrate SMTP to TLS, and then I want a plan
that could evolve into an succesful migration, without hurting
interoperablity.

But elements of a risk analysis could be:

Snooping og transmission is becoming more widespread, and thus a greater risk.
Encryption is probably one of the few mechanisms that still provides
some protection against snooping. SMTP has a mechanism for using encryption
in the form of TLS, with the STARTTLS command.

This BCP outlines best practices that can retain good interoperability and then 
provide for a migration to have all SMTP traffic encrypted.

The specification does not alter integrity of datar.s

For confidentiality of sender and receiver, using STARTTLS will encrypt these data,
while MTA to MTA TCP/IP connections will still be visible in the clear.

Autentifications of sender and receiver is not intended to be improved,
although externally signed certificates for the TLS can improve it.
IGiven the sate of trust that can currently be given to some certificate vendors,
self-signed certificates are an integrated part of the best practices, and self-signed
certificates should not be penalized in the recommendations.

I would appreciate if somebody could help enhancing the text, if this is deemed
necessary.

best regards
keld

---

From: "John Levine" <[email-masked]>
Date: 19 Sep 2013 17:35:15 -0000

>that could evolve into an succesful migration, without hurting

OK, just tell people to support STARTTLS in their server MTAs, and to
use it in their clients whenever a server offers it.  All done.

If you don't think that's all done, now you have to tell us why not,
which means you need to have a threat model.

R's,
John

---

From: Sabahattin Gucukoglu <[email-masked]>
Date: Thu, 19 Sep 2013 18:42:05 +0100

> that could evolve into an succesful migration, without hurting

I've already explained in one way how interoperability is guaranteed to be hurt, even if your threat model only includes passive attackers. And I'm really not sure I'm happy about weakening TLS by making verification optional without making it very clear to implementers that their choice to use a CA-signed certificate is completely undermined for the sake of those who don't, regardless of how pointless verification may be.

But look, what *is* your threat model? Who are you up against? What capabilities do they have? Is this about Prism, or something much worse involving active network attackers or server takeover? Without this we really don't know how we can best solve the problem, and even if we did, we'd probably disagree on the means, or the utility, or the interoperability problems.

Cheers,
Sabahattin

---

From: Martijn Grooten <[email-masked]>
Date: Thu, 19 Sep 2013 18:42:43 +0000 (UTC)

> that could evolve into an succesful migration, without hurting

What Rolf was saying is that in this thread we were trying to come up 
with a solution, without first having defined the problem we were trying 
to solve. That is, without having defined a threat model we wanted to 
defend against.

One such threat model could be a third party reading the content of a 
conversation. A defense against such a threat could be the encryption of 
the message content, for instance by using PGP.

Another threat model could be anyone being able to determine the location 
of the sender. A defense against such a threat could be to use an 
anonimity network like Tor to log into a webmail service and use that to 
send email.

So you should first identify a threat model and then we can discuss 
defenses against them. If your threat model is government surveillance, 
then I don't think TLS is a solution.

As many others have tirelessly tried to explain in this thread: if you 
don't want to risk your message being intercepted by third parties, some 
kind of always-use-TLS-pretty-please flag won't offer adequate protection. 
If you can live with this risk, you're unlikely to want to risk losing the 
email.

Martijn.

---

From: [email-masked]
Date: Thu, 19 Sep 2013 22:05:36 +0200

> I've already explained in one way how interoperability is guaranteed to be hurt, even if your threat model only includes passive attackers. And I'm really not sure I'm happy about weakening TLS by…

And I already outlined a way to accomodate your concerns.

You would strengthen SMTP security overall by employing TLS.
I understand that it is only a few SMTP implementations that have the problems
you described. And those implementations are most likely contaminated anyway.
CA-signen certifications are most likely also contaminated, and self-signed certificates
are most likely having more chances of not being contaminated.

> But look, what *is* your threat model? Who are you up against? What capabilities do they have? Is this about Prism, or something much worse involving active network attackers or server takeover? Wi…

What are the requirements for the specs for a threat analysis?
Who made  such a requirement?
Can you provide a link to the requirements?
And a good example of one?

best regards
Keld

---

From: Timo Sirainen <[email-masked]>
Date: Fri, 20 Sep 2013 00:39:48 +0300

On 19.9.2013, at 21.42, Martijn Grooten <[email-masked]> wrote:

> What Rolf was saying is that in this thread we were trying to come up with a solution, without first having defined the problem we were trying to solve. That is, without having defined a threat model we wanted to defend against.

Threat: Defending against casual (non-targeted) network snooping by governments, which is what NSA (and probably others) are doing to everyone.

Solution: TLS, even when it doesn't verify the remote certificate in any way.

Threat 2: Defending against attempted MITM attacks by not-that-powerful governments.

Solution: TLS with DANE, assuming the destination server's trust anchor doesn't belong to that government.

Threat 3: Defending against targeted email nooping by a powerful government.

Solution: Don't use email.

---

From: Sabahattin Gucukoglu <[email-masked]>
Date: Fri, 20 Sep 2013 08:24:54 +0100

> are most likely having more chances of not being contaminated.

So interoperability isn't *that* important.  I'm happy with people choosing that option, as long as they realise that it's a precondition for your scheme.

I also need to point out that you've made many assumptions about implementations and CAs.  Do we really need to go there?  If nothing else, you're proposing nothing less than to undermine the entire CA industry--a sweet thought, to be sure, but not likely to go down too well with said industry. :)

> And a good example of one?

Here's a general description of a threat analysis:
http://www.sans.org/reading_room/whitepapers/auditing/overview-threat-risk-assessment_76

I'm not a security person, but I think the idea is pretty straightforward: figure out what it is we're worried about.

FWIW, I think Prism is what we should be worried about, but it's a baby step in the scheme of things to simply turn on TLS everywhere with self-signed certs.  I'd much rather we pushed DNSSEC+DANE as that's the only thing which will cater to stronger security requirements while also being interoperable with CA certs.  But perhaps you feel differently.

Cheers,
Sabahattin

---

From: [email-masked]
Date: Fri, 20 Sep 2013 11:37:57 +0200

> So interoperability isn't *that* important.  I'm happy with people choosing that option, as long as they realise that it's a precondition for your scheme.

Interoperability is important. I have outlined ways to keep interoperability,
even with bad current implementations of STARTTLS.
Another way to handle bad STARTTLS implementations is to keep track
of bad implementations in a greylisting manner, if TLS did not work,
then don't offer it next time around. For sending MTAs, then just put
it in the queue, for receiving MTAs that depends on the bad MTAs handling 
but at least next time around the mail will get thru. The receiving
MTA could also consult a reltime black list of bad MTAs, to not
offer TLS.

> I also need to point out that you've made many assumptions about implementations and CAs.  Do we really need to go there?  If nothing else, you're proposing nothing less than to undermine the entir…

It was only to do a weighting about priority to paid certificates
vs. self-signed. People can continue to buy their certificates.
Anyway the CA-industry have deliberately decieved their costumers 
by selling them contaminated certificates.

> http://www.sans.org/reading_room/whitepapers/auditing/overview-threat-risk-assessment_76

Thanks for the link. I will have a look. I understand that this is not an IETF requirement.

> FWIW, I think Prism is what we should be worried about, but it's a baby step in the scheme of things to simply turn on TLS everywhere with self-signed certs.  I'd much rather we pushed DNSSEC+DANE…

I am all for better security, but my main aim was to get TLS employed, and that
seems hard enough to get consesnsus on in this group.
My main aim is to maintain interoperability, so if we can employ .
better security without hurting interoperability, that would be fine.
Using DNSSEC could be an option then.

Best regards
keld

---

From: Russ Allbery <[email-masked]>
Date: Fri, 20 Sep 2013 13:22:51 -0700

[email-masked] writes:

> I am all for better security, but my main aim was to get TLS employed,
> and that seems hard enough to get consesnsus on in this group.  My main
> aim is to maintain interoperability, so if we can employ .  better
> security without hurting interoperability, that would be fine.  Using
> DNSSEC could be an option then.

I have a little bit of operational experience with STARTTLS with SMTP
(probably not as much as many people here), since I use opportunistic TLS
on all my own servers and Stanford enforces TLS for mail exchanges with
some sites.  The current state of play with interoperability is not
particularly great in my experience, which will probably not come as a
surprise to people who run large mail environments.  Interoperability for
SMTP in general is kind of a mess; there are a lot of very substandard
implementations out there.

For a very small personal mail server that only does STARTTLS when the
other side explicitly requests it, I see about one error message logged
per day, ranging from clients sending the wrong TLS version number to
weird invalid certificates to various other protocol problems.

It mostly works or can be made to work with large institutions who have an
incentive (such as our policy to require STARTTLS for all email exchanges
with anyone who is a partner of the Stanford Medical Center).  Where that
institutional will is not present, the quality of existing implementations
seems to vary wildly.

This is for transit connections.  The end-user clients in general are much
better at doing STARTTLS, probably because more ISPs have been requiring
TLS for end-user mail submission for much longer.

-- 
Russ Allbery ([email-masked])             <http://www.eyrie.org/~eagle/>

---

From: "Rolf E. Sonneveld" <[email-masked]>
Date: Fri, 20 Sep 2013 22:28:14 +0200

> MTA could also consult a reltime black list of bad MTAs, to not

You keep talking about solutions, without defining the problem.

> by selling them contaminated certificates.

Please provide some references to articles. I know there have been a 
number of CA 'issues' (Diginotar, Turktrust) and we all have our 
thoughts about to what extent CA's have been/are resistant against 
possible requests from governments, but so far I have not seen an 
article describing the fact that CA's have provided contaminated 
certificates. I may have missed that one, between all other revelations 
that followed the Prism scandal.

> I am all for better security, but my main aim was to get TLS employed,

TLS employment is not a goal in itself.

> and that

Don't blame the group if you're just seeking consensus about TLS 
employment without defining what problem this solution will solve.

> Using DNSSEC could be an option then.

And another option: good old typewriters and snail mail... [1]

/rolf

[1] 
http://www.theguardian.com/world/2013/jul/11/russia-reverts-paper-nsa-leaks