On Oct 22, 2013, at 10:42 AM, Martijn Grooten
So after my initial excitement about the idea of using something DKIM-like to
ensure organisation-to-organisation encryption for SMTP, I've started to have
I basically have two concerns.
Firstly, while I understand the important difference between guaranteeing
encryption of the connection to the next hop (as STARTTLS does) and
guaranteeing encryption of the full transit to the recipient's mail server
(as this proposal aims to do), in practice how often do these two differ?
If the encryption is done in the MUA this protects the content at the MUAs
Of course, in the common case the entity that controls the smarthost also
controls the DNS recursive resolver...
The only widely used example I can think of are organisations using hosted
email (for filtering spam etc.) - but not decrypting the emails at the
cloud-based host would defeat the whole point of using hosted email.
Secondly, I don't think the proposal includes a way to authenticate the
receiving server. I think this is important to defend against active
man-in-the-middle attacks by attackers who are able to modify DNS responses
(as happened in the case of some prominent security firms recently - though
web rather than email was the attackers' main target). In this proposal as I
understand it, as in DKIM itself, DNS is a single point of failure. I know
authentication requires the use of certificates, which adds complications and
introduces a likely cost and that sometime DKIM-like is therefore a lot
easier to implement. But is this compromise worth it?
DNSSEC is probably the answer to that (which doesn't mean that doing something
additional wouldn't be a decent idea, if there's any low hanging fruit there).
ietf-smtp mailing list