ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] Re: New Issue: 4.2 needs new Attack Item: InconsistentSignature vs Policy Attacks

2006-02-02 17:33:34

On Feb 2, 2006, at 6:59 AM, Hector Santos wrote:

As with DKIM the only real exploit is a PASS from a white-listed source.

The issue of PASS is true. Why should we trust it?

DKIM is about restoring trust for transactional emails. A domain should be assumed untrusted until otherwise vetted as trustworthy. When the signature is verified, the white-listed source is being trusted. However, white-listing a signing domain may include both trustworthy and untrusted users or signing applications. There should be a means where the signing-domain is able to offer guidance with respect to which internal sources are trustworthy and which are not. After all, a single signed message can be replicated widely and wreck havoc. Such havoc may impact the domain's trusted status.


But we don't have must more we can do here but to apply or augment optional and non-standard tracking concepts.

A bit in the key verifying the message's signature can note whether the specific internal source for the message is considered trustworthy. Such an assertion could help sort out trusted and non- trusted messages. The signing domain would be motivated to protect their own trustworthy status and ensure messages obtaining a "trusted" status are indeed from trustworthy sources. It is important to minimize the amount of "trusted" abuse allowed to slip through. This concern would be due to evaluation costs, as this would be based upon message content. :-(


However, what you want to make sure you don't allow fall thru the cracks are the mix policy and protocol inconsistencies, and that might include mixing DKIM with other methods as well at the implementation level. But at the very least, the protocol level.

Just one small aspect of a violation of trust would be an "inappropriate" use of header fields. Even this apparent inappropriate use of a header field would depend upon the role of the signing-domain and whether the signing domain is also asserting the message to be trustworthy. For a typical list-server, none of the list's messages should be marked as trustworthy. Perhaps messages from the list's administrator could be marked as trustworthy, in which case headers will likely not be an issue.

DKIM is independent of the message envelope. This independence means that DKIM can _not_ be used to abate spam. Third-party signing policies will likely play little, if any, role in evaluating a violation of trust. When the signing-domain is trustworthy (third- party or not) and indicates the message can be trusted, the email- address that appears in the header will likely be of little concern, unless or until there is a report of a violation of trust. Those domains considered trustworthy should also held accountable for any criminal acts that they both sign and _mark_ as trustworthy.

Not marking the message trustworthy should mean the message is simply treated as not signed, irrespective as to whether the domain itself is trustworthy.

-Doug

_______________________________________________
ietf-dkim mailing list
http://dkim.org