<p class="MsoNormal">Thank you for the well thought out criticism.  I've done my best to address each point and remove duplication, but let me know if I missed something.  The TL;DR version is I still think TLS Authentication has a place with DMARC. TLS is currently deployed with various skill levels by administrators, and the consistency of failure modes of TLS is much of a lose end as SPF/DKIM is.  It makes sense to consolidate all three polices in a single framework. </p>
<p class="MsoNormal"><br></p><p class="MsoNormal">Let me preface this response by saying I have no intention to slow down current DMARC progress.  I’m open to this being in scope for vNext, though I want it in v1.  At the least I simply want to create a placeholder and compatibility for what I consider to be the next logical step.</p>
<p class="MsoNormal"><br></p><p class="MsoNormal"><br></p><p class="MsoNormal"></p>

<p class="MsoNormal"> </p>

<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><b>Franch Martin said:<br></b> - [If] the authentication-result header indicate[d] when TLS was employed, would that serve your purpose better?</blockquote>
<div> </div><p class="MsoNormal"></p>

<p class="MsoNormal"></p>

<p class="MsoNormal">This is helpful on the receiver's end, but doesn't help when
a domain owner is trying to define consistent outbound behavior for all MTAs.  This is especially important when the domain owner doesn't control and administer every outbound MTA.  </p><p class="MsoNormal"><br></p><p class="MsoNormal">
<br></p>

<p class="MsoNormal"> </p>

<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><b>Murray Kucherawy said:</b><br>- 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.</blockquote><p class="MsoNormal"></p>

<p class="MsoNormal"></p>

<p class="MsoNormal"> </p>

<p class="MsoNormal">I see SPF and DKIM analogous to dual factor authentication for a message.   SPF refers to an IP address "something the sender has", bound to a DNS name.  DKIM is the signed contents also bound to a DNS name.  Signed contents should be sent from approved senders.  This also prevents replay attacks.  </p>
<p class="MsoNormal"><br></p><p class="MsoNormal">Everything is simple if no shared IPs are involved.  But, if ashared IP is involved, SPF authentication is weakened.  TLS would address this scenario with a private key held by the sender.</p>
<p class="MsoNormal"><br></p><p class="MsoNormal">If the goal of DMARC is to provide sufficient information to the domain owner about all the MTAs so a quarantine or drop policy can be applied, then we're starting to define the barrier (or demarcation point ;)) where email delivery becomes the receivers problem and not the sender's.</p>
<p class="MsoNormal"><br></p><p class="MsoNormal">I just want to mention that authenticating via TLS also has disjoint failure modes.  The sender usually defines these as: NDR the message, or queue and retry. 
The behavior of this is inconsistent at best since there the domain owner often doesn't control every MTAs.  Examples include: Hotels, ISPs, marketing campaigns, etc.</p>

<p class="MsoNormal"> </p><p class="MsoNormal"><br></p><p class="MsoNormal"><br></p>

<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">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.</blockquote><p class="MsoNormal"></p>

<p class="MsoNormal"> </p>

<p class="MsoNormal">This is absolutely viable for the class of messages that
don't require TLS.  Not every message
warrants the protection a TLS encrypted payload offers.  However, for those people concerned about
data encrypted in transit, such as those email messages regulated by HIPPA, UK,
Massachusetts or California privacy laws require messages to be encrypted in
transport.</p><p class="MsoNormal"><br></p><p class="MsoNormal"><br></p>

<p class="MsoNormal"> </p>

<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"> 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.</blockquote><p class="MsoNormal"></p>

<p class="MsoNormal"> </p>

<p class="MsoNormal">The irony here is that I don't have sufficient visibility to
prove or disprove this myself. </p>

<p class="MsoNormal"> </p><p class="MsoNormal"><br></p>

<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">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.</blockquote><p class="MsoNormal"></p>

<p class="MsoNormal"><br></p><p class="MsoNormal">I’ll assert that those excluded senders probably don't need
the encryption to begin with.  For
example, senders and receivers of Greeting Cards probably don't care about
encryption, but password reset notifications, financial, PII or HIPPA data
should be encrypted.  Most people who
care about security likely also have a HTTPS certificate, which can also be
repurposed for use with TLS.</p>

<p class="MsoNormal"><br></p><p class="MsoNormal"><br></p><p class="MsoNormal"><br></p><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<span style="font-size:10.5pt;line-height:115%;color:#222222">I presume that BYODs send mail to a designated MTA operated by the mobile
service provider</span></blockquote><p class="MsoNormal"></p>

<p class="MsoNormal"><span style="font-size:10.5pt;line-height:115%;color:#222222"><br></span></p><p class="MsoNormal"><span style="font-size:10.5pt;line-height:115%;color:#222222">This
is one example where SPF breaks, that is unless the domain owner specifies the
IP range of each mobile service provider’s relay.  The only way I can imagine this working is to
blur the lines between email submission and email exchange, just as Roland saw I was
doing.   </span></p><p class="MsoNormal"><span style="font-size:10.5pt;line-height:115%;color:#222222"><br></span></p><p class="MsoNormal"><span style="font-size:10.5pt;line-height:115%;color:#222222"><br></span></p>

<p class="MsoNormal"><br></p><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span style="font-size:10.5pt;line-height:115%;color:#222222">Anyone can create a certificate that claims to belong to "</span><a href="http://example.com/" target="_blank" style><span style="font-size:10.5pt;line-height:115%;color:#1155cc">example.com</span></a><span style="font-size:10.5pt;line-height:115%;color:#222222"><span style>"; how do you know it's real?</span></span></blockquote>
<div> </div>

<p class="MsoNormal"><font color="#222222"><span style="font-size:10.5pt;line-height:115%">True, some verification is needed.  Some ideas on this:</span></font></p><p class="MsoNormal"></p><ul><li><span style="color:rgb(34,34,34);font-size:10.5pt;line-height:115%">Store the SHA Hashcode or thubmprint of the certificate</span><span style="color:rgb(34,34,34);font-size:10.5pt;line-height:115%"> in DNS. </span></li>
<li><span style="color:rgb(34,34,34);font-size:10.5pt;line-height:115%">Consider DANE or something similar where the public<span style="font-size:10.5pt"> key would be stored in DNS</span></span></li><li><span style="color:rgb(34,34,34);font-size:10.5pt;line-height:115%">Consider that DKIM
already has a key in DNS.  What if we
solved this problem by expanding the role of DKIM to also apply to TLS?  Of course that would be a separate RFC.. but
then again, DMARC is a composition of several different RFCs and reports on
them.</span></li></ul><p></p><p class="MsoNormal"><span style="font-size:10.5pt;line-height:115%;color:#222222"><br></span></p><p class="MsoNormal"><span style="font-size:10.5pt;line-height:115%;color:#222222"><br></span></p>


<p class="MsoNormal"><span style="font-size:10.5pt;line-height:115%;color:#222222"><br></span></p><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<span style="font-size:10.5pt;line-height:115%;color:#222222">[Regarding indirect routing] chances are SPF and/or DKIM are in good shape for that
message already, so the added client authentication TLS would provide for that
hop doesn't gain much</span></blockquote><p class="MsoNormal"></p>

<p class="MsoNormal"><span style="font-size:10.5pt;line-height:115%;color:#222222"><br></span></p><p class="MsoNormal"><font color="#222222"><span style="font-size:10.5pt;line-height:115%">I'll challenge that solution and think it's not as practical as we hope it could be.  For example, is
it really a good idea for a domain owner to create a list of every ISP and hotel relay
and maintain that within a TXT record?  I would think this administrative </span><span style="font-size:14px;line-height:16px">burden</span><span style="font-size:10.5pt;line-height:115%"> is error prone, likely not to be updated, and increases risk that approved shared MTAs that will be used for
malicious purposes.  </span></font></p><p class="MsoNormal"><span style="font-size:10.5pt;line-height:115%;color:#222222"><br></span></p>

<p class="MsoNormal"><font color="#222222"><span style="font-size:10.5pt;line-height:115%">Since
DMARC is all about message authentication of (1) the node that sends the mail
(2) the contents of the message, we lose confidence in </span><span style="font-size:14px;line-height:16px">authentication</span><span style="font-size:10.5pt;line-height:115%"> whenever the IP Address(#1)
is shared with someone else.  In this
case, we have to substitute the security principal of</span></font><a href="http://security.stackexchange.com/q/3796/396" style="color:rgb(34,34,34);font-size:10.5pt;line-height:115%"> “something you have” </a><font color="#222222"><span style="font-size:10.5pt;line-height:115%">with
something else.  I propose that something
else be a certificate in the form of PKI, DKIM, or DANE.</span></font></p>

<p class="MsoNormal"><font color="#222222"><span style="font-size:14px;line-height:16px"><br></span></font></p><p class="MsoNormal"><font color="#222222"><span style="font-size:14px;line-height:16px"><br></span></font></p>
<p class="MsoNormal"><font color="#222222"><span style="font-size:14px;line-height:16px"><br></span></font></p>

<p class="MsoNormal"><br></p><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Roland said:<br>- <span style="font-size:10.0pt;line-height:115%;font-family:"Arial","sans-serif";color:#222222">If you want to add TLS as an authentication
mechanism to DMARC, yo</span>u'll first need an existing authentication
protocol that yields a pass/fail/unknown result and second you'd need
widespread adoption, at least to the point of covering, say, 10% of the
legitimate email received by multiple interested receivers</blockquote><p class="MsoNormal"></p>

<p class="MsoNormal"></p>

<p class="MsoNormal"><br></p><p class="MsoNormal">Almost every MTA I can think of supports the verification of
a TLS connection.  The administrator
usually configures the MTA for Reject, Accept, or Retry.  </p><p class="MsoNormal"><br></p><p class="MsoNormal">The only thing missing from TLS is a consistent centralized approach to policy.  The failure of a TLS connection is as much of
a loose end as a SPF FAIL or a DKIM FAIL.</p><p class="MsoNormal"><br></p><p class="MsoNormal"><br></p>

<p class="MsoNormal"> </p>

<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">- <span style="font-size:10.0pt;line-height:115%;font-family:"Arial","sans-serif";color:#222222">(I'd suggest DANE rather than TLS-OBC)</span></blockquote>
<p class="MsoNormal"></p>

<p class="MsoNormal"><span style="font-size:10.0pt;line-height:115%;font-family:"Arial","sans-serif";color:#222222"><br></span></p><p class="MsoNormal"><span style="font-size:10.0pt;line-height:115%;font-family:"Arial","sans-serif";color:#222222">You’re right, I sent a different communication to
the DomainKeys group, and corrected my wording when I posted to DMARC.</span></p><p class="MsoNormal"><span style="font-size:10.0pt;line-height:115%;font-family:"Arial","sans-serif";color:#222222"><br>
</span></p><p class="MsoNormal"><span style="font-size:10.0pt;line-height:115%;font-family:"Arial","sans-serif";color:#222222"><br></span></p>

<p class="MsoNormal"><span style="font-size:10.0pt;line-height:115%;font-family:"Arial","sans-serif";color:#222222"><br></span></p><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<span style="font-size:10.0pt;line-height:115%;font-family:"Arial","sans-serif";color:#222222">- Note that the widespread use of TLS in
FSI on the back of bilateral or intra-consortium agreements is not sufficient, </span></blockquote>

<p class="MsoNormal"><br></p><p class="MsoNormal">Pardon my ignorance, I’m not sure what FSI means and a Google search for “email
FSI RFC” didn’t expose anything obious for me. 
Would you elaborate?</p><p class="MsoNormal"><br></p><p class="MsoNormal"><br></p>

<p class="MsoNormal"><br></p><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">- <span style="font-size:10.0pt;line-height:115%;font-family:"Arial","sans-serif";color:#222222">to attempt to replace/augment SPF with TLS
would achieve exactly nothing</span></blockquote><p class="MsoNormal"></p>

<p class="MsoNormal"><br></p><p class="MsoNormal">SPF is weakened in scenarios where an IP is shared with
multiple users.  TLS could be a viable
alternative here.  I have no desire to
delay the implementation of DMARCv1 but want to make sure we have provisions in
place for DMARCv2 (or DMARC+Security if deemed out of scope) </p><p class="MsoNormal"><br></p><p class="MsoNormal"><br></p>

<p class="MsoNormal"><br></p><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">I think that DMARC has no relevance whatever to MUAs...
Establishing an EV CERT type agreement may be a worthy goal, but DMARC has
little/nothing to add to this process.</blockquote><p class="MsoNormal"></p>

<p class="MsoNormal"><br></p><p class="MsoNormal">Agreed, the DMARC specification doesn't cover MUAs except to permit they can report on the authentication outcome.  Some MUAs will do more, some will do less with the user interface.</p>
<p class="MsoNormal"><br></p><p class="MsoNormal"><br></p>

<p class="MsoNormal"><br></p><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">- <span style="font-size:10.0pt;line-height:115%;font-family:"Arial","sans-serif";color:#222222">If you are able to persuade a group of
receivers who are already using TLS to incorporate their TLS results into DMARC
aggregate reports then you might get movement on some of these points</span></blockquote><div> </div><p class="MsoNormal"></p>

<p class="MsoNormal">Sounds like a reasonable challenge. Are there any
considerations for the report format that I should be aware of to maintain
maximum compatibility?</p><p class="MsoNormal"><br></p><p class="MsoNormal"><br></p>

<p class="MsoNormal"><br></p><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">- What is it you think that DMARC reporting can actually
add?</blockquote><div> </div><p class="MsoNormal"></p>

<p class="MsoNormal">DMARC reporting offers a single location where email policy
can be defined, broadcast and aggregated across a variety of MTAs, each of
which may be under different administrative control, software version, and may have
differing configurations (some of which in error).  It allows for report consumers to view
summary data in a consistent XML format.</p><p class="MsoNormal"><br></p>

<p class="MsoNormal">Your right, it is theoretically possible to get this report
today, but not all MTAs expose this, or if they do the format varies
greatly.  Some hosted platforms won't
share this with the domain owner, and if they do, it is per-message after
grepping the MTA logs.</p><p class="MsoNormal"><br></p>

<p class="MsoNormal">Add to the previous point that not every outbound MTA is
owned by the DNS domain owner.  Marketing
companies that send email outside the postmaster's control may send communications
that are not in compliance with the domain owner’s encryption policy.  It’s this type of configuration that prevents
a domain owner from setting a bi-directional TLS enforced policy for most
domains and restricts sender authentication and security of the email system.</p>