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

MH Michael Hammer (5304) MHammer at ag.com
Tue Jun 19 08:15:07 PDT 2012

Even though DMARC is open for extension and SSL/TLS was discussed and
considered, there was a consensus that focusing on SPF and DKIM
initially makes sense as they are fairly well understood (for DMARC
purposes) and widely used. Adding additional authentication methods into
the mix adds complexity that may not be useful at this stage of


From: dmarc-discuss-bounces at blackops.org
[mailto:dmarc-discuss-bounces at blackops.org] On Behalf Of Franck Martin
Sent: Tuesday, June 19, 2012 11:01 AM
To: Chris Lamont Mankowski; dmarc-discuss at dmarc.org
Subject: Re: [dmarc-discuss] Is DMARC the right place for SMTP-TLS
policy and reporting?


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.  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%20> 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


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/29b011c1/attachment-0001.htm>

More information about the dmarc-discuss mailing list