[ietf-dkim] Re: t=y

My points are clear:

- A testing attribute should used for Migration ideas, by it its very 
natural definition, a testing attribute is limited in scope and time.
- Not having any guidelines on how VERIFIERS will deal with perpetual 
failures, especially those with a testing attribute, is a problem.
I don't see why this is not understood. It should be a no brainer, and 
quite frankly, I am a bit tired repeating something that been stated 
numeruous times for the past 2-3 years.  I will not get into any length 
discussion over something the spec authors are having a hard time seeing.
If DKIM is all about "responsibility" and "domain reputation", a testing 
attribute should NOT add to its possible harm.
Therefore, its going to be ignored just like in other similar ideas with 
testing attributs, or the worst case is that it will exploited and used 
to reject mail.
I guess if a DOMAIN addres t=y, then it really doesn't care what is the 
deposition of the message.  After all, its only a test.
My recommendation is basically spell out that no one should depend on it 
and that no one should use it over extended periods.
Finally, yes, I agree, it does have some reporting ideas behind it, but 
it still a LIMITED IN TIME concept.   It can't be a persistent t=y 
issue.  One day, CISCO.COM will have to remove its t=y attribute from 
its policy.
Thats all.  It really isn't that hard.

--
HLS



Jim Fenton wrote:
> Hector Santos wrote:
> > Murray S. Kucherawy wrote:
> >
> > > 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.
> I'm a little confused about whether you're talking about t=y in the key
> record or in the SSP record, so let's discuss both.
>
> t=y in the key record is of dubious value if verifiers adhere to the
> principle that DKIM failures are equivalent to non-existent signatures. 
> Since a broken signature shouldn't cause a message to be rejected or
> otherwise penalized, there isn't any reason to warn verifiers that
> you're testing.
>
> t=y in the SSP record is perhaps unnecessary, since there isn't much
> possibility of a failure in publishing an SSP record that would require
> much, if any, testing.
>
> However, t=y might be more useful if it's associated with reporting
> failure to some reporting address that might be specified by the
> signer.  You could collect failure reports without actually causing
> (particularly SSP) to take effect.  I believe that Murray may be on the
> verge of proposing just such a mechanism.
>
> If your point is that publishing t=y provides no security over not using
> DKIM or SSP at all, I agree.
>
> -Jim

--
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