Re: [ietf-smtp] Two recent Internet-Drafts about using TLS with email protocols

[Wei Chuang <[e-mail]>]

On Wed, Oct 23, 2013 at 10:48 AM, Keith Moore <[e-mail]>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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ietf-smtp
>
>