ietf-smtp
[Top] [All Lists]

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

2013-09-19 02:46:14
On 09/19/2013 09:12 AM, Mark Andrews wrote:
In message <523A9CC1(_dot_)3080302(_at_)pscs(_dot_)co(_dot_)uk>, Paul Smith 
writes:
On 19/09/2013 02:32, Mark Andrews wrote:
Well one could start by looking at the reponse to the HELO/EHLO and
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.
Which requires large blocks of addresses.

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

(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
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.
They could subvert any DNS data crossing their international data links,
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.
"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.
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.
(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).

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