On Wed, Oct 23, 2013 at 10:48 AM, Keith Moore
<moore(_at_)network-heretics(_dot_)com>wrote:
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.
I just wanted to note that the draft-wchuang-msmd-00 recommends that
additional CA verification be done through Certificate Transparency
[RFC6962]. We didn't put a stronger requirement since some deployment
details are not specified (according to one of the authors), and our
understanding is that the community hasn't registered a strong preference
to either DANE TLSA or Certificate Transparency (or some other scheme).
Certificate Transparency doesn't directly depend on DNSSEC which is only
slowly being deployed, and instead builds upon the existing X.509 CA
infrastructure. It provides means for 3rd parties to observe the signing of
certificate, and quickly verify if a particular CA is doing the right
thing. To stir the pot up, I just want to point out this comparison of the
alternatives:
http://www.certificate-transparency.org/comparison
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.
+1 (While I'm one of the authors of a TLS based approach, I'd also like to
see more discussion/ideas of privacy protecting end-to-end approaches)
-Wei
Keith
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp