Subject: [Uta] New Draft: draft-friedl-uta-smtp-mta-certs-00

From: "Stephan Friedl (sfriedl)" <[email-masked]>
Date: Thu, 13 Mar 2014 21:33:47 +0000

I have just posted a draft discussing a standard methodology for verifying server identities for TLS secured SMTP MTA to MTA connections.  I believe this draft augments some of the other UTA drafts which target using TLS to improve the security of email networks.

This draft arose from discussions with Tom Kaupe (a coauthor) at Microsoft from improving interoperability of TLS secured MTA connections for delegated email services.

Please review the draft and comments are very much welcome.

Thanks,

Stephan

---

From: Chris Newman <[email-masked]>
Date: Fri, 14 Mar 2014 17:46:43 -0700

--On March 13, 2014 21:33:47 +0000 "Stephan Friedl (sfriedl)"
<[email-masked]> wrote:
> I have just posted a draft discussing a standard methodology for verifying
> server identities for TLS secured SMTP MTA to MTA connections.  I believe
> this draft augments some of the other UTA drafts which target using TLS to
> improve the security of email networks.
> 
> This draft arose from discussions with Tom Kaupe (a coauthor) at Microsoft
> from improving interoperability of TLS secured MTA connections for delegated
> email services.
> 

If you allow use of a post-MX-lookup identity (4.1.4.1 option 3), then the
protocol is subject to a man-in-the-middle attack. The purpose of certificate
authentication for SMTP would be to prevent a man-in-the-middle attack. So this
appears to be a complex proposal that I believe accomplishes nothing useful.
Can you argue why it is useful?

Now the post-MX lookup hostname may be fine if DNSSEC is used, but if we assume
DNSSEC is required then we have a more mature proposal:
  http://tools.ietf.org/html/draft-ietf-dane-smtp-with-dane-07

If you're writing a proposal that doesn't care about man-in-the-middle attacks,
then why not just write a spec advising MTAs to have a configuration that
ignores the server certificate but uses TLS encryption? That will be a lot
easier to deploy and protects against passive attacks including bulk passive
attacks.

		- Chris

---

From: "Stephan Friedl (sfriedl)" <[email-masked]>
Date: Mon, 17 Mar 2014 21:32:19 +0000

Chris,

The goal of this draft is to provide a specification for the process whereby MTA server identities are verified using the certificate materials supplied during a TLS handshake.  It does not propose techniques to close the MITM hole that has always existed when MX lookups are used to determine a remote email server and we call this out in the security considerations section of the draft.  As you point out, the DANE based proposal is targeted at closing those holes.

Fundamentally, this draft seeks to address an interoperability issue which has recently been exacerbated by the increasing popularity of delegated email services.  We would like to provide the same specificity for the identity verification process to SMTP MTA to MTA connections that RFC 6215 provides for a variety of other use cases.  Without this standard methodology in place, different MTAs may behave quite differently for email transmission based simply on idiosyncratic approaches to identity verification in an environment without pervasive DNSSEC.  Beyond that, this draft also seeks to document the appropriate use of wildcards for delegated email services. 

 I believe the draft is useful in that it ties up some loose ends with existing MTA TLS connectivity issues.  The complexity is pretty much the nature of the problem, you get the permutations when the differences between self-hosted and delegated email models are considered together.

Thanks,

Stephan

> -----Original Message-----
> From: Chris Newman [mailto:[email-masked]]
> Sent: Friday, March 14, 2014 6:47 PM
> To: Stephan Friedl (sfriedl); [email-masked]
> Subject: Re: [Uta] New Draft: draft-friedl-uta-smtp-mta-certs-00
> 
> > I have just posted a draft discussing a standard methodology for
> > verifying server identities for TLS secured SMTP MTA to MTA
> > connections.  I believe this draft augments some of the other UTA
> > drafts which target using TLS to improve the security of email networks.
> >
> > This draft arose from discussions with Tom Kaupe (a coauthor) at
> > Microsoft from improving interoperability of TLS secured MTA
> > connections for delegated email services.
> >
> authentication for SMTP would be to prevent a man-in-the-middle attack. So
> this appears to be a complex proposal that I believe accomplishes nothing
> useful.
> Now the post-MX lookup hostname may be fine if DNSSEC is used, but if we
> assume DNSSEC is required then we have a more mature proposal:
> If you're writing a proposal that doesn't care about man-in-the-middle
> attacks, then why not just write a spec advising MTAs to have a configuration
> that ignores the server certificate but uses TLS encryption? That will be a lot