-----Original Message-----
From: McDowell, Brett [mailto:bmcdowell(_at_)paypal-inc(_dot_)com]
Sent: Thursday, September 09, 2010 10:21 AM
To: MH Michael Hammer (5304)
Cc: dkim-ops(_at_)mipassoc(_dot_)org
Subject: Re: [dkim-ops] subdomain vs. cousin domain (when
deploying"discardable")
Since Hector (rightly) didn't let me leave this thread in a state of
disagreement, I'll pick-up on what I think is the most important
concept
to get right.
On Sep 4, 2010, at 1:04 PM, MH Michael Hammer (5304) wrote:
My personal belief is that use of subdomains presents less of an
increase in attack surface than use of analog domains.
That's the $64K question isn't it. Will more customers fall prey to
phishing attacks if norms like domain-inc.example are reinforced as
"trustworthy" than if criminals discover and exploit an un-protected
subdomain like corp.domain.example?
There's a lot more than $64k riding on it.
Perhaps I need to be more specific as to why I recommend what I do. My
general recommendation would normally be to use a very different domain
but in the particular case of Paypal the issue is complicated by
existing practices.
For example, this email originates from ag.com. It is a pretty extreme
edge case that a (card notification) phishing email from ag.com would be
confused by an enduser as coming from americangreetings.com.
You have to work with the hand that has been dealt and my experience as
a sender having domains that are targets for abuse tells me that in this
particular situation you have less risk using the subdomain (unless you
are willing to incur an extreme amount of pain and suffering over the
near and medium term).
Let's shift our focus to methodology for finding out the truth of this
question. How could we "test" or "measure" this that would result
statistically valid results for what is truly "best practice"?
You cannot. What you have asked us to comment on is a fairly unique
situation. The general rule would be to use a different domain that is
far enough from the transactional/brand domain that the risk of use for
enduser phishing is mitigated.
The case we are discussing is a situation where the corporate users are
using the same domain as the transactional domain and you need to do
something to address the conflict between strict policies to protect
against (transactional) phishing and corporate use which results in mail
going through lists, etc. with the commensurate risk of authentication
breakage.
We could measure:
- how many customers receive ADSP=all vs. ADSP=discardable mail
(either
from domain-inc.example or corp.domain.example. This would give us an
indication of the scale of the new "norm" we are creating by operating
a
non-discardable domain. For example, does the sophisticated user
(i.e.
the only user who actually pays attention to the from:filed domain)
differentiate corp.domain.example from domain.example when making a
trust
decision? If not (as I suspect they do not), then all mail from
domain.example reinforces the modality that corp.domain.example should
be
trusted. Comparing that statistically to mail customers see from
domain-
inc.example and it's no contest. This could be tested in a usability
lab.
If my guess is correct then it sways us toward domain-inc.example as
the
better practice.
Endusers are too trusting. Your issue is that you have already
implemented controls to prevent endusers from getting messages that
purport to be from Paypal where validation fails.
Unfortunately the question you are trying to ascertain is whether it
hurts less to die by firing squad or the guillotine. The folks who abuse
you now will test for opportunities either way.
- is the harm of having this non-discardable mail stream discarded in
error comparable to the harm done if phishing mail from the non-
discardable namespace is delivered? That depends on what the users do
with the phish mail that is delivered... are they more likely to fall
prey
to the attack if it comes from corp.domain.example than if it comes
from
domain-inc.example? Yes, I think so but it's something that could be
tested in a usability lab. Of course if the answer is yes, then we
sway
toward domain-inc.example as the better practice.
The bad guys will be much more creative than your usability lab. When
you say "harm" are you talking about the harm to the enduser, harm to
the brand, harm to the employee whose mail was dropped or some other
harm? While these may be related they are not the same thing and the
tradeoffs are not a straight forward thing.
- Then there's the issue of implementation issue of DKIM of t=s vs.
t=null
(absent). I'll be honest, the language of RFC 5672 is clear as mud
from
my perspective so I'd love someone else's read of how this decision
would
impact our choice of domain-inc.example vs. corp.domain.example
(language
from RFC pasted below for quick reference)
<snip RFC 5672>
...for example, a key record for the domain example.com can be
used to verify messages where the AUID ("i=" tag of the
signature)
is sub.example.com, or even sub1.sub2.example.com. In order
to
limit the capability of such keys when this is not intended,
the
"s" flag MAY be set in the "t=" tag of the key record, to
constrain the validity of the domain of the AUID. If the
referenced key record contains the "s" flag as part of the
"t="
tag, the domain of the AUID ("i=" flag) MUST be the same as
that
of the SDID (d=) domain. If this flag is absent, the domain
of
the AUID MUST be the same as, or a subdomain of, the SDID.
</snip RFC 5672>
Are there other measurable considerations?
BTW, whatever is done now is only temporary because solving the root
problem (MLM's handling of DKIM) will make the need for
non-discardable
domains moot, for the most part.
I would not hold my breath on this. If the recent discussion of the MLM
draft hasn't convinced you of the futility of doing so, I don't know
what will....
If the only issue you are trying to resolve pertains to mailing lists I
would propose another solution vector. Don't allow employees to
participate in mailing lists using work email addresses. A variation
would be to require employees who participate in mailing lists to use a
separate domain that is only used for mailing lists. You could then tell
receivers that if the mail for that domain did not come through a list
they should throw it away.
More than one way to skin a cat.
Mike
_______________________________________________
dkim-ops mailing list
dkim-ops(_at_)mipassoc(_dot_)org
http://mipassoc.org/mailman/listinfo/dkim-ops