Subject: [ietf-dkim] testing Message Corpus & question for base spec

From: Tony Hansen <[email-masked]>
Date: Fri, 10 Feb 2006 17:36:07 -0500

The message corpus found on dkim.org contains messages with illegal
expirations like "x=-1019102801;".

I'll be correcting these in the revised corpus I'm working on.

However, there is a question for the base spec: what should be done when
faced with an invalid expiration date such as that? Ignore it? Treat it
as a signature failure? Treat the message as always expired?

	Tony Hansen
	[email-masked]
_______________________________________________
NOTE WELL: This list operates according to &lt;http://dkim.org/ietf-list-rules.html&gt;

---

From: Michael Thomas <[email-masked]>
Date: Fri, 10 Feb 2006 14:49:45 -0800

>expirations like "x=-1019102801;".
Which brings something else up: it would be nice to have both a corpus of
good signatures, but also a corpus of stress test signatures with as many
edge cases and bogosities as possible with their correct outcomes.

>as a signature failure? Treat the message as always expired?
This group has been taking a pretty anti-Postel posture, so the 
consistent answer
would be to consider it badly formed and thus broken. Whether that's the 
right
answer...

       Mike
_______________________________________________
NOTE WELL: This list operates according to 
&amp;lt;http://dkim.org/ietf-list-rules.html&amp;lt;

---

From: "Hector Santos" <[email-masked]>
Date: Fri, 10 Feb 2006 18:34:08 -0500

----- Original Message -----
From: "Tony Hansen" <[email-masked]>

> The message corpus found on dkim.org contains messages
> with illegal expirations like "x=-1019102801;".
>
> However, there is a question for the base spec: what should be
> done when faced with an invalid expiration date such as that?
> Ignore it? Treat it as a signature failure? Treat the message
> as always expired?

This isn't like the old days where a sites machine is using the wrong
HELO domain or isn't using brackets Domain literals or there a space
after the MAIL FROM:, etc, and we have all sorts of relaxations.  Poor
form *must* be a major part of the protection.

Our implementation will be to reject all illegal DKIM implementations,
the form, the syntax, etc - regardless of any relaxed DKIM specification
or recommendation and especially of any accreditation system saying
otherwise including augmented fee-based tokens.

We would not recommend it to be a great idea to start something "new"
with relaxed provisions for broken implementations - that 80% of the
problem today. It should not be expected behavior.

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

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

---

From: Dave Crocker <[email-masked]>
Date: Fri, 10 Feb 2006 15:47:10 -0800

> would be to consider it badly formed and thus broken. Whether that's the 

I am guessing that the Postel reference is for being liberal in what you accept.

That guidance always has limits, of course.  The wrangling over canonicalization 
is an example of very much trying to be liberal.

But Postel never meant, for example, that one should accept a semi-colon if the 
syntax called for a period.  There are reasonable distortions imposed by the net 
and there are unreasonable errors imposed by originators.  The latter need to lose.

d/

-- 

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

---

From: <[email-masked]>
Date: Fri, 10 Feb 2006 22:30:29 -0500

I would treat it the same way as a broken ssl certificate, with suspicion. Rather than determining what is acceptable policy we should briefly outline what consists of a valid dkim sig with a brief note that policy is in the eye of the beholder.
thanks,
Bill

-----Original Message-----
From: [email-masked] on behalf of Dave Crocker
Sent: Fri 2/10/2006 6:47 PM
To: Michael Thomas
Cc: IETF DKIM WG
Subject: Re: [ietf-dkim] testing Message Corpus & question for base spec

d/

-- 

Dave Crocker

---

From: Dave Crocker <[email-masked]>
Date: Fri, 10 Feb 2006 22:01:36 -0800

> I would treat it the same way as a broken ssl certificate, with suspicion. Rather than determining what is acceptable policy we should briefly outline what consists of a valid dkim sig with a brief…

Hmmm.  Come to think of it, I'm inclined to interpret the Postel dictum as 
meaning that a broken signature (for whatever reason) is the same as no 
signature.  Pretend it wasn't there.

That's the most robust (liberal) handling by the validator.

So maybe DKIM has remained within the fold.

d/

-- 

Dave Crocker

---

From: Tony Hansen <[email-masked]>
Date: Sat, 11 Feb 2006 01:13:52 -0500

Michael Thomas wrote:
> Which brings something else up: it would be nice to have both a
> corpus of good signatures, but also a corpus of stress test
> signatures with as many edge cases and bogosities as possible with
> their correct outcomes.

I agree completely. If anyone has particular edge cases you'd like to
see included in an expanded corpus, send me email off-list and I'll
collect the ideas together. Then we can work on enlarging the corpus.

	Tony Hansen
	[email-masked]

---

From: "Hector Santos" <[email-masked]>
Date: Sat, 11 Feb 2006 03:15:28 -0500

----- Original Message -----
From: "Dave Crocker" <[email-masked]>

> Hmmm.  Come to think of it, I'm inclined to interpret the Postel
> dictum as meaning that a broken signature (for whatever reason) is
> the same as no signature.  Pretend it wasn't there.
>

Dave,

The Wolves (Bad Actors) will lick their chops with that interpretation,
and have.

"Postel's Law": "be conservative in what you do, be liberal in what you
accept from others" (often reworded as "be conservative in what you
send, be liberal in what you receive").
http://en.wikipedia.org/wiki/Postel's_Law

I've always interpreted this natural law philosophy to mean where there
is an indeterminate decision, a resultant first based on everything
being done as expected, you side with acceptance.

In the "good actor" world, the sender will tend to be correct without
ambiguity thus lowering confusion for the receiver.  The expectation is
you are doing thing correctly.  Where there is an indecision, you side
with acceptance.

Of course, for DKIM, it should all depend on the "reason" for the
breakage.

In the case of a bad expiration attribute, that should be an immediate
red flag for rejection with a high payoff, low false positives.

---

From: Douglas Otis <[email-masked]>
Date: Sat, 11 Feb 2006 06:21:32 -0800

> red flag for rejection with a high payoff, low false positives.

When the effort is to reduce phishing attacks, a message held too long
in a queue would not be a clear reason for rejection.  This of course
would assume the signature can still be verified.  The threat may fall
into the category of potential replay attack.  One solution could be
delayed acceptance in conjunction with replay-block-listing.  

Working through threats, strategies for assessment, and methods for
blocking, that effort may provide a better overview of these handling
strategies.  It seems unlikely DKIM, by itself, will offer a means to
reduce the level of spam, which appears to the motivation behind
aggressive rejection. At this time, DKIM is unrelated to return-path, so
even this avenue of attack remains unaffected.

-Doug

---

From: Frank Ellermann <[email-masked]>
Date: Sat, 11 Feb 2006 18:12:16 +0100

Douglas Otis wrote:

> It seems unlikely DKIM, by itself, will offer a means to
> reduce the level of spam, which appears to the motivation
> behind aggressive rejection.

We've STRONG DKIM and "weak" DKIM.  For the former you need
a valid "originator" signature, otherwise reject is the most
sensible thing to do:  Tag as suspicious and move it to some
"potential junk" folder expecting end users to wade through
it manually could degenerate into "drop", and then "reject"
is much better for legit senders.
                                  Bye, Frank

---

From: Douglas Otis <[email-masked]>
Date: Sat, 11 Feb 2006 10:01:08 -0800

> is much better for legit senders.

When the signature has elapsed beyond the an expiry period, the current
draft indicates the recipient MUST NOT consider the signature to be
valid.  This would be independent of any sender policy.  When the
message is within a reasonable time frame beyond the expiry time, this
could be due to two causes, replay or delay.  With a high level of spam,
placing messages into a junk folder is likely worse than rejecting the
message.  If this message was a delinquent delinquency notice, for
example, either full acceptance or rejection would make more sense.

The recipient may wish to consider how to handle delivery periods that
are perhaps too short to accommodate delays that may occur in the
recipient's system.  The MUST in the draft may be a bit harsh.

-Doug

---

From: Frank Ellermann <[email-masked]>
Date: Sat, 11 Feb 2006 20:05:47 +0100

Douglas Otis wrote:

 [base-00 3.5 x=] 
> The MUST in the draft may be a bit harsh.

Yes, s/MUST/SHOULD/ makes sense, e.g. if a MUA behind IMAP
wants to check signatures.  Editorial nit:  Splitting 3.5 in
subsections for the various "field types" could be a good idea.

I'd also prefer "parameters".  While talking about the header
"field" has a well-known meaning, "field types" within a header
field are confusing.  

OTOH it could be also confusing if these "parameters" don't
behave like MIME parameters (wrt "quoted string" etc.), maybe
a matter of taste.
                             Bye, Frank

---

From: Michael Thomas <[email-masked]>
Date: Sat, 11 Feb 2006 11:26:16 -0800

> Yes, s/MUST/SHOULD/ makes sense, e.g. if a MUA behind IMAP

I dunno, what does X.509 say about expired certificates?

I'm a little bit worried about the law of unintended consequences
here. Right now we have exactly two states: fully verifies, or
doesn't and is equivalent to no signature at all. What is the
ramification of allowing for a third state? Are there exploits
which become available? What about over all reliability/stability
when some receivers interpret the SHOULD differently?

		Mike

---

From: Dave Crocker <[email-masked]>
Date: Sat, 11 Feb 2006 11:42:39 -0800

> ramification of allowing for a third state? 

Indeed.

The power of the current, simple 2-state model cannot be overestimated, in my 
opinion.  We need to keep in mind that this is a mechanism for transit 
validation, rather than something with broader scope.

There are myriad, clever enhancements that could be made to DKIM's 
functionality.  We need to firmly resist the temptation to pursue any of them at 
this stage... unless there is a compelling argument for *immediate* community need.

After the first IETF version of DKIM is issued as a standard, we can consider 
all of those fascinating enhancements.

Right now, the urgency is for a basic, standard mechanism that works.

d/

-- 

Dave Crocker

---

From: "Hector Santos" <[email-masked]>
Date: Sat, 11 Feb 2006 14:51:14 -0500

----- Original Message -----
From: "Frank Ellermann" <[email-masked]>

> wants to check signatures.

And what if they do not?  What if it isn't behind IMAP.  Maybe its
online web mail system or just good old POP3 or both?

I personally don't have a problem with a change to "SHOULD" or "MAY"
recommendation, but rested assured, this (bad expiration) will be one or
many guarantee form of exploitation.  So a relaxation should be couple
with a hindsight about the high probably consequences of passing the
buck of bad or expired keys to the user.

All an X= relaxation does is put added pressures at various points in
the
system.

Also, there might be indirect association with this section and the
threat 4.1.10 "use of revoked keys" and DNS TTL timing issues.

---

From: Frank Ellermann <[email-masked]>
Date: Sat, 11 Feb 2006 20:58:38 +0100

Michael Thomas wrote:

  [base-00 3.5 x=]

> I'm a little bit worried about the law of unintended
> consequences here. Right now we have exactly two states:

> fully verifies, or doesn't and is equivalent to no signature
> at all. What is the ramification of allowing for a third
> state?

SHOULD NOT is most definitely not "do what you like".  One case
of "x NOT RECOMMENDED" vs. "SHOULD do y" where y is a part of x
just made it to the IAB for review.

Violating a SHOULD NOT still needs a good excuse, and wrt DKIM
the typical excuse "old implementations couldn't know this" is
not applicable (or maybe it is if an older DK draft didn't have
this MUST, I'm too lazy to verify this).

But checking DKIM in MUAs is possible, and what they find in
their POP3 or IMAP inbox could be rather old.  Not always, but
sometimes.  For a STRONG signing policy "invalid signature" is
almost the same as "reject - delete - report - it's a phish".

If the only problem is the expiration, and if that has a simple
reason like "user is now back from vacation reading his mails",
then the full anti-phishing-flak is not necessarily what (s)he
wants.  That could be a third case for STRONG signing policies.

> Are there exploits which become available? What about over
> all reliability/stability when some receivers interpret the
> SHOULD differently?

It's also possible to say "MUST NOT, but" if it's clear what
the "but" is about.
                           Bye, Frank

---

From: "Hector Santos" <[email-masked]>
Date: Sat, 11 Feb 2006 15:05:07 -0500

----- Original Message -----

> subsections for the various "field types" could be a good idea.

Just a follow up to my previous message.

This section says the default is NO expiration.

That isn't going to work very well :-)

A DKIM message will no expiration will quickly moving into a reject
classification if other issues are found with the message.

This will be especially the case with key policy "t=y" testing flag
(section 3.6.1).

This section should make the x= mandatory for t=y key policies and
should recommend a short expiration for testing.

A long "testing period" with problematic DKIM messages should not be
tolerated.

---

From: Michael Thomas <[email-masked]>
Date: Sat, 11 Feb 2006 12:30:22 -0800

> just made it to the IAB for review.

Yes, I know that.

> wants.  That could be a third case for STRONG signing policies.

And this I'm pretty sure leads us down a rathole we don't want
to go. It's just fine for MUA's to do the verification, but their
expectations shouldn't be what drives the standard, IMO. For
one, lots of MDA's torture messages into unverifiable messes, so
keeping expectations low is probably wise. For the same reason,
MUA's in general shouldn't be making any rash decisions about
signatures in the hear and now since regardless of x=, the sender
may also retire (= withdraw from DNS) a key in which case the
MUA would have no means of verifying it.

> It's also possible to say "MUST NOT, but" if it's clear what

Or just not say anything as Dave mentions. This is an easy one
to hedge against the future in any case. If it turns out we're wrong,
we haven't made an irreversable decision.

		Mike

---

From: Douglas Otis <[email-masked]>
Date: Sat, 11 Feb 2006 12:37:08 -0800

On Sat, 2006-02-11 at 14:51 -0500, Hector Santos wrote:
> recommendation, but rested assured, this (bad expiration) will be one
> or many guarantee form of exploitation.  So a relaxation should be
> couple with a hindsight about the high probably consequences of
> passing the buck of bad or expired keys to the user.

An expiry that is too brief may also be used as a type of exploitation.
A bad actor knows that a domain checks DKIM at both the backup MTA and
at the MDA.  The bad actor uses a mis-directed return-path and an expiry
that is too short and sure to be caught by the MDA.  The DSN thereby
generated would be expected to damage the signature.  Perhaps an expiry
exploit could be used to get the victim to wonder how they sent a signed
message containing that hot stock tip. 

-Doug

---

From: Douglas Otis <[email-masked]>
Date: Sat, 11 Feb 2006 12:58:48 -0800

On Sat, 2006-02-11 at 11:42 -0800, Dave Crocker wrote:

> 
> The power of the current, simple 2-state model cannot be
> overestimated, in my opinion.  We need to keep in mind that this is a
> mechanism for transit validation, rather than something with broader
> scope.
> 
> functionality.  We need to firmly resist the temptation to pursue any
> of them at  this stage... unless there is a compelling argument for
> *immediate* community need.
> 
> After the first IETF version of DKIM is issued as a standard, we can
> consider  all of those fascinating enhancements.
> 

Agreed.

Threat analysis should not be as constrained, however.  Noted problems
and possible defensive strategies may help ensure future options are not
circumvented or otherwise prevented.  This may also set the proper
expectations for what DKIM can and cannot safely provide.  Until the
limitations and defensive strategies for DKIM are better explored,
implementers may not have anticipated the impact and become
disappointed.  Working out the problems within the WG, at least on
paper, also seems to ensure these solutions can remain in the public
domain.

-Doug

---

From: Frank Ellermann <[email-masked]>
Date: Sat, 11 Feb 2006 22:59:00 +0100

Michael Thomas wrote:

>> That could be a third case for STRONG signing policies.
 
> And this I'm pretty sure leads us down a rathole we don't
> want to go.  It's just fine for MUA's to do the verification,
> but their expectations shouldn't be what drives the standard,
> IMO.

Maybe it's a hole that can be blocked elsewhere.  Doug found an
interesting way of (ab)using intentionally short expirations.

> lots of MDA's torture messages into unverifiable messes

Do they ?  Maybe I was lucky, I've never seen that with several
ISPs.  Or you're talking about servers that I won't consider as
proper MDA. 

> Or just not say anything as Dave mentions.

If there are forseeable non-nonsense scenarios, where checking
DKIM might not always work as expected, we should mention it
somewhere.

> If it turns out we're wrong, we haven't made an irreversable
> decision.

As long as the caveats are documented I won't insist on using
MUSTard to make them more interesting than they are... :-)  Bye

---

From: Jim Fenton <[email-masked]>
Date: Sat, 11 Feb 2006 22:31:04 -0800

> recipient's system.  The MUST in the draft may be a bit harsh.
The MUST in the draft refers to the validity of the signature, not the
validity of the message.

If you subscribe (as I do) to the philosophy that an invalid signature
should be treated as though it is absent, then the verifier MUST behave
as though the expired signature just isn't there.  Maybe there is
another valid signature, or maybe not.  If not, the message is handled
just like an unsigned one.

-Jim

---

From: Douglas Otis <[email-masked]>
Date: Sun, 12 Feb 2006 09:13:10 -0800

On Sat, 2006-02-11 at 22:31 -0800, Jim Fenton wrote:
> should be treated as though it is absent, then the verifier MUST
> behave as though the expired signature just isn't there.  Maybe there
> is another valid signature, or maybe not.  If not, the message is
> handled just like an unsigned one.

This view overlooks the effect policy might play.  With strict treatment
of an expiry time, this could create situations where messages are
rejected post acceptance, but prior to delivery, for example.

-Doug

---

From: Eric Allman <[email-masked]>
Date: Wed, 15 Feb 2006 12:16:33 -0800

--On February 10, 2006 6:34:08 PM -0500 Hector Santos 
<[email-masked]> wrote:
> Our implementation will be to reject all illegal DKIM
> implementations, the form, the syntax, etc - regardless of any
> relaxed DKIM specification or recommendation and especially of any
> accreditation system saying otherwise including augmented fee-based
> tokens.

Hector, are you saying that you intend to ignore MUSTs in the spec? 
For example, the spec says that verifiers MUST ignore any tags that 
they do not implement.  This can be viewed as a "relaxed" view, but 
it is critical to allow future extensions.

If you're just talking about the x=-1019102801 issue (and things of 
that sort, i.e., malformed entries that the verifier does understand) 
then I'm in total agreement, and I think the existing draft already 
covers that.  For example, section 6.1 includes:

        Implementers MUST meticulously validate the format and values
        in the "DKIM-Signature:" header field; any inconsistency or
        unexpected values MUST result in an unverified email. Being
        "liberal in what you accept" is definitely a bad strategy in
        this security context. Note however that this does not
        include the existence of unknown tags in a "DKIM-Signature"
        header field, which are explicitly permitted.

Since the ABNF for the x= tag reads:

        sig-x-tag    = %x78 [FWS] "=" [FWS] 1*12DIGIT

the hyphen/dash/minus is clearly out of spec.

[I do see one error however; that statement should probably say "MUST 
cause the header field to be completely ignored", which is consistent 
with the wording in the rest of section 6.]

eric

---

From: "Hector Santos" <[email-masked]>
Date: Wed, 15 Feb 2006 17:27:28 -0500

----- Original Message -----
From: "Eric Allman" <[email-masked]>
To: "Hector Santos" <[email-masked]>

> Hector, are you saying that you intend to ignore MUSTs in the spec?

You and I know as SMTP developers, that is not want I meant. :-)

> it is critical to allow future extensions.

Correct. Standard stuff.  [Small Point, might help to highlight if
not there already, a minimum requirement section]

> then I'm in total agreement,

Correct, this and issues like it.

> with the wording in the rest of section 6.]

I think there needs to be a clarification in the on-going and repeated usage
of saying "completely ignored".

In short, without going too deep with this, transactions based on the "very
limited purpose of DKIM, for assigning transit accountability, [1]" makes
the assertion of:

     legacy transit info !=  new transit and CORRECT accountability info

But this also implies the assertion:

     legacy transit info !=  new transit and INCORRECT accountability info

So if one is to assume an assertion that correct usage improves legacy SMTP
operations, it is also implies incorrect usage improves legacy SMTP
operations as well. So treating the incorrect as if its an legacy system is
where I'm afraid to say, we will see some major conflicting "mixed
technology or policy" adoption issues in the future.  There is absolutely no
doubt in my mind of that, hence basically the basic meaning of my original
statement above.

[1] http://mipassoc.org/pipermail/ietf-dkim/2006q1/002168.html

---

From: Eric Allman <[email-masked]>
Date: Wed, 15 Feb 2006 14:50:13 -0800

>>> ...

Good, that's what I thought, but I wanted to be sure.

> not there already, a minimum requirement section]

It seems pretty clear to me, but then I know the document perhaps too 
well to see it objectively.  I think I quoted the text previously.

> ...
>
>> [I do see one error however; that statement should probably say
>> "MUST cause the header field to be completely ignored", which is
>> consistent with the wording in the rest of section 6.]
>
> I think there needs to be a clarification in the on-going and
> repeated usage of saying "completely ignored".

Yes, I agree.  The kind of algorithm I have in mind is something like:

        read_all_signatures();
        sort_signatures_into_preferred_order();
        good_sig = false;
        foreach sig in signatures
                if (malformed || missing key || expired key || ...)
                        continue;
                if (good_sig = check_sig_ok(sig))
                        break;   // from foreach
        if (good_sig)
                process the message with signature
        else
                process the message as though there were no signature

The problem is turning this into English.

> In short, without going too deep with this, transactions based on
> the "very limited purpose of DKIM, for assigning transit
> accountability, [1]" makes the assertion of:
>

I'm not sure I'm understanding this.

> So if one is to assume an assertion that correct usage improves
> legacy SMTP operations, it is also implies incorrect usage improves
> legacy SMTP operations as well. So treating the incorrect as if its
> an legacy system is where I'm afraid to say, we will see some major
> conflicting "mixed technology or policy" adoption issues in the
> future.  There is absolutely no doubt in my mind of that, hence
> basically the basic meaning of my original statement above.

And I'm quite sure I don't understand this.

eric

---

From: "Hector Santos" <[email-masked]>
Date: Wed, 15 Feb 2006 18:36:40 -0500

----- Original Message -----
From: "Eric Allman" <[email-masked]>
To: "Hector Santos" <[email-masked]>

> well to see it objectively.  I think I quoted the text previously.

Just a suggestion for a new section:

    1.5 Basic Requirements Summary

Then seach for all "requir" or "MUST" in the document, consolidate it and
try to summary it in this basic section in outline format, maybe with each
having a reference to the specific more detail section as well.

> The problem is turning this into English.

[FLAWED TECHNOLOGY!]

    If one or more signatures are valid, then process the message as
    a good signature.  This includes if there exist one or more
    bad signature.  As long as there is 1 good signature, process
    the message as a good signature.

> I'm not sure I'm understanding this.

ok, this is what I meant :-)

I would change your pseudo code or implement it as such:

      total_sigs = read_all_signatures();  // v1.1 HLS
      sort_signatures_into_preferred_order();
      good_sig = false;
      something_wrong[] = {nope};   // v1.1 HLS
      foreach sig in signatures {
          //-------------------------
          // v1.1 HLS
          something_wrong[sig] = malformed || missing key || expired key ||
...
          if (something_wrong[sig])
              continue;
          //-------------------------
          if (good_sig = check_sig_ok(sig))
              break;   // from foreach
      }

      // v1.1 HLS
      not_quite_kosher = false;
      foreach wrong in something_wrong
         if (wrong != nope) {
           not_quite_kosher = true;
           break;
         }
      }
      //

      if (good_sig)
          if not_quite_kosher and LocalPolicy_AcceptWrong then // v1.1 HLS
             reject(something_wrong[]);   // v1.1 HLS
          else
             process the message with signature(something_wrong[]);
      else
          if (total_sigs and LocalPolicy_AcceptWrong)
             reject(something_wrong[]);   // v1.1 HLS
          else
             process the message as though there were no signature

In short, if there is any attempt to use a new set of DKIM information, and
its incorrect, then it should it a LOCAL POLICY DRIVEN as to how this will
handled.  It is not like there is a "no signature" because that isn't true.
There is a signature, just incorrect and this information is vitality
important.

I can not under good conscious believe there would be such a think as a GOOD
message when there is something wrong with it.

Grant it, I think your code assumes and attempts to desensitize the "List
Server" issues. But it doesn't take into account the high potential abuse
and extreme overhead that will be placed across the network on so many
systems.  Over 80% of SMTP transactions are not SMTP compliant
(intentionally).  Is DKIM the exception to this high probability?

Note: the Reject() function is just a stub. Whether it is actually rejected,
put aside or flagged, is implementation dependent and more than likely local
policy defined.

---

From: Eric Allman <[email-masked]>
Date: Wed, 15 Feb 2006 18:21:36 -0800

--On February 15, 2006 6:36:40 PM -0500 Hector Santos 
<[email-masked]> wrote:

> Then seach for all "requir" or "MUST" in the document, consolidate
> it and try to summary it in this basic section in outline format,
> maybe with each having a reference to the specific more detail
> section as well.

Interesting idea, but I think it's probably best held off until the 
document is essentially done so we don't get things out of sync.

>     the message as a good signature.

OK, I made the last paragraph of Section 6 (i.e., right before 6.1) 
read

        Verifiers MUST apply the following steps in the order listed.
        In many cases these steps say that a "DKIM-Signature" header
        field should be ignored, e.g., because it is malformed or
        because the signature verification failed.  In such cases
        verifiers SHOULD proceed to the next signature, and treat the
        message as verified if any signature succeeded, ignoring the
        bad signatures.  The order in which signatures are tried is a
        matter of local policy for the verifier and is not defined
        here.  A verifier MAY treat a message that has one or more
        bad signatures and no good signatures differently from a
        message with no signature at all; again, this is local policy
        and is beyond the scope of this document.

I hope this captures what we are both trying to say.  There is one 
possibly controversial point here: that a verifier MAY treat a 
message with bad signatures differently than those with no 
signatures.  I really view this as out of scope, since that's a local 
policy issue, so perhaps it should be deleted entirely.

>           something_wrong[sig] = malformed || missing key ||
> expired key || ...
>           if not_quite_kosher and LocalPolicy_AcceptWrong then //
> v1.1 HLS              reject(something_wrong[]);   // v1.1 HLS
>           else
> In short, if there is any attempt to use a new set of DKIM
> information, and its incorrect, then it should it a LOCAL POLICY
> DRIVEN as to how this will handled.  It is not like there is a "no
> signature" because that isn't true. There is a signature, just
> incorrect and this information is vitality important.

I think we're agreeing, although I think your last "if" block has 
some conditions reversed (or I'm getting confused over variable 
names).  It seems to say that I have a good signature but something 
is wrong and my local policy allows this then I should reject the 
message.

My initial draft actually included something like this but I pulled 
it out for simplicity; mine just included a "something failed" 
boolean that got set in the obvious places.

> I can not under good conscious believe there would be such a think
> as a GOOD message when there is something wrong with it.
>
> Grant it, I think your code assumes and attempts to desensitize the
> "List Server" issues. But it doesn't take into account the high
> potential abuse and extreme overhead that will be placed across the
> network on so many systems.  Over 80% of SMTP transactions are not
> SMTP compliant (intentionally).  Is DKIM the exception to this high
> probability?

Dream on, although I'm surprised the number is so high --- perhaps if 
you include spam engines.  But here is where I think we have a 
disagreement; I am concerned, at least in the short run, about 
signatures that get trashed for innocuous reasons, such as mailing 
list exploders.  I don't think such messages should be rejected. 
This is, of course, local policy.

eric

---

From: Mark Delany <[email-masked]>
Date: Thu, 16 Feb 2006 03:00:25 +0000

On Wed, Feb 15, 2006 at 06:21:36PM -0800, Eric Allman allegedly wrote:

>         here.

Modulo possible upgrade/downgrade guidance given in other parts of the
(future) spec.

>         A verifier MAY treat a message that has one or more

I would almost want such text not to be in the spec, but making it
clear that any assessment of invalid signatures is strictly
out-of-scope and entirely a local policy is a good thing.

Jim and Mike I think have push this button the most - and I agree
completely - that ascribing meaning to an invalid signature is tenuous
at best and certainly not something we want to codify.

>> Over 80% of SMTP transactions are not SMTP compliant

> This is, of course, local policy.

Right. If anything I would want to go further and advise against
implementing local policy in this space. The point about SMTP
non-compliance reinforces that point as most of this non-conformance
is likely due to ignorance, hubris and bugs rather than malicious
intent.

Mark.

---

From: "Hector Santos" <[email-masked]>
Date: Thu, 16 Feb 2006 01:26:10 -0500

Eric (and Mark),

First, let me say thanks for taking the time to reply.

I've bounced around this all evening and decided it isn't worth the time to
rock this (leaky) boat anymore.

But I will say this for the record:

Whether you know it or not, you are making indirect technical and indirect
local policy decisions with the assertion:

    "bad signatures --> treat as if no signature was even present"

So just because you don't want to say anymore about Local Policies or how
invalid DKIM signatures are possible, saying it should be treated as if as
NO SIGNATURE is present, it is making a technical and local policy decision.

I think it is a failed and flawed design concept and I have not been
convinced that it is not.

I can only advise you of this:

If mailing list or middle ware tampering is your problem, then I advise you
to quickly resolve this because there is no doubt in my mind the
exploitation of using invalid DKIM signatures is going to be give DKIM a
black eye and become a major thorn on the side.  To believe only "GOOD
Signatures" is the only form of good messages and BAD signatures as no
signature is unrealistic.

---

From: Mark Delany <[email-masked]>
Date: Thu, 16 Feb 2006 07:36:03 +0000

> convinced that it is not.

You may be right, we may be wrong. Or vice versa. These are early days
and we collectively will learn more as time goes by. If DKIM 1.0
doesn't get it perfectly right, that doesn't preclude a DKIM 1.1
getting it closer to right.

In part, these sort of differences underscore why many of us want to
make DKIM the lowest possible bar for success. We want DKIM 1.0 to be
*just* useful enough to succeed, but we don't want to presuppose or
impose on the huge uncharted territory that follows.

While I might disagree with Hector today about the question of
inferring meaning from invalid signatures, rather than try and battle
that out in the abstract on this list, I'd much rather see a DKIM 1.0
framework that lets us find out real answers in the field.

If it turns out that Hector is right, based on empirical evidence,
then let's reflect that in DKIM 1.1. If it turns out that Hector is
wrong, we should similarly reflect that outcome in DKIM 1.1

If there is one mistake we should avoid, I'd suggest that imposing our
speculation on the minimum base to try and get it perfect, is it. Why?
Because we don't know what perfect is yet.

Mark.

---

From: Eric Allman <[email-masked]>
Date: Thu, 16 Feb 2006 13:31:25 -0800

--On February 16, 2006 1:26:10 AM -0500 Hector Santos 
<[email-masked]> wrote:
> Whether you know it or not, you are making indirect technical and
> indirect local policy decisions with the assertion:
>

Yes, you are correct, which is why such wording is (supposed to be) 
no more than a SHOULD or an informative comment.  I do see that there 
are several MUSTs that really ought to be converted to SHOULDs for 
this to be true.  This is a major enough change that I think it 
should have further discussion; I'll ask Elliot to put it on the 
issues list.

> So just because you don't want to say anymore about Local Policies
> or how invalid DKIM signatures are possible, saying it should be
> treated as if as NO SIGNATURE is present, it is making a technical
> and local policy decision.
>

Our (or at least My) logic is as follows:  in the short run, we know 
there are agents out there that modify the message in various ways. 
We might argue that they are wrong, but they do exist.  We expect or 
at least hope that DKIM will cause such agents to atrophy.  At some 
point there may be few enough of them that my advice will change, and 
we can consider a bad signature to be a strong sign of probably 
abuse.  But for now I'm a firm believer that to do so would cause far 
too many incorrect rejections.

That said, I do believe that this is verifier local policy, and I 
support your right to implement your code however you deem 
appropriate.

eric

---

From: Jim Fenton <[email-masked]>
Date: Mon, 20 Feb 2006 14:27:53 -0800

>     the message as a good signature.
Perhaps this is part of sort_signatures_into_preferred_order(), but I
wanted to make it explicit:  Since SSP might not allow third-party
signatures, it's probably best to check first-party signatures first. 
Stopping with the first valid signature might not give the right result
otherwise.

-Jim

---

From: "Hector Santos" <[email-masked]>
Date: Wed, 22 Feb 2006 08:50:46 -0500

----- Original Message -----
From: "Jim Fenton" <[email-masked]>
To: "Hector Santos" <[email-masked]>

> Stopping with the first valid signature might not give the right result

Possibly.  The sorting question seems to be "kludge" or an attempt to make
something good out of something that just be really bad.

In my view, four items are keeping us from going full steam with this:

   - the SSP,
   - list servers,
   - mix policy conflict, and
   - authorization results/reporting.

All needs to be resolved before trying to make heads or tails from DKIM
signatures.  Too many mushrooms in this "DKIM Green Field."

For the records, we have begun collecting DKIM and DOMAINKEY signed messages
passing through our system.  I'm seeing fraud already taken place. The most
obvious are those with no policies - just fake signatures.  I'm also seeing
the spammers beginning to use one or both thru 3rd party domains.  These 3rd
party domains are going to be a high risk of quickly getting "flagged."