ietf-smtp
[Top] [All Lists]

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

2013-09-18 10:25:18
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
<paul(_at_)pscs(_dot_)co(_dot_)uk> wrote:

On 18/09/2013 15:11, keld(_at_)keldix(_dot_)com 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)".
 
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?

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.
_______________________________________________
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>