Re: [OT] SMTP bad
On 12/06/13 21:35, Jeremy Stanley wrote:
> On 2013-06-12 08:08:17 +0200 (+0200), Daniel Pocock wrote:
>> On 12/06/13 00:02, Jeremy Stanley wrote:
>>> That basically just makes the case for relying on (E)SMTP only for
>>> transporting messages, but leveraging OpenPGP or S/MIME to provide
>>> authentication and confidentiality where required (or for anonymity,
>>> Mixmaster et al).
>> OpenPGP and S/MIME don't guarantee anonymity as they don't (and can't
>> really) encrypt the headers/envelope
> [...]
>
> Apologies if that message made it past the sarcasm filter, but I was
> being flippant. As for anonymity, that's why I mentioned a type II
> remailer... you can use Mixmaster without nyms as long as you don't
> care about the recipient being able to respond to you. And if you
> do, well that's pseudonymity not anonymity. (Though I really think
> you meant "confidentiality" when you wrote "anonymity" there?)
Both confidentiality and anonymity are desirable options to have, but I
definitely used the word anonymity in error there. Confidentiality is
the more important feature to offer and is probably easier to achieve.
> The situation with SMTP is not so dire as you paint it, you simply
> need to implement your own cryptography on top of it and be aware of
> the characteristics it provides (for example put your real subject
> in the message body if using OpenPGP, onion-routing/remailers if you
> don't want an eavesdropper to know who you're talking to, et
While this is good for the attentive user, my own feeling is that it
needs to "just work" by default even for those users who don't
understand the details. Useability is really fundamental.
> cetera). Hop-by-hop opportunistic encryption on the "honor system"
> does little more than give a false sense of security, but mailadmins
> hopefully already know this long before they contemplate twisting
> the shiny STARTTLS knob for remote deliveries?
>
> In short, encrypted SMTP is there to protect your login credentials
> when connecting directly to a known smarthost, and if you're doing
> it right you're using proper certificate validation (at least TOFU
I agree that it is very effective and works well in this scenario. All
my own devices use this mode exclusively.
> anyway). Any use beyond that is either misguided fantasy or a sales
> pitch for the PKI (CA/TTP) cartels. As long as you accept the nature
> of SMTP and use it in the ways it's intended, it's a perfectly fine
> protocol which has withstood several decades of pounding while its
> detractors have never managed to successfully replace it with
> something better.
Not quite - there is now some overlap between the certificate
requirements for SMTP, XMPP and SIP. E.g. an appropriate subjectAltName
(SAN) certificate can be shared between all those types of server and
used to implement mutual TLS authentication.
The difference is, SMTP is already widely deployed and there is a
massive focus on backwards compatibility, while XMPP and SIP federation
are generally based on the latest server technology and if they all
agree on a common way of using TLS, it can work quite well.
Reply to: