Subject: [ietf-dkim] DKIM Interoperability Event notes

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 8 Nov 2007 13:45:38 -0800 (PST)

At the DKIM Interoperability Event in Dallas a couple of weeks ago I was 
nominated as scribe during the discussions among the participants about 
what parts of RFC4871 people found troublesome.  This is the distillation 
of those notes.  They should be considered for possible inclusion in a 
future "DKIM Errata" draft, if any.

1. "s=" in key records: There is no explicit guidance about what to do 
with clearly bogus values.  Examples given:

 	s=*:email
 	s=foo:email:bar

The normative text covering "s=" doesn't say what to do if one of the 
colon-separated words is a word not enumerated in the "currently defined 
service types".  It also doesn't specify what to do with absurd values 
like the first example.  The consensus is to ignore any colon-separated 
value not recognized and only pay attention to "*" and "email" for DKIM 
e-mail implementations.

2. Empty bodies: Although the "simple" body canonicalization says 
precisely what to do in the case of an empty message body, "relaxed" does 
not.  The consensus is that the "relaxed" body canonicalization of the 
null body is the null input, but it was conspicuous that "simple" was 
explicit while "relaxed" was not.

3. Multiple replies to TXT records: RFC4871 defines the handling of such 
cases as "undefined", but it still came up in conversation several times. 
Also noteworthy is that SSP has not yet added any discussion on this 
topic.

4. Empty local parts can be problematic: RFC4871 discusses the "g=" (key) 
vs. "i=" (signature) comparison including the default for the local-part 
to be used when "i=" is undefined, but it's possible a signer could 
explicitly say "i=@example.com" and there's no way for "g=" to match that 
other than using a wildcard (or the default).

5. "x=" must be compared to a local time base instead of to "t=": I'm not 
remembering the context about why I was asked to include this, so maybe 
someone can refresh my memory here.

6. "h=" (key) vs. "a=" (signature): One participant felt the requirement 
to corellate these two values was not sufficiently normative.

7. There is insufficient guidance about whether the domain in "i=" or the 
domain in "d=" should be used when generating a domain reputation query 
based on a DKIM signature verification.  At the end of this discussion, 
participants were asked to think about this and try to generate language 
for inclusion in later specifications to provide such guidance.

--
Murray S. Kucherawy ========================================= [email-masked]
Principal Engineer           Sendmail, Inc.                Emeryville, CA, USA
(510) 594-5400                                         http://www.sendmail.com
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Hector Santos <[email-masked]>
Date: Thu, 08 Nov 2007 17:00:16 -0500

Anything regarding t=y?

Based on SPF where this idea was borrowed from, it is basically a 100% 
ignored option.

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.

--
HLS

Murray S. Kucherawy wrote:
> what parts of RFC4871 people found troublesome.  This is the 
> distillation of those notes.  They should be considered for possible 
> inclusion in a future "DKIM Errata" draft, if any.
> 
> precisely what to do in the case of an empty message body, "relaxed" 
> does not.  The consensus is that the "relaxed" body canonicalization of 
> the null body is the null input, but it was conspicuous that "simple" 
> was explicit while "relaxed" was not.
> 
> cases as "undefined", but it still came up in conversation several 
> times. Also noteworthy is that SSP has not yet added any discussion on 
> this topic.
> 
> 4. Empty local parts can be problematic: RFC4871 discusses the "g=" 
> (key) vs. "i=" (signature) comparison including the default for the 
> local-part to be used when "i=" is undefined, but it's possible a signer 
> could explicitly say "i=@example.com" and there's no way for "g=" to 
> match that other than using a wildcard (or the default).
> 
> 5. "x=" must be compared to a local time base instead of to "t=": I'm 
> not remembering the context about why I was asked to include this, so 
> maybe someone can refresh my memory here.
> 
> 7. There is insufficient guidance about whether the domain in "i=" or 
> the domain in "d=" should be used when generating a domain reputation 
> query based on a DKIM signature verification.  At the end of this 
> discussion, participants were asked to think about this and try to 
> generate language for inclusion in later specifications to provide such 
> guidance.
> 
> -- 

-- 
Sincerely

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

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 8 Nov 2007 14:19:44 -0800 (PST)

> 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.
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Hector Santos <[email-masked]>
Date: Thu, 08 Nov 2007 18:36:02 -0500

Murray S. Kucherawy 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?

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.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 8 Nov 2007 15:41:52 -0800 (PST)

> 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.
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Hector Santos <[email-masked]>
Date: Thu, 08 Nov 2007 18:58:02 -0500

Murray S. Kucherawy wrote:
>> 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?
> 
> 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

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 8 Nov 2007 16:04:30 -0800 (PST)

> creates a signature with a junk hash because the t=y will promote a 

OK so in fact the complaint is "t=y is dangerous", not "a hacker could 
insert t=y into someone's policy" (which is what you originally said). 
There are other people here who can debate that as well as or better than 
I so I'll yield.

In sticking to the Subject: of this thread, no, this was not discussed at 
the Interop event.  SSP was determined early on to be out-of-scope for our 
tests.  We were focusing only on RFC4871 itself.

It was felt, though, that SSP might be the subject of a future Interop 
event once the draft has become an RFC (or, perhaps, multiple proposals 
are available).
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Hector Santos <[email-masked]>
Date: Thu, 08 Nov 2007 19:26:15 -0500

Murray S. Kucherawy wrote:
>> 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.
> 
> There are other people here who can debate that as well as or better 
> than I so I'll yield.

Ok, I didn't say insert, but I can see how it was read.  I stated:

   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.

I should of been clear of saying "exploited domains who added t=y into 
their policy":

   ... and all they have to do is find a DOMAIN with a t=y policy...

> In sticking to the Subject: of this thread, no, this was not discussed 
> at the Interop event.  SSP was determined early on to be out-of-scope 
> for our tests.  We were focusing only on RFC4871 itself.

How unfortunate.

> event once the draft has become an RFC (or, perhaps, multiple proposals 

Its unfortunate that SSP continues to be play 2nd fiddle when in fact, 
in my mind, DKIM is worthless (offers little payoff) without a POLICY 
concept.  I won't recommend DKIM until SSP is part of the fundamental 
picture.

Anyway, I won't go there.  I just hope the t=y comments are not ignored.

Thanks for your own comments.

-- 
Sincerely

Hector Santos, CTO

---

From: Jim Fenton <[email-masked]>
Date: Thu, 08 Nov 2007 16:27:25 -0800

Hector Santos wrote:
>> record may be valid, but I remain confused about this point and it
>> seems to be the premise of your attack.
>

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

---

From: "Frank Ellermann" <[email-masked]>
Date: Fri, 9 Nov 2007 01:33:02 +0100

Hector Santos wrote:

> based on SPF experience, since day one I have outlined on 
> implementation

If you're talking about SOFTFAIL I wonder what "ignored by
some SPF implementation" means, does the code return FAIL
or NEUTRAL instead of SOFTFAIL ?  Or are you talking about
receivers interpreting SOFTFAIL like FAIL or NEUTRAL ?  

RFC 4408 recommends a kind of "greylisting" for a SOFTFAIL,
or flagging / scoring the mail as suspicious.  If some SPF
implementation "ignores" SOFTFAIL by returning a different
result like NONE, TEMPERROR, NEUTRAIL, FAIL, or what else,
it's broken.  

If a receiver treats SOFTFAIL like another result it's ok.,
his server, his rules, "receiver policy".

A publisher using SOFTFAIL over a long time will find that
"interpreting SOFTFAIL as suspicious" actually means that
SOFTFAILing mails could vanish in the black holes of "spam
folders".  It's dangerous to use SOFTFAIL over long periods
of time, the likely behaviour of mail receivers is hard to 
predict for a SOFTFAIL, unlike FAIL.  What Ebay and Paypal
do is wrong, no doubt about it.

 Frank (certainly no SOFTFAIL fan)

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 8 Nov 2007 16:38:08 -0800 (PST)

>> tests.  We were focusing only on RFC4871 itself.

I disagree.  Nobody at the event said SSP was unimportant.  But, one thing 
at a time; we were only there to evaluate that piece of the protocol that 
was already issued by the IETF.  SSP is still nascent, so discussing it 
there (rather than at IETF or on this list) seemed like an inappropriate 
use of our limited time.
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Hector Santos <[email-masked]>
Date: Thu, 08 Nov 2007 19:45:09 -0500

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

-- 
Sincerely

Hector Santos, CTO

---

From: Hector Santos <[email-masked]>
Date: Thu, 08 Nov 2007 19:54:11 -0500

Hi Frank,

Well SOFTFAIL has similar implementation issues. But I was specifically 
talking the similar t=y "I am in testing mode, so IGNORE any possible 
failure" mechanism for DKIM/SSP.

Our implementation ignored its in SPF, and if we implement DKIM/SSP, it 
will be ignore there too.

The DKIM/SSPEC authors seem to take these real world concerns very 
lightly, especially if you not within the "inner circle."  So I will 
just watch with optimism that sound engineering will eventually prevail. 
  It usually does.  If not, well, DKIM is not the first worthless 
protocol "thrown into the waste basket with full force." :-)

--
HLS

-- 
Sincerely

Hector Santos, CTO

---

From: SM <[email-masked]>
Date: Thu, 08 Nov 2007 21:23:23 -0800

Hi Hector,
At 16:45 08-11-2007, Hector Santos wrote:
>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.

Yes.  But it's not up to the specifications to define the scope and time.

>- Not having any guidelines on how VERIFIERS will deal with 
>perpetual failures, especially those with a testing attribute, is a problem.

Consider the message as unsigned.

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

"t=y" means that the domain is testing DKIM.  Some domains can run a 
test in a few days and reach a conclusion while others may require 
in-depth testing.  The sender do care about the disposition of the 
message, hence the test.

Regards,
-sm

---

From: "Charles Lindsey" <[email-masked]>
Date: Fri, 09 Nov 2007 11:36:49 -0000

> t=y will trigger a "SKIP DKIM" concept.

Surely, t=y will be used in one of two scenarios:

1. Someone is intending to roll out DKIM, and is trying it out. He is not  
sure whether he has implemented it right, so it may fail.

But in that case there will be no SSP record, or if there is one it will  
say "we do not sign (yet)".

2. An existing DKIM user is rolling out a new algorithm. As before, he may  
get it wrong and the signatures may fail.

BUT, if (as is likely) his SSP says "we sign everything", then he MUST  
continue to sign with his old algorithm, in addition to the new one which  
has "t=y" in it.

With those two provisos, the existing rule, to ignore any failed t=y  
signature (as though there had been no signature) makes perfectly good  
sense.

And, answering another point that was made, it may make good sense to  
report back to the signer on t=y signatures that failed, so that he can  
fix his bug. A t=y user can reasonably expect to receive such reports.  
OTOH, without a t=y attempts to regularly report failures would amount to  
harassment, and are a Bad Thing.

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131                       
   Web: http://www.cs.man.ac.uk/~chl
Email: [email-masked]      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Hector Santos <[email-masked]>
Date: Fri, 09 Nov 2007 07:35:13 -0500

> Yes.  But it's not up to the specifications to define the scope

It can be open-ended without specifics. The point is, domain risk harm 
to themselves if they think t=y is going to be marginally viewed, There 
is high potential for abuse. Extremely easy to do and Murphy's Law says.....

 >> I guess if a DOMAIN adds t=y, then it really doesn't care what is

There you go, you have some form of inherent scope and time.

Personally, I think systems with DKIM today are using it to mean "We are 
in BETA mode!" because they had the t=y for years now.  Which is fine, 
but RFC4871 is official now.  No one should expect it to be *PERPETUAL* 
fail-safe concept and once, if ever, we get into full production with 
wider adoption, I don't think it is will be tolerated, again, and I 
repeat, especially when it *perpetually* fails.

I don't think I can avoid adding logic for a time table for domains with 
t=y vs the # of failures.   Domains with a high failure t=y rate will be 
pre-empted, trigging a skip process and a "unsigned status."  If it 
continues, the domain will be blocked, and reported to RBL sites - 
DOMAIN REPUTATION IS HARM UNBENOWST TO THE DOMAIN.

Keep in mind that systems like SPAM ASSASSIN will be taught to watch for 
such t=y marking.  A verifier might just record all this and this weight 
to the SA heuristics.

In a production environment, it only makes sense for the good primary 
domain to perform their test quickly and remove that attribute as soon 
as possible.

-- 
Sincerely

Hector Santos, CTO

---

From: Hector Santos <[email-masked]>
Date: Fri, 09 Nov 2007 08:29:02 -0500

Charles Lindsey wrote:

> 1. Someone is intending to roll out DKIM, and is trying it out. He is 
> not sure whether he has implemented it right, so it may fail.
> 
> 2. An existing DKIM user is rolling out a new algorithm. As before, he 
> may get it wrong and the signatures may fail.

That might be GOOD GUY scenarios.  How about the EXPLOITED scenarios?

> signature (as though there had been no signature) makes perfectly good 

hahahahahaha. :-)  Sorry. I just don't see how its not seen that what 
you think is GOOD can also be BAD. :-)

> OTOH, without a t=y attempts to regularly report failures would amount 
> to harassment, and are a Bad Thing.

Thats a different issue, but it highlights even further why something 
like t=y should not be taken lightly.

What is to stop someone, for the sake of example, take cisco.com, and 
create a forged messages complete all the DKIM markings, and does so in 
an highly efficient manner by wasting no time in creating or trying to 
create a fake hash, and just create a fast random junk hash and blast 
the world with spam and/or malicious eViruses?

Is this not familiar today with/without DKIM?

If DKIM/SSP is suppose to help some DOMAINS here, then it is important 
that t=y is not abused and/or forgotten. For the SAKE of the domain own 
reputation, it is in its ADVANTAGE and BEST INTEREST that it is removed 
as soon as possible.  Never mind the "GOOD GUY" usage, it is the BAD GUY 
exploitation I am worry about.

I don't want to waste alot of time adding DKIM/SSP to our own outgoing 
mail, only to have exploiters FORGE our mail because we have a t=y. 
Once we remove the t=y, I expect to be protected when this FORGED mail 
hits DKIM/SSP compliant sites.  By keeping in there, I am not doing 
myself a favorite.  I would think all HV domains would agree that the 
expense in adding DKIM requires that they don't reduce their investment 
by exposing t=y for any prolonged period.

All I ask is for better clarification on this t=y and to highlight its 
danger and should be used with extreme limits in scope and time.

-- 
Sincerely

Hector Santos, CTO

---

From: Steve Atkins <[email-masked]>
Date: Fri, 9 Nov 2007 05:45:30 -0800

On Nov 9, 2007, at 5:29 AM, Hector Santos wrote:

>> 1. Someone is intending to roll out DKIM, and is trying it out. He  
>> is not sure whether he has implemented it right, so it may fail.
>> But in that case there will be no SSP record, or if there is one  
>> it will say "we do not sign (yet)".
>> 2. An existing DKIM user is rolling out a new algorithm. As  
>> before, he may get it wrong and the signatures may fail.
>
>> With those two provisos, the existing rule, to ignore any failed  
>> t=y signature (as though there had been no signature) makes  
>> perfectly good sense.
>
> hahahahahaha. :-)  Sorry. I just don't see how its not seen that  
> what you think is GOOD can also be BAD. :-)

That you do not understand that a DKIM message only has two states -  
validly signed or not signed - and continue to use that ignorance to  
waste time in this forum isn't a laughing matter.

Please behave professionally and constructively or be quiet and let  
others work.

Cheers,
   Steve

---

From: Hector Santos <[email-masked]>
Date: Fri, 09 Nov 2007 09:01:07 -0500

Steve Atkins wrote:
>>> But in that case there will be no SSP record, or if there is one it 
>>> will say "we do not sign (yet)".
>>> 2. An existing DKIM user is rolling out a new algorithm. As before, 
>>> he may get it wrong and the signatures may fail.
>>
>>> signature (as though there had been no signature) makes perfectly 
>>> good sense.
>>

I think I have been extremely professional and constructive.  Whether 
you choose and others CHOOSE to ignore that input is another matter all 
together.

I think the CONCERNS are very VITAL in the discussions about DKIM 
implementation and SSP.

It is WELL understood DKIM has two states.  The FAILED t=y STATE is a 
PROBLEM under a PERPETUAL USAGE MODE.

Why is that NOT a valid concern and why do you choose to IGNORE it?

-- 
Sincerely

Hector Santos, CTO

---

From: SM <[email-masked]>
Date: Fri, 09 Nov 2007 07:18:06 -0800

At 04:35 09-11-2007, Hector Santos wrote:
>I don't think I can avoid adding logic for a time table for domains 
>with t=y vs the # of failures.   Domains with a high failure t=y 
>rate will be pre-empted, trigging a skip process and a "unsigned 
>status."  If it continues, the domain will be blocked, and reported 
>to RBL sites - DOMAIN REPUTATION IS HARM UNBENOWST TO THE DOMAIN.

People are already evaluating domain reputation, with or without 
DKIM.  I don't see how removing "t=y" would change that.

>Keep in mind that systems like SPAM ASSASSIN will be taught to watch 
>for such t=y marking.  A verifier might just record all this and 
>this weight to the SA heuristics.

Yes, some people may do that.  It's like assigning a negative spam 
score to a message based on whether the DKIM signature verifies.

>In a production environment, it only makes sense for the good 
>primary domain to perform their test quickly and remove that 
>attribute as soon as possible.

The message about the DKIM Interoperability event shows that even 
after DKIM has been published as a RFC, there may still be some 
"bugs".  Some can be identified during interoperability testing while 
others may only be noticeable in a production environment.  It makes 
sense for a domain to remove that attribute only when they are 
comfortable that their implementation is working correctly.

Regards,
-sm

---

From: <[email-masked]>
Date: Fri, 9 Nov 2007 10:34:36 -0500

A better question is how many domains will move signing into production
without the testing flag, then fix the inevitable issues.

Bill Oxley
Messaging Engineer
Cox Communications
404-847-6397

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of SM
Sent: Friday, November 09, 2007 10:18 AM
To: [email-masked]
Subject: Re: [ietf-dkim] Re: t=y

Regards,
-sm

---

From: Dave Crocker <[email-masked]>
Date: Fri, 09 Nov 2007 09:46:55 -0600

> without the testing flag, then fix the inevitable issues.

Given that most protocols do not have a 'testing' flag -- and they manage to 
move into production quite nicely -- a different question might be why such a 
flag is needed...

d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Steve Atkins <[email-masked]>
Date: Fri, 9 Nov 2007 07:52:58 -0800

On Nov 9, 2007, at 7:46 AM, Dave Crocker wrote:

> Given that most protocols do not have a 'testing' flag -- and they  
> manage to move into production quite nicely -- a different question  
> might be why such a flag is needed...

Particularly as the failure mode of DKIM is simply to treat the  
message as unsigned - so DKIM failures will not, in any competently  
configured system, affect SMTP interoperability adversely.

Cheers,
   Steve

---

From: Hector Santos <[email-masked]>
Date: Fri, 09 Nov 2007 10:54:40 -0500

SM wrote:
>> with t=y vs the # of failures.   Domains with a high failure t=y rate 
>> will be pre-empted, trigging a skip process and a "unsigned status."  
>> If it continues, the domain will be blocked, and reported to RBL sites 
>> - DOMAIN REPUTATION IS HARM UNBENOWST TO THE DOMAIN.
> 
> People are already evaluating domain reputation, with or without DKIM.  

Of course, one might have a:

Non DKIM/SSP transactions:

    POSITIVE REPUTATION --> OK
    UNKNOWN REPUTATION  --> Indeterminate

DKIM/SSP failed t=y transactions

    POSITIVE REPUTATION --> OK? REJECT? BY REQUEST?
    UNKNOWN REPUTATION  --> Indeterminate? REJECT? BY REQUEST?

But in the real world, I am not aware of any open standard widely 
adopted Positive Reputation system in place. Negative Reputation, scores 
of DNS RBL sites.  Using the negative reputation:

DKIM/SSP failed t=y transactions

    NEGATIVE REPUTATION --> REJECT
    UNKNOWN REPUTATION  --> Indeterminate? REJECT? BY REQUEST?

So the verifier is left in limbo when there is unknown reputation, 
negative or positive.

The point is that with wide adoption, a failed t=y, the odds are very 
high there would be NO reputation to access leaving the verifier 
continued abuse if t=y is honored.  So lacking reputation or any other 
layer specification, a perpetual encounter of failed t=y transactions is 
not going to be ignored because by doing so, you are putting the 
verifier, the primary domain and ultimately the end-users in harm.

One question is why would a DKIM domain testing his implementation have 
a perpetual failure?  That would not be the expectation.

> I don't see how removing "t=y" would change that.

Well, to be clear, I wasn't proposing to remove or eliminate this 
option.  But that its definition be better fined tuned to real world 
possibilities.

> The message about the DKIM Interoperability event shows that even after 
> DKIM has been published as a RFC, there may still be some "bugs".  Some 
> can be identified during interoperability testing while others may only 
> be noticeable in a production environment.  It makes sense for a domain 
> to remove that attribute only when they are comfortable that their 
> implementation is working correctly.

Agreed.

Thanks SM. I appreciate your comments.

-- 
Sincerely

Hector Santos, CTO

---

From: Hector Santos <[email-masked]>
Date: Fri, 09 Nov 2007 11:09:16 -0500

> might be why such a flag is needed...

Good question Dave.

My input that is ok to have it but only as a "advertise" that the domain 
is testing for possibly for logging or reporting.

My recommendation is that the verifier should continue to treat the DKIM 
transaction following the other DKIM/SSP recommendations.  Essentially, 
the verifier SHOULD ignore t=y for any kind of decision making process. 
It should not become FAIL-SAFE option without limits.

I think the exception is some pre-arrange whitelisting concept or domain 
to domain arrangement where the verifier is well aware of the domain 
testing and will not negatively flag a failed t=y for this domain.

-- 
Sincerely

Hector Santos, CTO

---

From: Hector Santos <[email-masked]>
Date: Fri, 09 Nov 2007 11:21:19 -0500

Steve Atkins wrote:
> Particularly as the failure mode of DKIM is simply to treat the message 
> as unsigned - so DKIM failures will not, in any competently configured 
> system, affect SMTP interoperability adversely.

Competently?  Oh brother. Any who.

I disagree.

All AVS operations worth their salt, is all about learning the bad guy 
threats and once patterns are detected that the bad guy is bombarding 
DKIM compliant servers with high rate of FAILED t=y transactions, it 
will not be ignored.

Trust me. Although I am just one SMTP vendor like others here with a few 
decades of practical experience in every market segment, who doesn't 
need to guess at what will happen, without a shadow of a doubt, will add 
such logic. I am confident other SMTP systems and operators will see the 
light as well.  t=y will be ignored if not restricted.

Why are you so adversely against fine tuning the definition of the t=y 
option?  What harm is there highlighting these real world concerns?

-- 
Sincerely

Hector Santos, CTO

---

From: Mark Delany <[email-masked]>
Date: Fri, 9 Nov 2007 08:35:50 -0800

> might be why such a flag is needed...

Ayup. I never had a good rationale for it either. I originally put it  
into DK on the behest of others in spite of personal reservations.

Mark.

---

From: Michael Thomas <[email-masked]>
Date: Fri, 09 Nov 2007 08:46:50 -0800

> into DK on the behest of others in spite of personal reservations.

Maybe this would be good motivation to get to draft standard.

       Mike, who never understood either
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 9 Nov 2007 09:24:45 -0800 (PST)

> natural definition, a testing attribute is limited in scope and time.

We actually have to say that, i.e. define "testing", in an RFC?

> failures, especially those with a testing attribute, is a problem.

Why?

> I don't see why this is not understood.

Conversely, I don't see why you think it's obvious.

> testing attributs, or the worst case is that it will exploited and used 

How can one exploit a test mode which is already explicitly telling 
verifiers, "This may or may not work, don't trust the results"?

> deposition of the message.  After all, its only a test.

Precisely.

> and that no one should use it over extended periods.

See my first comment above.

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

I'd bet real money that they will.

> Thats all.  It really isn't that hard.

We certainly agree there.

-MSK

---

From: David Mayne <[email-masked]>
Date: Fri, 09 Nov 2007 09:52:21 -0800

> move into production quite nicely -- a different question might be why such a
Hrm, let's see - the SMTP protocol has EXPN, VRFY, and, well RSET - 
meaning I'm just kidding, reset the session and start over. POP3 has 
RSET too. What about ping, and traceroute, in a more general sense ?

SMTP didn't have an undo to the DATA command - so we couldn't just say 
OK, sorry, I just dumped this message on you, but was just testing out 
my DK implementation, please just ignore your verification results in 
the processing of the message.

In the earlier days of DK, one of the hurdles I had to convince our 
management it was a good idea to experiment with DK signing,  was how 
would receivers handle issues with our implementations, before we were 
convinced it was working - and we were a pretty large volume mailer at 
the time, who were concerned about customer churn over things like 
undelivered mail. Without this "grace" period of checking out our 
implementation, it would  have been a harder sell to the people in 
management above me as it was.

That said, perhaps at this point, having a test flag engraved in the 
protocol now may be a bit obsolete with a more mature SSP framework. I 
do fail to see the damage and dooom hat some are attributing to this 
test mode though, as receivers will act to their best interests anyway, 
no matter what the signers policy states...

David

---

From: Dave Crocker <[email-masked]>
Date: Fri, 09 Nov 2007 12:10:40 -0600

David Mayne wrote:
> Dave Crocker wrote:
>> 
>> Given that most protocols do not have a 'testing' flag -- and they manage
>> to move into production quite nicely -- a different question might be why
>>  such a flag is needed...
>> 
> Hrm, let's see - the SMTP protocol has EXPN, VRFY, and, well RSET - meaning
> I'm just kidding, reset the session and start over. POP3 has RSET too. What
> about ping, and traceroute, in a more general sense ?

Skipping over the humor, for the moment, these underscore that one can add 
features, albeit as options, without needing a 'testing' bit.  As for ping and 
traceroute, I don't understand.  Traceroute isn't really a hack.  It's a very 
creative re-application of an existing protocol mechanism.

> management it was a good idea to experiment with DK signing,  was how would
> receivers handle issues with our implementations,

And that's why I didn't say anything like "a test flag is a silly idea".  It 
isn't a silly idea.  It just turns out that for the Internet, there's not much 
history of needing the flag for functional purposes.  And adding a long-term 
protocol feature for short-term, political expedience seems like rather poor 
engineering (on at least two counts.)

d/

ps. This sub-thread is academic.  I'm not lobbying to change the protocol. 
Just re-issuing my query about whether anyone knows of such a feature being 
particularly helpful in any other Internet protocol.

-- 

   Dave Crocker

---

From: Hector Santos <[email-masked]>
Date: Fri, 09 Nov 2007 15:43:17 -0500

> no matter what the signers policy states...

I agree Mr. Mayne, but can we safely say this is true for the general 
network and wide adoption across millions of the smaller systems?

IF the specification says:

   y  The domain is testing signing practices, and the Verifier
      SHOULD NOT consider a message suspicious based on the record.

with no further engineering insights, then this opens the door to 
security threats if verifiers honor the currently written SHOULD NOT 
recommendation.

The threat is this:

Once DKIM signed messages are unleashed on the world en masse, attackers 
can take the DKIM headers of HV domains or any domains who have t=y 
policies, add their own content to the body and blast their spam, 
marketing or malicious mail.

They are not going to worry about the fact that the signature will be 
invalid because the t=y will promote the idea there is nothing 
suspicious about the message.

Yes, DKIM says "failure is to be views as unsigned" but SSP "Must sign 
all" policies also say unsigned means suspicion - failure.

SSP will override DKIM "Failure To Unsigned Status" promotion.

But the real problem is when the failure is perpetual, the verifier is 
seeing this over and over again from the same domain for extended periods.

-- 
Sincerely

Hector Santos, CTO