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
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
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"?
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.
- 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.
- 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.
dkim-ops mailing list