<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
</head>
<body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; color: rgb(0, 0, 0); font-size: 14px; font-family: Calibri, sans-serif; ">
<div>I don't understand the characterization you have in the first paragraph. Both SPF and DKIM independently identify some party (in the form of a domain name) that takes some responsibility for the handling of the message, although they go about it differently
and have disjoint failure modes.</div>
<div><br>
</div>
<div>To flip your "same hop" logic around: If SPF and TLS evaluate the same hop, why not go with the far cheaper option? SPF consists of only a couple of DNS queries and some simple logic; the same cannot be said for TLS.</div>
<div><br>
</div>
<div>Are there significant scenarios in which SPF (and DKIM, for that matter) fail but TLS passes? If you're identifying a serious false negative issue, that's definitely something we need to consider.</div>
<div><br>
</div>
<div>Also, until DANE is widely deployed, TLS as a client authentication mechanism is only available to those who purchase CA-signed certificates. That has the feeling of being somewhat exclusionary, where DMARC has been trying to be as open as possible.</div>
<div><br>
</div>
<div>-MSK</div>
<div><br>
</div>
<span id="OLK_SRC_BODY_SECTION">
<div style="font-family:Calibri; font-size:11pt; text-align:left; color:black; BORDER-BOTTOM: medium none; BORDER-LEFT: medium none; PADDING-BOTTOM: 0in; PADDING-LEFT: 0in; PADDING-RIGHT: 0in; BORDER-TOP: #b5c4df 1pt solid; BORDER-RIGHT: medium none; PADDING-TOP: 3pt">
<span style="font-weight:bold">From: </span>Chris Lamont Mankowski <<a href="mailto:makerofthings77@gmail.com">makerofthings77@gmail.com</a>><br>
<span style="font-weight:bold">Date: </span>Wed, 20 Jun 2012 01:11:12 -0400<br>
<span style="font-weight:bold">To: </span>"John R. Levine" <<a href="mailto:johnl@iecc.com">johnl@iecc.com</a>><br>
<span style="font-weight:bold">Cc: </span><<a href="mailto:dmarc-discuss@dmarc.org">dmarc-discuss@dmarc.org</a>><br>
<span style="font-weight:bold">Subject: </span>Re: [dmarc-discuss] Is DMARC the right place for SMTP-TLS policy and reporting?<br>
</div>
<div><br>
</div>
<div>I don't think it's accurate to say this is about compliance verses S/MIME because that conversation is tangential to why I started this thread; I want to refocus on the part where SPF authenticates the sender, and DKIM reports the outcome. </div>
<div><br>
</div>
<div>Considering that TLS occurs at approximately the same hop when a SPF record is validated, and if SPF will be reported on via DKIM why shouldn't TLS be evaluated similarly? TLS provides an alternative method of validation to SPF that may be complimentary
in some situations. In situations such as legal or financial documents it could enhance overall security and trust in the message.</div>
<div><br>
</div>
<div>John quoted my comment on how Google's planned MUA will show a special icon for validated messages. Continuing on that train of thought: If TLS policy is excluded from the DMARC spec, and MUAs end up showing a validation icon, does that imply that when
a message is sent TLS Secured users will have yet another icon? </div>
<div><br>
</div>
<div>I'm envisioning a situation where a single email has so many validation icons it looks like the message was sponsored by Nascar. Users will be overwhelmed and won't be able to tell the difference.</div>
<div><br>
</div>
<div>The last time a significant user change was implemented someone invented the EV HTTPS certificate (the green bar in the URL) that provides no technical value other than the insurance that only applies to e-commerce sites. I want to prevent a repeat of
what I consider misguided history and add some real security backbone to what is displayed to the end user.</div>
<div><br>
</div>
<div>Specifically:</div>
<div>
<ul>
<li>I want to define the version of TLS that was used (TLS 1.1 or newer in my case)</li><li>The cipher must be RSA2048 or DHE </li><li>The hash must be SHA2 or newer</li><li>The subject name (or SAN) must match the sending domain</li><li>(optional) the cert must be trusted in the root store</li><li>(optional) the cert must have a thumbprint equal to xxx (allows for self signed certs)</li><li>(optional) DNSSec is used for all certificate operations (to allow full compatibility with .gov)</li></ul>
</div>
<div><br>
</div>
<div>I think DMARC can cause great things in MUAs to occur, and I'm elated it's being proposed but see that incorporating TLS policy and reporting as an essential component before anything is displayed to the end user as being secure.</div>
<div><br>
</div>
<br>
<div class="gmail_quote">On Wed, Jun 20, 2012 at 12:38 AM, John R. Levine <span dir="ltr">
<<a href="mailto:johnl@iecc.com" target="_blank">johnl@iecc.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
S/MIME could be an option for some industries, but I'm a finance vertical<br>
and we are required to have a supervisory compliance agent review our<br>
electronic communications. (See Smarsh.com or Proofpoint Archive as an<br>
example)<br>
</blockquote>
<br>
</div>
Hmmn. If this is about compliance, I think it's considerably outside the scope of what DMARC is intended for. But I'll defer to Murray to explain.<br>
<br>
Regards,<br>
John Levine, <a href="mailto:johnl@iecc.com" target="_blank">johnl@iecc.com</a>, Primary Perpetrator of "The Internet for Dummies",<br>
Please consider the environment before reading this e-mail. <a href="http://jl.ly" target="_blank">
http://jl.ly</a><br>
</blockquote>
</div>
<br>
_______________________________________________ dmarc-discuss mailing list <a href="mailto:dmarc-discuss@dmarc.org">
dmarc-discuss@dmarc.org</a> <a href="http://www.dmarc.org/mailman/listinfo/dmarc-discuss">
http://www.dmarc.org/mailman/listinfo/dmarc-discuss</a> NOTE: Participating in this list means you agree to the DMARC Note Well terms (<a href="http://www.dmarc.org/note_well.html">http://www.dmarc.org/note_well.html</a>)
</span>
</body>
</html>