On Sat, Sep 14, 2013 at 09:37:38PM -0400, John C Klensin wrote:
--On Saturday, September 14, 2013 17:02 +0200 keld(_at_)keldix(_dot_)com
wrote:
...
I am thinking of an advice to application developers to always
have TLS on by default, and to 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 time 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.
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
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.
best regards
keld
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp