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

Chris Lamont Mankowski makerofthings77 at gmail.com
Tue Jun 19 07:28:26 PDT 2012

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.  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)
concept could allow for an authorized SMTP sender to publish its public
keys into DNS, while removing any dependency (or
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

***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/92584664/attachment-0001.htm>

More information about the dmarc-discuss mailing list