ietf-smtp
[Top] [All Lists]

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

2013-09-18 20:23:18
On Wed, Sep 18, 2013 at 11:24:52AM -0400, John C Klensin wrote:
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.

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.

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)".

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.

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?

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

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

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