On 09/19/2013 09:12 AM, Mark Andrews wrote:
In message <523A9CC1(_dot_)3080302(_at_)pscs(_dot_)co(_dot_)uk>, Paul Smith
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
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
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
a) the threat analysis
b) the solution to address these threats
So first things first, let's start with a proper threat analysis.
ietf-smtp mailing list