On Sat, 2006-09-09 at 21:27 -0400, Scott Kitterman wrote: > On Saturday 09 September 2006 19:16, Wietse Venema wrote: > > Hector Santos: > > > Just so you know, no one, atleast not me, has said that SSP or DKIM-BASE > > > itself will protect against near-domain style spoofing A.K.A phishing. > > > > Actually, the discussion has demonstrated that SSP can't detect > > look-alike phishing, while DKIM-BASE can. > > Not without getting beyond the scope of the WG charter. DKIM-BASE > certainly gives a more reliable name basis for name based reputation > and accept/reject decisions. It does not, however, provide a complete > mechanism for doing so on it's own.
,--- | The DKIM working group will produce standards-track specifications | that allow a domain to take responsibility, using digital signatures, | for having taken part in the transmission of an email message and to | publish "policy" information about how it applies those signatures. | Taken together, these will assist receiving domains in detecting (or | ruling out) certain forms of spoofing as it pertains to the signing | domain. '__ Providing policy information to associate email-addresses with a signing domain for the purpose of ruling out spoofing seems well within the DKIM WG charter. > Another question I would have is how a message from a sender on the > trusted list that was received without a valid signature would be > treated. Without SSP to determine is the domain signs all mail, it > would seem problematic to either accept or reject such messages. It > may be that SKIM-SSP would complement such efforts. When using an annotation approach, validated email-address are normally annotated based upon an association with a list or retained email-addresses. Messages that are not signed or assured valid in some manner do not receive annotations. The recipient may still have phishing attempts appear in their inbox, but they are easily distinguished by lacking the expected annotation. While the details of this annotation scheme are beyond the scope of the WG, the critical aspect is just the normal association and assurances offered by DKIM. This information is leveraged by these external schemes into offer substantial protections. > > This involves a list of trusted DKIM-BASE signing domains (*). > > Given this list, potential look-alike or exact-name phishing attempts > > stand out because their signing domain isn't in the trusted list. > > Agreed, but this list is outside the scope of what I understand the WG was > chartered to do. Focus only upon offering validated email-addresses and how policy can extend this capability of DKIM. DKIM already can associate a valid email-address with that of the signature through the i= syntax and the d= domain. Policy can extend associations to broaden the coverage being offered. Ignore details related to email-address retention and annotation. One only needs to assume that such annotation is possible at this point. > > That list could be recipient maintained (a bit like the way SSH > > asks for permission when it encounters an unknown hostkey). Or it > > could be maintained externally. > > > > I think that a list of trusted DKIM-BASE signing domains can go a > > long way towards the elimination of look-alike and exact-name > > forgeries. > > Agreed, but that requires additional mechanism beyond what we are > chartered to do. I'd be interested to know if someone was working on > an open solution to this part of the problem. There is ongoing work. Is there interest in a different WG to cover this effort? I suspect most will see this as being too soon. -Doug _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
