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

Chris Lamont Mankowski makerofthings77 at gmail.com
Wed Jun 20 09:34:58 PDT 2012

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.

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.

> *Franch Martin said:
> * - [If] the authentication-result header indicate[d] when TLS was
> employed, would that serve your purpose better?

 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.

> *Murray Kucherawy said:*
> - 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.

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

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.

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.

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.

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.

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.

>  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.

The irony here is that I don't have sufficient visibility to prove or
disprove this myself.

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.

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.

I presume that BYODs send mail to a designated MTA operated by the mobile
> service provider

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.

Anyone can create a certificate that claims to belong to "example.com"; how
> do you know it's real?

True, some verification is needed.  Some ideas on this:

   - Store the SHA Hashcode or thubmprint of the certificate in DNS.
   - Consider DANE or something similar where the public key would be
   stored in DNS
   - 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.

[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

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 burden is error prone, likely
not to be updated, and increases risk that approved shared MTAs that will
be used for malicious purposes.

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
authentication whenever the IP Address(#1) is shared with someone else.  In
this case, we have to substitute the security principal of “something you
have” <http://security.stackexchange.com/q/3796/396>with something else.  I
propose that something else be a certificate in the form of PKI, DKIM, or

Roland said:
> - 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

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.

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

> - (I'd suggest DANE rather than TLS-OBC)

You’re right, I sent a different communication to the DomainKeys group, and
corrected my wording when I posted to DMARC.

- Note that the widespread use of TLS in FSI on the back of bilateral or
> intra-consortium agreements is not sufficient,

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?

- to attempt to replace/augment SPF with TLS would achieve exactly nothing

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)

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.

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.

- 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

Sounds like a reasonable challenge. Are there any considerations for the
report format that I should be aware of to maintain maximum compatibility?

- What is it you think that DMARC reporting can actually add?

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.

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.

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://medusa.blackops.org/pipermail/dmarc-discuss/attachments/20120620/f785e564/attachment-0001.htm>

More information about the dmarc-discuss mailing list