<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Chris,<br>
<br>
I suspect that this isn't going to fly (a) because it doesn't solve
a current problem for anybody, (b) because you're trying to solve it
in the wrong place, (c) because TLS is not widely used for a
relevant purpose and (d) because you're confusing email submission
and email exchange.<br>
<br>
DMARC as an authentication mechanism is purely a composition of
other mechanisms, it adds no new ability to perform an
authentication that isn't already provided by one of the underlying
mechanisms (it <u><b>does</b></u> provide identifier alignment
rules, but not to the point of causing an authentication which would
otherwise fail to pass). Only mechanisms in widespread use have been
incorporated in order to minimise complexity and provide maximum
bang-for-buck. If you want to add TLS as an authentication mechanism
to DMARC, you'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. Such
mechanisms can readily be composed for TLS (I'd suggest DANE rather
than TLS-OBC) but none have currently reached broad consensus, much
less broad adoption. Note that the widespread use of TLS in FSI on
the back of bilateral or intra-consortium agreements is not
sufficient, you also need widespread use of a protocol that gives an
independent receiver a pass/fail/unknown result for a given message.<br>
<br>
That said, for DMARC's purposes, to attempt to replace/augment SPF
with TLS would achieve exactly nothing; SPF already does the job.
Purposes that aren't DMARC's (confidentiality of data in transit)
are advanced by this change, but DMARC's are not. The [massive]
increase in complexity that this change requires would therefore
tend to be resisted.<br>
<br>
Finally, you're talking about having mobile devices deliver email
directly to MXs rather than to submit to their organisation's
mail-severs. Setting aside that I suspect that most FSI participants
would ban this anyway, as Franck has already pointed out this would
run afoul of receiver policies about dynamic address space, would
break completely with hotel systems and the like, etc. If there was
an actual problem to solve here then there would be a discussion to
be had about reducing this distinction, but as it stands there does
not appear to be.<br>
<br>
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 (few
report processors are going to ignore reports because they contain
additional information) but until/unless you do so, I'd say that
this isn't going to fly.<br>
<br>
- Roland<br>
<br>
<br>
On 19/06/2012 22:28, Chris Lamont Mankowski wrote:
<blockquote
cite="mid:CANMw_CtVBrmCjVFf+K6y8wNJT1KAVNzZ7R57TjxXCW6Ts7KbxA@mail.gmail.com"
type="cite">
<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 face="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 moz-do-not-send="true" 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 face="arial, sans-serif" color="#222222"><br>
</font></div>
<div style=""><font face="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.</font></div>
<div style=""><font face="arial, sans-serif" color="#222222"><br>
</font></div>
<div style=""><font face="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.</font></div>
<div style=""><font face="arial, sans-serif" color="#222222"><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 moz-do-not-send="true"
href="http://tools.ietf.org/html/draft-ietf-dane-protocol-23%20">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
moz-do-not-send="true"
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 face="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,</font><a
moz-do-not-send="true"
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
face="arial, sans-serif" color="#222222"> and additional
information on</font><a moz-do-not-send="true"
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 face="arial, sans-serif"
color="#222222"> . </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>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
dmarc-discuss mailing list
<a class="moz-txt-link-abbreviated" href="mailto:dmarc-discuss@dmarc.org">dmarc-discuss@dmarc.org</a>
<a class="moz-txt-link-freetext" 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 class="moz-txt-link-freetext" href="http://www.dmarc.org/note_well.html">http://www.dmarc.org/note_well.html</a>)
</pre>
</blockquote>
<br>
<pre class="moz-signature" cols="72">--
Roland Turner | Director, Labs
TrustSphere Pte Ltd | 3 Phillip Street #13-03, Singapore 048693
Mobile: +65 96700022 | Skype: roland.turner
<a class="moz-txt-link-abbreviated" href="mailto:roland.turner@trustsphere.com">roland.turner@trustsphere.com</a> | <a class="moz-txt-link-freetext" href="http://www.trustsphere.com/">http://www.trustsphere.com/</a></pre>
</body>
</html>