Subject: [ietf-dkim] New Issue: Analyzing Failures: List of Possible Reasons

From: "Hector Santos" <[email-masked]>
Date: Fri, 17 Mar 2006 14:27:16 -0500

Proposal:

I think section 6.5 is a good step but we need a section that is dedicated
to all the possible reasons for failures as we KNOW it to possibly to occur.
I think there should a special section:

    6.6 List of Possible Failures

This section would include a discussion on failures and prepare a list of
possible reasons, including probably summarize the set of standard error
response codes and/or labels for verifiers and or mail presentation software
to use.

  - Missing Public Key
  - Missing Header Information
  - Hashing Failure
       Which part?  Header or Body?
  - Signature has Expired
  - Subject Mismatch
  - Policy Conflict (SSP related)

etc.

Background:

One of the concerns I see that is going to occur is a huge expense in
support in answering customers questions as to why this or that message
failed or has a warning tag or lacks having a "GOOD DKIM SEAL" tag when it
should have one, etc, which ever way the verifier and/or reader wishes to
present this stuff.

As we consider adding DKIM signing,  I can see the issues when the target
final destinations verifiers and/or readers start to see non-GOOD messages.
There is going to be a lot of questions coming our way to explain why.  We
need to be prepare to answer them.

First I expect the support questions:

  "We turned this on and now YAHOO/AOL is saying our messages
   are bad. Is it me or your software?"

  "We began to charge a few our customers for domain signing,
   and they are saying there customers are getting bad messages..
   What's going on?"

and then worst - finger pointing and passing the support buck:

  "According to XYZ, you are not signing right..."

  "Maybe your software is changing text...."

and I am sure more questions in this vain, and then I expect even more
"passing of the
buck" finger pointing excuses:

   "Well, somewhere the message was broken in the route."

   "Maybe it is really bad?"

   "Maybe the verifier is broken?"

In any case, what is really missing from DKIM is the "reasons" for failure
that verifiers can use to help alleviate these support issues.

I predict there is going to be a lot of chaos in this area, especially when
the "two-tier" divide begins due to the bigger concentrating in sniffing out
the good out the big haystack of the bad or even bigger haystack of non-DKIM
messages.

What bothers me greatly is that I foresee the era when the BAD, by a far
majority, outweighs the GOOD to the extent that it has a "Cry Wolf" effect
and people simply just start ignoring all the bad markings or "lack of good
markings" messages.

In some respect, I can see why some would want to "hide" failures, so that
there would be less "explanations" for the failures. But IMO, if there is
going to be an increase of "bad messages" with DKIM markings, I think it
would be better to help verifiers support operations to increase the
confidence of the system.   By promoting the idea that these bad messages
should be viewed as "No Signatures" messages,  I can't help but seeing a
"cry wolf" syndrome to occur.  We already see this now with mangled listed
mail.  We accept them - even with broken DKIM/DKEY signatures.

--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com

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

---

From: <[email-masked]>
Date: Sat, 18 Mar 2006 10:21:37 -0500

-----Original Message-----
From: Oxley, Bill (CCI-Atlanta)
Sent: Fri 3/17/2006 3:39 PM
To: 'Hector Santos'
Subject: RE: [ietf-dkim] New Issue: Analyzing Failures: List of Possible Reasons
 
Your support idea is sound although I disagree on what DKIM is actually going to do. However those issues should not be a part of a policy document but rather an appendix or FAQ

Something along the lines of

Unsigned Message is received from publisher who claims to sign all
Treat as unsigned message

Signed message is received but decodes invalidly
Treat as unsigned message

Published dkim record indicates a 1025 hash but signature is 512
Treat as unsigned message

Hmm, I'm starting to see a pattern here :-)

Bill Oxley 
Messaging Engineer 
Cox Communications, Inc. 
Alpharetta GA 
404-847-6397 
[email-masked] 

-----Original Message-----
From: Hector Santos [mailto:[email-masked]] 
Sent: Friday, March 17, 2006 3:10 PM
To: Oxley, Bill (CCI-Atlanta); [email-masked]
Subject: Re: [ietf-dkim] New Issue: Analyzing Failures: List of Possible Reasons

----- Original Message -----
From: <[email-masked]>
To: <[email-masked]>; <[email-masked]>
Sent: Friday, March 17, 2006 2:36 PM
Subject: RE: [ietf-dkim] New Issue: Analyzing Failures: List of Possible
Reasons

> I don't think that user recipients are going to see
> dkim anything unless they are used to viewing their headers.
> A dkim failure is just an identification failure, not a
> stop delivery notice. All it means is that I cant clearly
> identify who sent me this.

Right, and we will get the quesitions, "why?"

> As an ISP I don't want anypart of the liability that comes
> into "this message is good" "that message is bad"

Well, unfortunately, if you add DKIM, you will be assuming liability whether
you agree with it or not.  It is a new level of responsibility, especially
for those who begin to put a cost associated with it.

Anyway, even if your TSO proclaims no liability, what are you going to do
with the support questions?  I was more concern with the obvous support
questions behind this.  Are we ready to proclaim DKIM is a "Plug and play -
No Support Required" protocol?   I don't think so.

> If I use a visible identifier software the message will say
> "software vendor BLA has declared this message safe".
> Any dkim failure or breakpoint is an unsigned message that
> the local retailer will process for the end user as local policy
> permits.

Right, but there will still be support questions and the odds are good that
your local policies will be molded based on the support issues.

> DKIM has never been a authentication service, just
> an identification service.

I don't agree with those semantics.  IMO, the fact is, you are
authenticating the identity of a domain by implementing DKIM processing.
That's is exactly what you are doing:

      Domain Identity Authentication via DNS DKIM records

Maybe you are saying it is not an authorization concept. If so, I agree
although there are dispensed semantics in the docs that suggest that a valid
identification promote authorization for acceptance.

In any case, the very fact there is there is no absolute, in the
technicality and/or the politics of DKIM,  there will be many support issues
for this very reason.  When you have people who are going to suffer the
consequences of increase abused DKIM messages, there is no doubt in my mind
there will be a higher scrutiny placed on the bad as well as the good.

All I am suggesting is to help the process by giving verifiers the "means"
to better identify the failures in a standard fashion so that there will
less support questions.

PS: To the "necessary folks", ignoring these concerns is in my view
negligent of the engineering process. Don't be surprise of the "future
critics" when the issues were pointed out now and you opted to ignore the
messenger now in attempt to promote negative consensus and avoid
highlighting the issue.  So if you are concern about the future critics, you
best to begin molding the answers now to the these concerns.

---

From: "Hector Santos" <[email-masked]>
Date: Sat, 18 Mar 2006 12:27:26 -0500

Thanks for going back on-list. <g>

----- Original Message -----
From: "Hector Santos" <[email-masked]>
To: <[email-masked]>
Sent: Friday, March 17, 2006 3:55 PM
Subject: Re: [ietf-dkim] New Issue: Analyzing Failures: List of Possible
Reasons

Why go off list Bill? :-)

In my view, you are a "necessary folk" too so post your thoughts
publicly. If you think it is FAQ material, then put it to a test
with others to see if they agree.

I personally think DKIM needs "reasons" for failures.  The
software is already doing it, it is just not put into "response
context."

I was expecting someone to say that this might be best for a
"Authorization-Result:" header where success and/or failure can
be communicated to the next party handling or viewing the mail.

But the way things are going, if you look at some of the
presentations and plans of vendors, there are expecting to "tag
and highlight" the good/valid messages with "Good DKIM seals."
There will no "bad markings" for others.

However, in my view, this is what's going to happen.

COX.COM (pick company) begins to offer DKIM "Trust Me Security"
mail systems to thier users.  They see a LIST of messages in their
inbox:

       From: so so    Date:
     $ From: so so    Date:
       From: so so    Date:
     $ From: so so    Date:
       From: so so    Date:
       From: so so    Date:
       From: so so    Date:
       From: so so    Date:
       From: so so    Date:
     $ From: so so    Date:
       From: so so    Date:
       From: so so    Date:

They see $ or whatever "Good DKIM Seal" icons for a few, but the majority
they don't.

But one of the non-$ messages is really a DKIM message but it had failed.

There will be many questions depending on a variety and combinations of
things:

1) One message was from a BANK account, DKIM signed, but it failed.
   Is it really good or bad?

2) Will the BANK contact COX.COM to find out why?

3) Will the USER contact the BANK to find out why?

4) What if it was really bad and the user lost his identity?

   Who is liable?

   COX.COM or the BANK.COM

   User sues BANK.COM.  BANK sues COX.COM.

etc, etc.  These are not non-issues, you can throw away.  These
are legal and managerial issues that inevitably will only be
solved by digging up the reasons why there was failure in the
first place.   So either you know upfront or find out later. It
will be required at some point.  Hopefully when its not too late.

> To: <[email-masked]>
> Sent: Friday, March 17, 2006 3:39 PM
> Your support idea is sound although I disagree on what DKIM is actually
> going to do. However those issues should not be a part of a policy
> document but rather an appendix or FAQ
>

---

From: <[email-masked]>
Date: Mon, 20 Mar 2006 09:54:47 -0500

I don't think presenting dkim information pro-actively to the end user
serves any useful purpose. Unlike PGP the user doesn't have an easy way
to decode what the header is telling them. In a few specific cases I
will reject mail based on a lack of dkim signatures. We do not envision
using dkim to bypass anti-spam, anti-virus or anti phishing services we
provide. It will be very useful when a properly decoded dkim sig
contains objectionable material, we now know who we can complain to
instead of guessing. The only support calls I envision are the same ones
we get now, from organizations that wonder why their messages are
getting bounced. DKIM may add to that but not significantly,
Thanks,

Bill Oxley 
Messaging Engineer 
Cox Communications, Inc. 
Alpharetta GA 
404-847-6397 
[email-masked] 

-----Original Message-----
From: Hector Santos [mailto:[email-masked]] 
Sent: Saturday, March 18, 2006 12:42 PM
To: Oxley, Bill (CCI-Atlanta)
Subject: Re: [ietf-dkim] New Issue: Analyzing Failures: List of Possible
Reasons

Offlist:

Does it means you plan to use DKIM deterministically?  Reject at the
SMTP
level?