<div style>Does it make sense for DMARC policy to define policy and feedback reporting of TLS?  </div><div style><br></div><div style><font color="#222222" face="arial, sans-serif">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 <a href="http://et.al">et.al</a>.  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. </font></div>
<div style><font color="#222222" face="arial, sans-serif"><br></font></div><div style><font color="#222222" face="arial, sans-serif">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.</font></div>
<div style><font color="#222222" face="arial, sans-serif"><br></font></div><div style><font color="#222222" face="arial, sans-serif">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.</font></div>
<div style><font color="#222222" face="arial, sans-serif"><br></font></div><div style><span style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:13px">Keeping in the spirit of DMARC, no PKI is needed if the TLS implementation <a href="http://tools.ietf.org/html/draft-ietf-dane-protocol-23 ">published certificates in DNS (TLSA formerly DANE) </a></span><span style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:13px">This concept could allow for an authorized SMTP sender to publish its public keys into DNS, while removing any dependency (</span><a href="http://security.stackexchange.com/q/2268/396" target="_blank" style="font-family:arial,sans-serif;font-size:13px;color:rgb(17,85,204)">or vulnerability</a><span style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:13px">) on the PKI hierarchy.  </span></div>
<div style><br></div><div style><font color="#222222" face="arial, sans-serif">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,</font><a href="http://security.stackexchange.com/q/6824/396" target="_blank" style="font-family:arial,sans-serif;font-size:13px;color:rgb(17,85,204)"> here is information on why DNSSec is required </a><font color="#222222" face="arial, sans-serif"> and additional information on</font><a href="http://security.stackexchange.com/q/6827/396" target="_blank" style="font-family:arial,sans-serif;font-size:13px;color:rgb(17,85,204)"> how easy it is to spoof DNS</a><font color="#222222" face="arial, sans-serif"> . </font></div>
<div style><br></div><div style><b>**Small gripe to MUA implementors w.r.t DMARC**</b></div><div style><br></div><div style>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.  </div>
<div style><br></div><div style>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.</div>
<div style><br></div><div style>Bottom line, I'd support a MUA indicator if DMARC policy also reflected encryption requirements.</div><div style><br></div><div style><b>**Questions**</b></div><div style>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?</div>
<div style><br></div><div style>Is there any specific initiative, RFC, or the like that gets MTAs to incorporate TLS with TLSA-based verification? (aka DANE)</div><div style><br></div><div style>Thanks for your consideration,</div>
<div style><br></div><div style>Chris Lamont Mankowski</div>