> -----Original Message-----
> From: McDowell, Brett [mailto:[email protected]]
> Sent: Thursday, September 09, 2010 10:21 AM
> To: MH Michael Hammer (5304)
> Cc: [email protected]
> 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
[email protected]
http://mipassoc.org/mailman/listinfo/dkim-ops
