ietf-smtp
[Top] [All Lists]

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

2013-09-18 09:12:09
On Sun, Sep 15, 2013 at 04:46:43PM -0400, John C Klensin wrote:


--On Sunday, September 15, 2013 14:41 +0200 keld(_at_)keldix(_dot_)com
wrote:

On Sat, Sep 14, 2013 at 09:37:38PM -0400, John C Klensin wrote:
...
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. 

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.

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.  

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.

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.

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.

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.

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.

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.

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

_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp

<Prev in Thread] Current Thread [Next in Thread>