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

Chris Lamont Mankowski makerofthings77 at gmail.com
Tue Jun 19 22:21:55 PDT 2012


 It's late.. I realized I wrote "DKIM reports the outcome"  I'm sure
everyone knows I meant DMARC.  Freudian slip   ;)


On Wed, Jun 20, 2012 at 1:11 AM, Chris Lamont Mankowski <
makerofthings77 at gmail.com> wrote:

> 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.
>
> 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.
>
> 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?
>
> 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.
>
> 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.
>
> Specifically:
>
>    - I want to define the version of TLS that was used (TLS 1.1 or newer
>    in my case)
>    - The cipher must be RSA2048 or DHE
>    - The hash must be SHA2 or newer
>    - The subject name (or SAN) must match the sending domain
>    - (optional) the cert must be trusted in the root store
>    - (optional) the cert must have a thumbprint equal to xxx (allows for
>    self signed certs)
>    - (optional) DNSSec is used for all certificate operations (to allow
>    full compatibility with .gov)
>
>
> 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.
>
>
> On Wed, Jun 20, 2012 at 12:38 AM, John R. Levine <johnl at iecc.com> wrote:
>
>>  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)
>>>
>>
>> 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.
>>
>> Regards,
>> John Levine, johnl at iecc.com, Primary Perpetrator of "The Internet for
>> Dummies",
>> Please consider the environment before reading this e-mail. http://jl.ly
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://medusa.blackops.org/pipermail/dmarc-discuss/attachments/20120620/f6b8d9b6/attachment-0001.htm>


More information about the dmarc-discuss mailing list