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

Murray Kucherawy msk at fb.com
Tue Jun 19 23:03:46 PDT 2012


I presume that BYODs send mail to a designated MTA operated by the mobile service provider, and not directly to the addressee's mail server.  Indeed, many receiving MTAs would probably not accept those connections directly, just like ISPs today tend to disallow connections from dynamic address pools.

Even if they did, how is the receiving MTA supposed to be able to validate what's in the TLS certificate?  Anyone can create a certificate that claims to belong to "example.com"; how do you know it's real?  I would imagine a service provider wouldn't share a certificate among all of its provisioned devices, so there has to be some way to determine that an arbitrary certificate was legitimately authorized by a service provider, and they are fairly large in number.  A PKI scale problem again, as you mentioned.  The nascent DANE concept might help with this, but it'll be some time before it's widely deployed and supported.

Back to the indirect routing claim: Assuming that's true, the handset TLS client authentication will be between your handset and your service provider, not your handset and the addressee.  The service provider then relays the message.  So the TLS of interest to DMARC, in your scenario, is between the service provider and the addressee.  But 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.

What am I missing here?

-MSK

From: Chris Lamont Mankowski <makerofthings77 at gmail.com<mailto:makerofthings77 at gmail.com>>
Date: Wed, 20 Jun 2012 00:26:14 -0400
To: John Levine <johnl at taugh.com<mailto:johnl at taugh.com>>
Cc: <dmarc-discuss at dmarc.org<mailto:dmarc-discuss at dmarc.org>>
Subject: Re: [dmarc-discuss] Is DMARC the right place for SMTP-TLS policy and reporting?

S/MIME could be an option for some industries, but I'm a finance vertical and we are required to have a supervisory compliance agent review our electronic communications.  (See Smarsh.com or Proofpoint Archive as an example)

All the comparable S/MIME solutions I looked at required a cumbersome BCC agent mechanism that didn't consistently work across all devices.  Now that we are in the Bring Your Own Device (BYOD) world, I can't ensure that the proper S/MIME BCC agent would be applied on iPhones, Blackberries,  Webaccess, Outlook, etc.  The technical challenges are too great, and the cost to implement is too high.

Add to that the complexity of IT operations where we have to gain the in-house expertise in PKI private key retrieval, and key management.  Users may have many keys if they renew, or loose the private key.  I don't want to get into all the details here, but it's a technical burden on an overworked IT staff.

Add one legal discovery operation that spans 3,000 or more individuals, and the back loaded costs are enormous and the privacy gained just isn't worth it.  (though in non-publicly traded companies like the government the privacy benefits may be worth the cost)

TLS is simple, analogous to a VPN and allows the business to be agile.  To be honest I don't ever see us using S/MIME even if Verisign gave us and our peers free certificates.



On Tue, Jun 19, 2012 at 6:10 PM, John Levine <johnl at taugh.com<mailto:johnl at taugh.com>> wrote:
>Bottom line, I'd support a MUA indicator if DMARC policy also reflected
>encryption requirements.

Well, OK.  We we want encryption, what's wrong with S/MIME?  Unlike
TLS, it's end to end, and is supported in most MUAs.  S/MIME certs
are basically the same as TLS certs.

R's,
John

_______________________________________________ dmarc-discuss mailing list dmarc-discuss at dmarc.org<mailto: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)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://medusa.blackops.org/pipermail/dmarc-discuss/attachments/20120620/5e28b13d/attachment-0001.htm>


More information about the dmarc-discuss mailing list