On Mar 15, 2006, at 12:37 PM, J.D. Falk wrote:
On 2006-03-14 20:48, Douglas Otis wrote:
1) Access in the Signing-Domain's Administrative Unit
Somebody inside your network can do bad things inside your network!
Conventions established with DKIM where third-parties can isolate
accounts or internal sources for reporting and remediation, even when
an account has been compromised, as many are. This represents a
substantial portion of the abuse dismissed in the threat review as
being beyond the purview of DKIM. It should not be.
2) Chosen Message Replay (High impact)
An edge case that we've known about since day 0 is still an edge case!
Viewed from the aspect of establishing trust or preventing a Denial
of Services due to high levels of abuse, DKIM can still offer
defensive strategies beyond ineffectual key revocation.
3) Increased Threats Due to Expedient Assessments (Why replay
abuse has a HIGH impact)
Edge cases in SPF might reveal obscure problems with DNS!
DKIM remains prone to attack as does SPF which provides an ideal
vehicle. There is no sanctuary found relying upon SPF for protection
which can target 100 DNS transactions for each domain-name evaluated
at each location where an evaluation occurs. There is a possible
solution verifying the HELO and using forward reference PTR lists to
associate the DKIM signature with the HELO. Verifying the HELO and
delayed acceptance can defeat most attack scenarios. There is
nothing in the threat view that provides a concept how DKIM is to be
defended. It seems there should be a more holistic view of security.
4) Risks of Confusion Using Sub-domains
Users are confused by things they don't understand!
Trust can not be established using sub-domains. Not all email from a
domain should be trusted, even when it is signed. The signing domain
can greatly improve upon trust by marking which keys are for
trustworthy sources within their domain. Yahoo.com signatures, in
general, should not receive any assurances. A special case can be
made when special keys are used. Admin(_at_)yahoo(_dot_)com when used with a
special key could be qualified as trustworthy, for example.
5) Preventing Spoofs from Untrusted Sources (Signing roles needed)
Bad MUA design is bad!
When not all signed messages are to be considered trustworthy,
sorting through the remainder will involve a user interface. The
number of prompts needed to administer trust locally must be
minimized or security is diminished. Signing Roles improves the MUA
interface for administrating local trust.
-Doug
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html