I'd like to call the list's attention to two other Internet-Drafts
regarding use of TLS with email protocols:
1. draft-ietf-dane-smtp-with-dane-00
<http://datatracker.ietf.org/doc/draft-ietf-dane-smtp-with-dane/>
This is (mostly) about SMTP mail relaying using Opportunistic TLS, and
how to make it work well by using TLSA records to both (a) provide a
secure indication that the SMTP server supports STARTTLS (thus thwarting
MITM downgrading attacks) and (b) provide a way to verify that the SMTP
server is the right server (given a chain of DNSSEC-signed
MX/CNAME/A/AAAA etc. records) without requiring the server to present a
TLS certificate for every possible DNS name for which that server is
authorized to accept mail.
The document seems to be fairly well written and worked out in a decent
amount of detail. It proposes Opportunistic TLS rather than an SMTP
extension or message header that would require secure delivery for the
entire path. For mail relaying I think Opportunistic TLS is a more
realizable goal. But even if people want to propose an SMTP extension
to mandate use of TLS for the remainder of the path to the recipient, I
think it would need to use the certificate verification mechanisms
described in this draft.
2. draft-moore-email-tls-00
<http://datatracker.ietf.org/doc/draft-moore-email-tls/>
This is a document recommending use of TLS in all interactions between
MUAs and mail servers (IMAP, POP, Submission). It basically has two
sets of recommendations - one for client and server implementations, and
another for mail service providers - because there are operational as
well as implementation concerns.
This started out to be a document recommending TLS for both MUA-MSP
interactions and for mail relaying, but it turned out that the two cases
are different enough that trying to specify both in the same document
made it too large and complex. When I discovered that
draft-ietf-dane-smtp-with-dane-00 existed and used the same approach I
was recommending, and also that the dane-smtp draft had things worked
out in more detail, I removed the portions from my draft that related to
SMTP relaying.
To me it seems that a comprehensive approach to encrypting email traffic
actually needs to cover three separate cases: (1) mail relaying, (2)
MUA-MSP interactions, and (3) end-to-end encryption. Cases (1) and (2)
are similar in goal - protect emails being transmitted over the network
from eavesdroppers and active attacks - but subtly different in
implementation. Case (3) protects emails from being disclosed to
servers which are operated by third parties and which might be
compromised. None of these is sufficient by itself, because (1) and
(2) by themselves don't protect the messages while they're stored on
third-party servers, and (3) doesn't protect against traffic analysis -
which when dealing with mass surveillance seems to be as important as
protecting the actual contents of the messages.
Of these, the most difficult problem seems to be (3). Solutions for
(3) e.g. PGP and S/MIME have been around for a long time, but they
haven't been widely deployed. This seems like an area that is worth
revisiting.
Keith
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp