<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"><head><meta http-equiv=Content-Type content="text/html; charset=us-ascii"><meta name=Generator content="Microsoft Word 12 (filtered medium)"><!--[if !mso]><style>v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style><![endif]--><style><!--
/* Font Definitions */
@font-face
        {font-family:"Cambria Math";
        panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
        {font-family:Calibri;
        panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
        {font-family:Tahoma;
        panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
        {margin:0in;
        margin-bottom:.0001pt;
        font-size:12.0pt;
        font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
        {mso-style-priority:99;
        color:blue;
        text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
        {mso-style-priority:99;
        color:purple;
        text-decoration:underline;}
p.MsoAcetate, li.MsoAcetate, div.MsoAcetate
        {mso-style-priority:99;
        mso-style-link:"Balloon Text Char";
        margin:0in;
        margin-bottom:.0001pt;
        font-size:8.0pt;
        font-family:"Tahoma","sans-serif";}
span.BalloonTextChar
        {mso-style-name:"Balloon Text Char";
        mso-style-priority:99;
        mso-style-link:"Balloon Text";
        font-family:"Tahoma","sans-serif";}
span.EmailStyle19
        {mso-style-type:personal;
        font-family:"Calibri","sans-serif";
        color:#1F497D;}
span.EmailStyle20
        {mso-style-type:personal-reply;
        font-family:"Calibri","sans-serif";
        color:#1F497D;}
.MsoChpDefault
        {mso-style-type:export-only;
        font-size:10.0pt;}
@page WordSection1
        {size:8.5in 11.0in;
        margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
        {page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="2050" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]--></head><body lang=EN-US link=blue vlink=purple><div class=WordSection1><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>If and when DMARC wants to further explore this idea, and perhaps develop a prototype of some sort, Symantec would like to participate.  For those that may not be aware, Symantec acquired VeriSign’s SSL business in 2010, and between our VeriSign, GeoTrust, Thawte, and RapidSSL product brands, we have ~65% of the global SSL business and have the resources to commit to working with DMARC on this.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Thanks…<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Geoff<o:p></o:p></span></p><div><p class=MsoNormal><span lang=EN-IE style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Geoffrey W. Noakes<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-IE style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Director, Business Development<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-IE style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Symantec Corporation<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-IE style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><a href="mailto:Geoffrey_noakes@symantec.com"><span style='color:blue'>geoffrey_noakes@symantec.com</span></a><o:p></o:p></span></p><p class=MsoNormal><span lang=EN-IE style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>+1-415-370-5980<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-IE style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p></div><p class=MsoNormal><a href="http://www.symantec.com/theme.jsp?themeid=seal-transition"><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D;text-decoration:none'><img border=0 width=288 height=175 id="Picture_x0020_1" src="cid:image001.png@01CD4DFB.F3573080" alt="VeriSign_trust_seals_production"></span></a><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><div><div style='border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in'><p class=MsoNormal><b><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From:</span></b><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'> dmarc-discuss-bounces@blackops.org [mailto:dmarc-discuss-bounces@blackops.org] <b>On Behalf Of </b>MH Michael Hammer (5304)<br><b>Sent:</b> Tuesday, June 19, 2012 8:15 AM<br><b>To:</b> Franck Martin; Chris Lamont Mankowski; dmarc-discuss@dmarc.org<br><b>Subject:</b> Re: [dmarc-discuss] Is DMARC the right place for SMTP-TLS policy and reporting?<o:p></o:p></span></p></div></div><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>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 development/deployment. <o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><div style='border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in 4.0pt'><div><div style='border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in'><p class=MsoNormal><b><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From:</span></b><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'> dmarc-discuss-bounces@blackops.org [mailto:dmarc-discuss-bounces@blackops.org] <b>On Behalf Of </b>Franck Martin<br><b>Sent:</b> Tuesday, June 19, 2012 11:01 AM<br><b>To:</b> Chris Lamont Mankowski; dmarc-discuss@dmarc.org<br><b>Subject:</b> Re: [dmarc-discuss] Is DMARC the right place for SMTP-TLS policy and reporting?<o:p></o:p></span></p></div></div><p class=MsoNormal><o:p> </o:p></p><div><p class=MsoNormal><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif";color:black'>DMARC is open for extension. <o:p></o:p></span></p><div><p class=MsoNormal><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif";color:black'><o:p> </o:p></span></p></div><div><p class=MsoNormal><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif";color:black'>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.<o:p></o:p></span></p></div><div><p class=MsoNormal><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif";color:black'><o:p> </o:p></span></p></div><div><p class=MsoNormal><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif";color:black'>Their only chance to submit email, is via their own MTA on submission port with authentication.<o:p></o:p></span></p></div><div><p class=MsoNormal><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif";color:black'><o:p> </o:p></span></p></div><div><p class=MsoNormal><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif";color:black'>Also, you will completely loose track of what emails your mobile workforce is sending.<o:p></o:p></span></p></div><div><p class=MsoNormal><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif";color:black'><o:p> </o:p></span></p></div><div><p class=MsoNormal><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif";color:black'>DMARC has this advantage, it obliges any employee to use your infrastructure to send emails with your domain name on it.<o:p></o:p></span></p><div><div class=MsoNormal align=center style='text-align:center'><span style='color:black'><hr size=2 width="100%" align=center></span></div><div id=divRpF612879><p class=MsoNormal style='margin-bottom:12.0pt'><b><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif";color:black'>From:</span></b><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif";color:black'> <a href="mailto:dmarc-discuss-bounces@blackops.org">dmarc-discuss-bounces@blackops.org</a> [dmarc-discuss-bounces@blackops.org] on behalf of Chris Lamont Mankowski [makerofthings77@gmail.com]<br><b>Sent:</b> Tuesday, June 19, 2012 7:28 AM<br><b>To:</b> <a href="mailto:dmarc-discuss@dmarc.org">dmarc-discuss@dmarc.org</a><br><b>Subject:</b> [dmarc-discuss] Is DMARC the right place for SMTP-TLS policy and reporting?</span><span style='color:black'><o:p></o:p></span></p></div><div><div><p class=MsoNormal><span style='color:black'>Does it make sense for DMARC policy to define policy and feedback reporting of TLS?  <o:p></o:p></span></p></div><div><p class=MsoNormal><span style='color:black'><o:p> </o:p></span></p></div><div><p class=MsoNormal><span style='font-family:"Arial","sans-serif";color:#222222'>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" target="_blank">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. </span><span style='color:black'><o:p></o:p></span></p></div><div><p class=MsoNormal><span style='color:black'><o:p> </o:p></span></p></div><div><p class=MsoNormal><span style='font-family:"Arial","sans-serif";color:#222222'>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.</span><span style='color:black'><o:p></o:p></span></p></div><div><p class=MsoNormal><span style='color:black'><o:p> </o:p></span></p></div><div><p class=MsoNormal><span style='font-family:"Arial","sans-serif";color:#222222'>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.</span><span style='color:black'><o:p></o:p></span></p></div><div><p class=MsoNormal><span style='color:black'><o:p> </o:p></span></p></div><div><p class=MsoNormal><span style='font-size:10.0pt;font-family:"Arial","sans-serif";color:#222222'>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%20" target="_blank">published certificates in DNS (TLSA formerly DANE) </a>This concept could allow for an authorized SMTP sender to publish its public keys into DNS, while removing any dependency (</span><span style='color:black'><a href="http://security.stackexchange.com/q/2268/396" target="_blank"><span style='font-size:10.0pt;font-family:"Arial","sans-serif";color:#1155CC'>or vulnerability</span></a></span><span style='font-size:10.0pt;font-family:"Arial","sans-serif";color:#222222'>) on the PKI hierarchy.  </span><span style='color:black'><o:p></o:p></span></p></div><div><p class=MsoNormal><span style='color:black'><o:p> </o:p></span></p></div><div><p class=MsoNormal><span style='font-family:"Arial","sans-serif";color:#222222'>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,</span><span style='color:black'><a href="http://security.stackexchange.com/q/6824/396" target="_blank"><span style='font-size:10.0pt;font-family:"Arial","sans-serif";color:#1155CC'> here is information on why DNSSec is required </span></a></span><span style='font-family:"Arial","sans-serif";color:#222222'> and additional information on</span><span style='color:black'><a href="http://security.stackexchange.com/q/6827/396" target="_blank"><span style='font-size:10.0pt;font-family:"Arial","sans-serif";color:#1155CC'> how easy it is to spoof DNS</span></a></span><span style='font-family:"Arial","sans-serif";color:#222222'> . </span><span style='color:black'><o:p></o:p></span></p></div><div><p class=MsoNormal><span style='color:black'><o:p> </o:p></span></p></div><div><p class=MsoNormal><b><span style='color:black'>**Small gripe to MUA implementors w.r.t DMARC**</span></b><span style='color:black'><o:p></o:p></span></p></div><div><p class=MsoNormal><span style='color:black'><o:p> </o:p></span></p></div><div><p class=MsoNormal><span style='color:black'>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.  <o:p></o:p></span></p></div><div><p class=MsoNormal><span style='color:black'><o:p> </o:p></span></p></div><div><p class=MsoNormal><span style='color:black'>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.<o:p></o:p></span></p></div><div><p class=MsoNormal><span style='color:black'><o:p> </o:p></span></p></div><div><p class=MsoNormal><span style='color:black'>Bottom line, I'd support a MUA indicator if DMARC policy also reflected encryption requirements.<o:p></o:p></span></p></div><div><p class=MsoNormal><span style='color:black'><o:p> </o:p></span></p></div><div><p class=MsoNormal><b><span style='color:black'>**Questions**</span></b><span style='color:black'><o:p></o:p></span></p></div><div><p class=MsoNormal><span style='color:black'>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?<o:p></o:p></span></p></div><div><p class=MsoNormal><span style='color:black'><o:p> </o:p></span></p></div><div><p class=MsoNormal><span style='color:black'>Is there any specific initiative, RFC, or the like that gets MTAs to incorporate TLS with TLSA-based verification? (aka DANE)<o:p></o:p></span></p></div><div><p class=MsoNormal><span style='color:black'><o:p> </o:p></span></p></div><div><p class=MsoNormal><span style='color:black'>Thanks for your consideration,<o:p></o:p></span></p></div><div><p class=MsoNormal><span style='color:black'><o:p> </o:p></span></p></div><div><p class=MsoNormal><span style='color:black'>Chris Lamont Mankowski<o:p></o:p></span></p></div></div></div></div></div></div></div></body></html>