On 19/09/2013 08:12, 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.
They have access to the whole IPv4/v6 address ranges.
Just because ARIN or whoever has assigned an IP address to someone
doesn't mean that anyone with strategically placed routers can't send
packets to that IP address somewhere else.
If someone has control of routers at an international link, then they
can trivially send incoming packets meant for any IP address they choose
to any other host they want.
(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.
Only if you can trust the signing authorities and the trust anchors you
have received about them and can trust that someone else hasn't obtained
the private keys (which is very difficult to do with complete certainty).
It all comes down to - who can you trust sufficiently?
If you can't absolutely trust anything except yourself, then, if you
have anything top secret, only use encryption methods which you have
total control over, or can trust sufficiently.
Registries, CAs, backbone providers, etc, are all 'closed' entities and
we have no way of knowing that they aren't regularly cooperating with
various governments. In fact, we have reason to believe that they may be.
My 'conclusion' is that email can't be trusted to be secret, so treat it
that way, and all's fine. I'm not going to send my plans for world
domination to my co-conspirators using plain text email (over TLS or
not); I'll use a one-time key which I've transmitted to my accomplices
in person, and then I don't care whether it's sent over TLS or not.
Forcing sending regular email over TLS using 'trustable' (for some
definition) certificates will break email in ways which neither senders
nor recipients will understand, and is not *guaranteed* to add security.
By all means, have a BCP document saying 'we recommend mail servers
support TLS with a CA provided certificate and we recommend mail senders
use TLS where available as this will reduce the possibility of snooping
on email en-route', but that's as far as I'd feel happy going.
Even something as 'simple' as making the default of, say, Sendmail being
to support TLS on the server-side causes issues? Do you refuse to work
until someone has manually installed a suitable (for some definition)
certificate? Do you generate a self-signed certificate? (which may make
people think they're safe when, in fact, a MITM attack would be
trivial). Or what?
It's more dangerous to make people think they're safer than they are
than it is to educate them about the risks. Telling them that email
isn't private is better than claiming to make it private when you can't
guarantee it.
-
Paul Smith Computer Services
Tel: 01484 855800
Vat No: GB 685 6987 53
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp