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

Scott Kitterman sklist at kitterman.com
Wed Jun 20 11:26:09 PDT 2012


WIth respect to shared IP addresses, the issues associated with them are 
addressed in RFC 4408.  It's not that hard to implement local controls to make 
sure local users are only using appropriate identities in email.

Scott K

On Wednesday, June 20, 2012 06:14:12 PM Murray Kucherawy wrote:
> On shared IP addresses, there are two considerations:
> 
>   1.  DKIM is agnostic to IP addresses.  That means for shared IP addresses,
> only authorized clients can possibly add valid signatures. 2.  A client
> behind a shared IP address is most likely (when sending legitimately) to
> send via its service provider's MTA, and not directly.  TLS in that case
> would be useful to authenticate the client to the service provider, but not
> to the recipient.  It's the latter spot where DMARC is in effect.
> 
> On required TLS: There are really two hops of interest here, namely one
> between the author and its service provider's MTA, and the one from that
> MTA to the recipient.  If you use TLS to secure the transport in both
> cases, you meet the regulatory requirement you're talking about, but still
> it's only that last hop that's of interest to DMARC.  SPF and/or DKIM have
> a high likelihood of success there, so it's still unclear what TLS brings
> in terms of incremental improvement.  Where the direction is reversed, such
> as something transactional or a notification back to the user, only the
> second half of that model exists, but the logic is the same.
> 
> (Also, I don't think bank.example.com is really too concerned about
> authenticating mail from your home account; it's really the other direction
> that's interesting, in which case your BYOD isn't part of the equation.)
> 
> A service provider adding to its SPF policy the entire IP space from which
> BYODs will be seen to connect is inviting degraded reputation.  This goes
> for your hotel example too.  I don't think that's likely to happen.
> 
> Your key verification ideas seem to be jumbled.  DANE is, to paraphrase, the
> storage of key fingerprints in the DNS as a way of associating a
> certificate with a domain in some way that's more authoritative than "that
> guy said so".  Storage of public keys in DNS is a DKIM thing, not a DANE
> thing.  Repurposing DKIM as you described seems like it would be redundant
> to what DANE already does.
> 
> I wouldn't expect an ISP to authorize use of its domain by any arbitrary
> hotel connection that appears.  I would expect hotel connections to send
> mail through some other authorized mail server, such as a VPN back to home
> base.  That will cause the mail to go out through a stable relay, where SPF
> and DKIM are reliable.  Anything else is a vector for abuse.
> 
> I'm not sure I agree that the weakening of SPF through shared addresses is a
> concern, because I don't think people are using SPF that way.  A domain
> owner that puts shared IP address ranges in its SPF record is begging for
> degraded reputation at both the IP and domain level.  Instead of trying to
> balance better SPF coverage with weakened results, you have the option of
> using DKIM as well since it's route-agnostic.  The SPF record for
> "comcast.net" for example appears to contain nothing bigger than a /23,
> which I'm sure doesn't include any of their shared IP space.  DMARC only
> requires that one of the two pass.
> 
> To boil it all down: DMARC looks at a message and says "Did this come from
> an authorized IP address (SPF), or via an authorized handler (DKIM)?"  I
> still don't see what TLS brings to that picture to make it more complete.
> 
> -MSK
> 
> 
> From: Chris Lamont Mankowski
> <makerofthings77 at gmail.com<mailto:makerofthings77 at gmail.com>> Date: Wed, 20
> Jun 2012 12:34:58 -0400
> To: Roland Turner
> <roland.turner at trustsphere.com<mailto:roland.turner at trustsphere.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? 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
> berepurposed 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<http://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 onthem.
> 
> 
> 
> [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
> DANE.
> 
> 
> 
> 
> 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
> FAIL or a DKIM FAIL.
> 
> 
> 
> - (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
> system. _______________________________________________ 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)



More information about the dmarc-discuss mailing list