ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] DKIM Interoperability Event notes

2007-11-08 17:03:15
Murray S. Kucherawy wrote:
On Thu, 8 Nov 2007, Hector Santos wrote:
How can an attacker add t=y to a signature? That only exists in keys and policies.

They can make themselves look like cisco.com or any other HV domain and with the obvious failure and t=y, how will verifiers react to this?

What you originally said was "all they have to do is add t=y". I assume you mean "they" is "the attackers". How would an attacker add "t=y" to a policy record and then take advantage of it?

The rest of your points about the exposure "t=y" in a published SSP record may be valid, but I remain confused about this point and it seems to be the premise of your attack.

Attackers will be able to create a FAILED fascimile of a primary domain DKIM complete message and as long as the primary has a t=y policy, the attackers need not worry about HASH PERFECTION - it just randomly creates a signature with a junk hash because the t=y will promote a IGNORE FAILURE concept.

If the valid GOOD GUY PRIMARY, like CISCO.COM continues to use t=y over extended periods, all you are doing is PROMOTING SUSPICION and BAD REPUTATION especially if the signatures perpertually fail to validate for some reason or another.

Systems will quickly learn not to tolerate this persistent failure with t=y.

There will be 3 type of attacks:

1 - Those who are ignorant of DKIM and unintentionally forged DKIM domains. This is the legacy attackers.

2 - Those who will become VALID DKIM implementators.

3 - Those whole will try to FORGE DKIM in some way or another, especially by using t=y.

Since day one, it has been my interest in DKIM/SSP to first address #1 and #3. Can't do anything with #2 without additional reputation layers.

But the obvious must be addressed.  t=y is obvious.

--
Sincerely

Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com


_______________________________________________
NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html