Re: [dmarc-ietf] Solution for DMARC disruption of normal email use while still offering its normal protection

[Brandon Long <[e-mail]>]

On Wed, May 28, 2014 at 11:20 AM, Douglas Otis <[e-mail]>
wrote:

>
> On May 28, 2014, at 12:07 AM, Brandon Long <[e-mail]> wrote:
>
> So...
>
> I think this buries the lede a bit more than the OAR suggestion does.  I
> could imagine something like this for broadcasting who a service trusts the
> OAR header from.
>
> This basically would require someone like Yahoo/Gmail to host some 30k DNS
> records granting any one of those third party services the ability to send
> mail for yahoo.com/gmail.com.
>
> For a service at this scale, you'd need to only do this for places where
> you "trust" their Authentication-Results header.  There is a potential
> issue of conflicting AR headers, which is one benefit of the OAR.
>
> Its not clear to me that gmail.com needs to tell another service to trust
> the OAR from a given third party, the choice to trust that service could
> easily be up to the receiving service.
>
> Finally, doesn't this imply a potentially large number of DNS queries?
>  Given the various mechanisms for finding the domain, and given that you
> have to look up the tpa record to know whether that mechanism is supported,
> it would seem you would need to look up tpa records for up to 7 possible
> domains, and potentially more with sub-domain checking.
>
>
> Dear Brandon,
>
> http://tools.ietf.org/html/draft-kucherawy-original-authres-00
>
> You'll see statements in the TPA-Label draft about including
> authentication-results and indeed this new header should be referenced as
> well.  Sorry about the omission. When there is a problem, the DMARC domain
> is still unable to respond to what might cause expensive damage when
> misplaced trust leads to customer attrition whenever uncontrolled sources
> are allowed to flood inboxes spoofing their identity.  The TPA-Label draft
> permits an effective response in minutes.
>

I don't think it does.

Take another way, without AuthRes, you're exposing your entire domain to
phishing attacks if there is any open relay on the "whitelisted" domain.
 Even with AuthRes, you're exposing your users to any intrusion on a third
party, and with 30k such third parties, some of them are going to get
hacked some times.  We've already seen "open posting" mailing lists on
trusted third parties used for spear phishing attacks, and that's not
something that "response in minutes" would solve.


> TPA-Label does not imply a large number of DNS transactions, unlike SPF or
> even DKIM.  TPA-Label is a single transaction directed toward a DMARC
> domain. There should only be one DMARC domain recognized per message.  Of
> course, as with any DNS transaction, this can be redirected to other
> domains.  It is still a single transaction, unlike SPF which can result in
> more than 100 transactions with any number of additional redirections
> involving other domains completely unrelated to domains seen in the
> exchange.  The TPA-Label can assert which validation methods should be used
> to help further reduce the number of DNS transactions needed.
>

Unless I'm mis-understanding, there is a single DMARC domain, but there are
N third party domains allowed, and how each one is allowed is specified in
their specific record.

So, I look in list-id, and then do a lookup for <list-id domain
hash>._smtp._tpa.<dmarc domain> and see if list-id domain is valid for tpa.
 If not, I then have to do <sender domain> and then go through the list of
7 possible locations, each of which could be different.

And if sub-domains are allowed, then if the list-id is "
foo.groups.google.com", I have to check "groups.google.com" and "google.com
".

Also, if some of those domains are googlegroups.com or yahoogroups.com,
whitelisting the entire thing is impractical, its not a controlled
environment where you can garuntee zero abuse.

Now, with caching, especially negative caching, and "legitimate" email most
likely having the same domain in most of the seven locations, real world
may be only a single lookup per message, and spoofed/bad messages would
likely need all 7.

Given that a small number of users is subscribed to any given mailing list,
I think some sort of mail relay token or a new dkim canonicalization would
be more practical.  Then, you have "this list is allowed to relay this
message" or "this user is subscribed to this list" or something.  Even
then, you may have issues with spear phishing attacks.

Brandon


>
> A shared DMARC-bypass whitelists would remove control away from the DMARC
> domain that has an incentive to ensure protection.  Community white-lists
> would make responding to any abuse impractical, to say the least.  In
> today's environment, an ability to respond should not be overlooked.
>
> A TPA-Label authorization would not be granting anyone the ability to send
> email for a domain.  This authorization simply permits alignment exceptions
> for specific third-party services that must still permit the validation of
> their own domain.  The authorization can also stipulate third-party domains
> must include their domain in a Sender or a List-ID.  If a problem is seen
> by any of their messages, the DMARC domain can retract authorization in
> minutes.  Those who apply DMARC alignment checks would be able to make
> exceptions for these third-party messages based on advice given directly
> from the DMARC domain.
>
> TPA-Labels as a disruption remedy can be done fairly rapidly since this
> would involve only those implementing DMARC.  Changing 30K mailing lists
> where one might be running in the basement of a local church should be
> expected to take much longer.
>
> Google already provides free recursive DNS for anyone to use.  It seems
> possible, Google could even get the ball rolling by offering a "_smtp._
> tpa.gmail.com" zone that others might wish to reference.  This would
> allow an easy and immediate solution for any DMARC domain willing to allow
> Google to manage their third-party services.  TPA-Labels will require the
> support of some large ISP before is likely to gain adoption.  I'll update
> the draft to include draft-kucherawy-original-authres-00
> <http://tools.ietf.org/html/draft-kucherawy-original-authres-00>.
>
> Regards,
> Douglas Otis
>
> On Tue, May 27, 2014 at 7:49 PM, Douglas Otis <[e-mail]>
> wrote:
>
>> Dear DMARC WG,
>>
>> A draft has been submitted for review.  It covers past failures while
>> also providing a path forward.
>>
>> I have experience with similar systems operating at much higher scale
>> without difficulty or using much in the way of resources.  Serving several
>> very large ISPs worth of users making queries against every received
>> message that then returned about 2 billion unique resource responses.
>> Originally, the service was free.
>>
>> In the wake of a massive compromise of accounts, some fairly large ISPs
>> are doing perhaps the only thing that is not (yet) ignored, DMARC.
>>
>> However, this new scheme only needs to sustain queries against already
>> validated third-party domains, but that then fail DMARC alignment
>> assertions. The number of resource records likely needed by large ISPs will
>> be in the 10s of thousands.  For smaller domains, this will likely only be
>> a hand-full.  Domains asserting DMARC alignment practices are receiving
>> cooperative feedback from many receivers who are also acting on behalf of
>> these domains to either reject or quarantine non-aligned messages.
>>  Comparing this feedback against their own outbound logs should permit
>> fairly automatic alignment exception list creation that can then be kindly
>> offered to their cooperative receivers.  These record permit several
>> mitigation strategies in the case of trouble. This scheme should reduce the
>> amount of feedback collected or support required to deal with broken
>> services.  This can be done by creating an informal federation of
>> third-party providers.  Perhaps one of the requirements for being included
>> in the federation would be to provide normal DMARC feedback. ;^)
>>
>> http://tools.ietf.org/pdf/draft-otis-tpa-label-00.pdf
>>
>> Regards,
>> Douglas Otis
>>
>
>
>