Murray S. Kucherawy wrote:
On Thu, 8 Nov 2007, Hector Santos wrote:
It is clearly a threat entry point allowing anyone to try to create a
DKIM signature and all they have to do is add t=y with the hope the
receiver will ignore all fail validations.
There was no discussion on this point.
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?
The SSP specs says to ignore the failed validation.
The bad guys will use this with the HOPE they can get one foot in the
door, in fact, verifiers might not even TRY to validate at all because a
t=y will trigger a "SKIP DKIM" concept.
There are few things were:
First, a t=y success should be ignored just like a t=y failure is
ignored. If a success has value, so does a failure.
Second, based on SPF experience, since day one I have outlined on
numerous occassions how this is being ignored by some SPF
implementation, and
Third, it should come with an expiration period concept.
At the very least, and this was suggested as well, any semantic about
t=y should come that the VERIFIER has the ultimate decision on how to
handle t=y. Saying it should be IGNORED, well, that definition will be
IGNORED itself. The statements should also include semantics about
limiting this usage to migration periods and should not permanently be
in place.
Finally, in the now expired DSAP proposal,
http://www.isdg.net/public/ietf/drafts/draft-santos-dkim-dsap-00.html
This is what we had for t=y:
4.7. DSAP Tag: t=y
The t=y tag is optional. If defined, the domain is currently testing
DKIM. Verifiers SHOULD NOT treat testers any different from
production mode signers. It SHOULD NOT be used as a way to bypass a
failed signature classification policies. However, verifiers SHOULD
track testers for over extended usage of test signatures and MAY
consider using the results to provide feedback to the domain.
--
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