[dmarc-discuss] Is DMARC the right place for SMTP-TLS policy and reporting?

Roland Turner roland.turner at trustsphere.com
Tue Jun 19 23:22:21 PDT 2012


Chris,

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.

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 _*does*_ 
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.

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.

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.

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.

- Roland


On 19/06/2012 22:28, Chris Lamont Mankowski wrote:
> Does it make sense for DMARC policy to define policy and feedback 
> reporting of TLS?
>
> 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 et.al 
> <http://et.al>.  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.
>
> 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.
>
> 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.
>
> Keeping in the spirit of DMARC, no PKI is needed if the TLS 
> implementation published certificates in DNS (TLSA formerly DANE) 
> <http://tools.ietf.org/html/draft-ietf-dane-protocol-23%20>This 
> concept could allow for an authorized SMTP sender to publish its 
> public keys into DNS, while removing any dependency (or vulnerability 
> <http://security.stackexchange.com/q/2268/396>) on the PKI hierarchy.
>
> 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, here is information on why DNSSec is required 
> <http://security.stackexchange.com/q/6824/396> and additional 
> information on how easy it is to spoof DNS 
> <http://security.stackexchange.com/q/6827/396> .
>
> ***Small gripe to MUA implementors w.r.t DMARC***
>
> 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.
>
> 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.
>
> Bottom line, I'd support a MUA indicator if DMARC policy also 
> reflected encryption requirements.
>
> ***Questions***
> 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?
>
> Is there any specific initiative, RFC, or the like that gets MTAs to 
> incorporate TLS with TLSA-based verification? (aka DANE)
>
> Thanks for your consideration,
>
> Chris Lamont Mankowski
>
>
> _______________________________________________
> dmarc-discuss mailing list
> dmarc-discuss at dmarc.org
> http://www.dmarc.org/mailman/listinfo/dmarc-discuss
> NOTE: Participating in this list means you agree to the DMARC Note Well terms (http://www.dmarc.org/note_well.html)

-- 
   Roland Turner | Director, Labs
   TrustSphere Pte Ltd | 3 Phillip Street #13-03, Singapore 048693
   Mobile: +65 96700022 | Skype: roland.turner
   roland.turner at trustsphere.com | http://www.trustsphere.com/

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://medusa.blackops.org/pipermail/dmarc-discuss/attachments/20120620/801037bf/attachment.htm>


More information about the dmarc-discuss mailing list