[dmarc-discuss] Is DMARC the right place for SMTP-TLS policy and reporting?

Franck Martin fmartin at linkedin.com
Tue Jun 19 08:01:04 PDT 2012

DMARC is open for extension.

However in your scenario a mobile workforce will have still issues, because a lot of people do not allow connection to their MTA from dynamic IP ranges, or IPs known to be ISP customer allocated IPs.

Their only chance to submit email, is via their own MTA on submission port with authentication.

Also, you will completely loose track of what emails your mobile workforce is sending.

DMARC has this advantage, it obliges any employee to use your infrastructure to send emails with your domain name on it.
From: dmarc-discuss-bounces at blackops.org [dmarc-discuss-bounces at blackops.org] on behalf of Chris Lamont Mankowski [makerofthings77 at gmail.com]
Sent: Tuesday, June 19, 2012 7:28 AM
To: dmarc-discuss at dmarc.org
Subject: [dmarc-discuss] Is DMARC the right place for SMTP-TLS policy and reporting?

Does it make sense for DMARC policy to define policy and feedback reporting of TLS?

As you probably know, in traditional STARTTLS communication the receiving MTA has the option to validate the certificate.  This validation can vary from no validation, to a a subject name match, to a fully trusted certificate that is vetted by Verisign et.al<http://et.al>.  It is the responsibility of the receiver to make sure this validation is done correctly, and this is usually implemented with an out of band communication with the sender, or unilaterally and performing a "scream test" and awaiting user feedback that mailflow isn't working.

I think that If DMARC is a place to specify the authorized sending IPs (via SPF), I believe a natural alternative to SPF is verification using a trusted TLS private key.

DKIM allows an interesting scenario where each user has an individual signing key.  In that case, a mobile workforce doesn't have to go through a central MTA in order to send valid email.  SPF on the other hand requires a closed set of MTAs (for better or worse).  What if a deployment of secure SMTP gave each user a private key (or a single shared private key) that aligned the Subject or SAN name to a DNS domain name?  This could further the goal of validating the RFC5322.From address to an authorized sender.  If it were possible to enforce validated TLS senders, we could substitute SPF authentication for a verified TLS connection.

Keeping in the spirit of DMARC, no PKI is needed if the TLS implementation published certificates in DNS (TLSA formerly DANE) <http://tools.ietf.org/html/draft-ietf-dane-protocol-23> This concept could allow for an authorized SMTP sender to publish its public keys into DNS, while removing any dependency (or vulnerability<http://security.stackexchange.com/q/2268/396>) on the PKI hierarchy.

In order for these TLS connections to be secure, the corresponding DMARC-TLS policy should define if DNSSec should not only be used for the certificate, but also the validating CRL and OCSP links.  I can see how one could think cipher and encryption levels would be out of scope for DMARC's goal of message authentication, but if you consider that a certificate could be used in situations to replace SPF, then we definitely should specify the minimum crypto allowed (we don't want MD5 for example) For those who are interested, here is information on why DNSSec is required <http://security.stackexchange.com/q/6824/396>  and additional information on how easy it is to spoof DNS<http://security.stackexchange.com/q/6827/396> .

**Small gripe to MUA implementors w.r.t DMARC**

I've seen a few posts that talk about MUAs displaying DMARC-verified messages with a golden key illustrating it's sent secure.  I understand that MUAs are out of scope for the DMARC spec, but I want to mention that feature will be confusing to my end users and customers as it stands today.  I'm in the financial vertical and work with HIPPA data and other material relevant to advisory services,benefits, life insurance.  As a result we are required to encrypt all data in transport.

In fact, I've worked with representatives from DMARC's sponsors (Bank of America, and Fidelity among others) to set up Enforced TLS between our companies (NFP).  The reason for this was to increase security in lieu of a portal-based-encryption such as Voltage or Zixmail.  Many of our end users and customers noticed how the contents of the message changed and they aren't requiring a login to a separate website for PII data.  They thought TLS made the contents insecure in transit, when this isn't the case.

Bottom line, I'd support a MUA indicator if DMARC policy also reflected encryption requirements.

So what are your thoughts?  Should DMARC also incorporate TLS encryption policy and reporting? Or simply create a placeholder for it?  Should something else be created such as DMARC-TLS?

Is there any specific initiative, RFC, or the like that gets MTAs to incorporate TLS with TLSA-based verification? (aka DANE)

Thanks for your consideration,

Chris Lamont Mankowski
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://medusa.blackops.org/pipermail/dmarc-discuss/attachments/20120619/c667fe20/attachment.htm>

More information about the dmarc-discuss mailing list