On Tue, 22 Oct 2013, Steve Atkins wrote:
If the encryption is done in the MUA this protects the content at the
MUAs smarthost.
Of course, in the common case the entity that controls the smarthost
also controls the DNS recursive resolver...
Yes. If your threat model includes the possibility that attackers have
taken control of the smarthost, you have bigger things to worry about (and
you should use Tor and/or a VPN rather than a scheme like this).
I can see that by doing the encryption in the MUA, you get the same kind
of control that the original proposal (by Wei Chuang et al) wanted to give
you. And it would mean that you (or your MUA) can make sure the message is
encrypted during transit. But for this to be useful, it would have to be
implemented as the default setting in MUAs. I'm not convinced (anymore)
that it would be easier to make MUAs and (receiving) MTAs adopt a
yet to be written protocol than it would be for sending and receiving MTAs
to adopt an existing protocol. Even if the existing protocol isn't trivial
to implement.
I have to admit that I would't know the reason why MTA are using STARTTLS.
If there are fundamental reasons for not using it, reasons that don't
apply to this protocol, then I think it is a rather nice way of getting
more or less the same security with relatively little effort. If these
reasons are that, well, it is a little bit difficult and no one seems to
care anyway, then I wonder if this new protocol is where we should focus
our efforts.
Martijn.
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp