ietf-smtp
[Top] [All Lists]

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

2013-09-16 04:21:52
On 14/09/2013 03:37, Timo Sirainen wrote:
I've been considering an SMTP client extension (especially for submission clients) where they can require that the mail be delivered via TLS, and have the server reject/bounce it if that's not possible. The main problem I see is relay servers that can accept the mail via TLS and then happily forward the mail over plaintext connection to the other side of the world..
You could have an extension which passes on the 'must use TLS extension' flag with the message (similar to the DSN extension).

You would have to treat the onward mail server as not supporting TLS if it doesn't support your extension, because, as you say, that server may well send the message over a plaintext connection if it has to, without letting you know.

However, a big problem would be what to do if you can't send mail using TLS. Most recipients won't know that their mail server doesn't support TLS, or that a mandatory upstream mail server doesn't support TLS.

Also, I'm not really sure that this would achieve much, depending on what you think the threat signature is.

For instance, theoretically a government could compromise servers belonging to big providers or implement MITM attacks (eg by faking DNS data sent across international links) to intercept messages. These would "bypass" any TLS encryption, and not be that hard to do if they have compromised international links.

End-to-end encryption (eg PGP) would help here, or (possibly) a centralised mail system held in a 'safe' location (if such a thing exists).

How secure do you want to be?

TBH, I don't care except on a philosophical level. I never send anything private by email (I've always understood that an email is as secure as a postcard). If I was to want to send something so private I didn't want a government to know, I wouldn't rely on TLS.

If a government wants to spy on my messages about DIRTY spam BOMBs on people in families which may or may not be NUCLEAR, then that's up to them, I really don't care.



-

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