Subject: Re: [ietf-dkim] Re: dkim-base-01 nits and semi-nits

From: Eric Allman <[email-masked]>
Date: Mon, 01 May 2006 11:01:05 -0700

> My only concern is to ensure we're not prescriptive to a
> verifier. Anywhere we say "reject" probably should be changed to
> "treat as unsigned" as long as there is no implication one way or
> the other as to what a verifier does with that "is verified" or "is
> not verified" knowledge.

At some level I agree with you.  But saying "treat as unsigned" is 
just as prescriptive as "reject" --- either is telling the verifier 
what to do.  As a verifier, I may want to just outright reject all 
messages that have unsigned content.  It's probably not a good idea, 
but someone somewhere will want to do it someday.

That said, I'll use your argument to remove the "reject" language 
from 3.4.5.  Changing all the "ignore the signature" clauses to 
"ignore the signature, which is a good idea, or if you really want, 
go ahead and reject the message outright if you dare" would just be a 
huge mess.

If we do want to make this more precise, I recommend that we have an 
explicit list of signature states, e.g., GOODSIG, BADSIG, NOSIG, 
PARTIALSIG (the l= case), SYNTAXSIG (syntax error in signature), 
etc., and then leave the actual actions taken on each of these states 
remain undefined in the -base document.  That's probably a fair 
amount of text changes, but most likely fairly mechanical.

eric

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

---

From: "Hector Santos" <[email-masked]>
Date: Mon, 1 May 2006 14:46:40 -0400

----- Original Message -----
From: "Eric Allman" <[email-masked]>
To: "Mark Delany" <[email-masked]>
Cc: <[email-masked]>
Sent: Monday, May 01, 2006 2:01 PM
Subject: Re: [ietf-dkim] Re: dkim-base-01 nits and semi-nits

> but someone somewhere will want to do it someday.

Eric, may I suggest a section totally devoted to defining what "invalid"
means and also instead of saying "reject" or "accept" say something like:

      - negatively classfied
      - positively classfied

It is like in SMTP, when say "send a postive response code" or "send a
temporary or permanent negative response code."

This is enough information for implementators to know what to do, and that
includes SMTP developers and also after market 3rd party software, i.e.,
reputation systems.

> amount of text changes, but most likely fairly mechanical.

Bingo!! +1!

This is where a section totally developed to Failure Definition and what is
expected by the domain can be added to it.

Lets keep in mind that we have SSP coming and DKIM needs to be consistent
with not blocking helper technology because there is no doubt in mind, DKIM
will need alot of help. :-)

In fact, I plan to offer an alternative to SSP called DSAP (DKIM Signature
Authorization Protocol).  This will be published very shortly.

http://isdg.net/public/ietf/drafts/draft-santos-dkim-dsap-01.txt
http://isdg.net/public/ietf/drafts/draft-santos-dkim-dsap-01.html

Related to your classification idea, part of the proposal allows the signing
domain to define a policy for failure handling for the three general errors:

   -  Signature Authoriztion  (fa=)
   -  Expiration, Revocation  (fx=)
   -  DKIM signature error    (fs=)

4.8.  DSAP Tags: fa=<failure-handling>; fs=<failure-handling>;
      fx=<failure-handling>;

   The fa=, fs, and fx= tags define the domain preferred rejection
   action policy a verifier is recommended to perform when an
   unauthorized signature, failed signature or expired signature is
   detected, respectively.

   The fa= tag defines the handling for failed signature authorization.

   The fs= tag defines the handling for failed signature verfication,
   and the fx= tag defines the handling when a signature expired or key
   is revoked.

   Failed signature includes failured related to the DKIM-Signature
   hashing, syntax and encryption verification process.

   <failure-handling> values:

   FAIL                The verifer MUST reject the transaction when
                       failure is detected.  (Default)

   SOFTFAIL            The verifer SHOULD reject the transaction when
                       failure is detected.

   IGNORE              The verifer MAY reject the transaction when
                       failure is detected.  This value may be defined
                       by the domain to signify the domain is testing
                       DKIM and failure may occur unexpectedly.
                       However, this handler should not be tolerated by
                       verifiers and should be tracked for abuse.

   The fa= and fs= tags are optional with default values of SOFTFAIL.

   Examples:

   fa=fail;fs=fail; fx=fail;  Domain has a MUST reject immediate policy
                       for unauthorized, failed or expired signatures.

   fa=fail;            Domain has a MUST reject immediate policy for
                       unauthorized signatures and a SHOULD reject
                       immediate policy for failed and expired
                       signatures.

   undefined tags;     DOMAIN has a SHOULD reject immediate policy for
                       all failures.

   fs=fail;  fx=fail;  Domain has a SHOULD reject immediate policy for
                       unauthorized signatures and a MUST reject
                       immediate policy for failed and expired
                       signatures.

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

---

From: Jim Fenton <[email-masked]>
Date: Mon, 01 May 2006 13:44:48 -0700

Eric Allman wrote:
> Jim, thanks for the comments.
>> Section 1.1 bullet 7 and bullet 9 seem redundant
>
> I think they are slightly different.  Bullet 7 says that you can get
> results without updating the clients.  Bullet 9 says you don't have to
> update all your MTAs at once.

Part of the problem is that I read "incrementally" and "independently"
as the same word.  This is fine.
>
>> Section 1.3 seems like it should say something about DKIM's
>> scalability characteristics, not just that of email, since the
>> other 1.x sections are describing DKIM in various ways.
>
> Hmm....  It also says that the any-to-any characteristic is important,
> which might not be true for other services.  Any suggested wording?

How about something like this:

DKIM is designed to support the extreme scalability requirements which
characterize the email identification problem.  There are currently over
70 million domains and a much larger number of individual addresses. 
DKIM seeks to preserve the positive aspects of the current email
infrastructure, such as the ability for anyone to communicate with
anyone else without introduction.
>
>> Section 3.1 The INFORMATIVE IMPLEMENTERS' NOTE seems like it would
>> fit better later in the document such as section 3.6.
>
> I couldn't quite get this to flow very well.  It doesn't belong under
> "Textual Representation" or "DNS binding" because the point is
> independent of how the record is represented or delivered.  It just
> doesn't seem to "fit" in the overview.  Perhaps I'm missing something.

I'm not sure of the solution to this either.  It just seemed like it was
a little early to discuss that sort of key/selector management detail
right after having introduced the concept of selectors themselves.

-Jim

---

From: Eric Allman <[email-masked]>
Date: Mon, 01 May 2006 14:03:24 -0700

>> Hmm....  It also says that the any-to-any characteristic is
>> important, which might not be true for other services.  Any
>> suggested wording?
>
> DKIM is designed to support the extreme scalability requirements
> which characterize the email identification problem.  There are
> currently over 70 million domains and a much larger number of
> individual addresses.  DKIM seeks to preserve the positive aspects
> of the current email infrastructure, such as the ability for anyone
> to communicate with anyone else without introduction.

Great, thanks.

>> I couldn't quite get this to flow very well.  It doesn't belong
>> under "Textual Representation" or "DNS binding" because the point
>> is independent of how the record is represented or delivered.  It
>> just doesn't seem to "fit" in the overview.  Perhaps I'm missing
>> something.
>
> I'm not sure of the solution to this either.  It just seemed like
> it was a little early to discuss that sort of key/selector
> management detail right after having introduced the concept of
> selectors themselves.

Now I understand.  As an attempt to make 3.1 flow better, I moved 
this note to the very end of the section.

eric

---

From: Jim Fenton <[email-masked]>
Date: Mon, 01 May 2006 16:59:18 -0700

> but someone somewhere will want to do it someday.
"Treat as unsigned" seems a little ambiguous when there might be
multiple signatures.  It might be interpreted as "treat the message as
though it is completely unsigned" as opposed to "consider this signature
invalid" which I think is your intent.

-Jim

---

From: Michael Thomas <[email-masked]>
Date: Mon, 01 May 2006 18:14:51 -0700

>invalid" which I think is your intent.
I'm a little confused by Eric's previous mail on what he was going to do,
but "ignore the signature [as invalid]" seems to convey the intent here, 
without
falling into the trap you're referring to.

       Mike

---

From: "Hector Santos" <[email-masked]>
Date: Mon, 1 May 2006 21:46:56 -0400

----- Original Message -----
From: "Jim Fenton" <[email-masked]>
To: "Eric Allman" <[email-masked]>
Cc: "Mark Delany" <[email-masked]>; <[email-masked]>
Sent: Monday, May 01, 2006 7:59 PM
Subject: Re: [ietf-dkim] Re: dkim-base-01 nits and semi-nits

> invalid" which I think is your intent.

Jim,

I hope not.

I understand the proposed pseudo procedure to handling multiple signatures,
looking for one that "works,",  but it completely fascinates me to think how
failure state information can be ignored.

How can one treat, view or interpret a failure signature as "unsigned" when
in fact, it was signed?

Continuing processing is one thing,  but treated it as it never happen?  I
fail to see this logic. Even if not rejected, but logged or flagged, that is
not treated it as it was unsigned.

If I was a domain signer, and I was responsible for this mail with my
reputation on the line, I would want the verifier to prune all failures
because it was not what I expected and I don't want potentially harmful
mail, which is probably isn't mind to begin with, reaching the intended
end-user.

And even if the verifier is not going to reject, I certainly do not want it
to ignore the fact there was a failure with mail purported to be from
domain.

So what or how should the verifier do?  What is expected of them by domain
signers?

I can only see this work if the verifiers gets help from the domain itself
having an email policy that tells verifiers how to handle failures.

---

From: Jim Fenton <[email-masked]>
Date: Tue, 02 May 2006 11:30:56 -0700

> How can one treat, view or interpret a failure signature as "unsigned" when
I don't think the wording "consider this signature invalid" requires the
verifier to consider a signature failure as "unsigned".  Yes, as I said
in http://article.gmane.org/gmane.ietf.dkim/1751, I think one should
consider failed signatures as if they aren't there, but I'm not sure
that's something to include in the -base specification.  Other
opinions?  How prescriptive should we be about how the verifier handles
this?

Here's a good "if a tree falls in the woods..." sort of question to
ponder:  If someone attaches a DKIM-Signature header field that they
know is invalid to a message, was the message signed?  If not, how can
you say that "in fact, it was signed"?
> mail, which is probably isn't mind to begin with, reaching the intended
Keep that thought for the SSP discussion.
> having an email policy that tells verifiers how to handle failures.
That's a direction we could go with SSP, when we get to that discussion.

-Jim

---

From: Douglas Otis <[email-masked]>
Date: Tue, 2 May 2006 12:28:28 -0700

On May 2, 2006, at 11:30 AM, Jim Fenton wrote:

> I don't think the wording "consider this signature invalid"  
> requires the verifier to consider a signature failure as "unsigned".

The state of being "unsigned" implies the message does not contain a  
verifiable signature.  Signature verification may fail when the  
algorithm is unknown.  Imposing a scheme where an invalid signature  
affects the validity of other signatures may prohibit a means to  
transition to newer algorithms.

>  Yes, as I said in http://article.gmane.org/gmane.ietf.dkim/1751, I  
> think one should consider failed signatures as if they aren't  
> there, but I'm not sure that's something to include in the -base  
> specification.

Some limit should bound the signature verification process, either by  
a permitted number of signatures or a minimum number of verification  
operations.  A basic goal of ensuring compatibility seems to require  
that some signature/verification limit be established.

-Doug

---

From: Arvel Hathcock <[email-masked]>
Date: Tue, 02 May 2006 14:34:03 -0500

> I think one should consider failed signatures as if they aren't there,
 > but I'm not sure that's something to include in the -base
 > specification.  Other opinions?  How prescriptive should we be about
 > how the verifier handles this?

I think this is a case where we should dictate verifier behavior in so 
far as instructing them that such signatures must be ignored (which is 
the same as saying treat it as if it isn't there).

To me, this sort-of falls into the category of defining for the verifier 
what a DKIM-Signature header looks like.  Just as it must conform to a 
certain syntax and start with "DKIM-Signature" etc (and BTW we have no 
problems prescribing those facts) we should also mandate that it must 
verify.

But, I'm interested to hear other views.

-- 
Arvel

---

From: Arvel Hathcock <[email-masked]>
Date: Tue, 02 May 2006 14:41:01 -0500

> Imposing a scheme where an invalid signature affects the validity of
 > other signatures may prohibit a means to transition to newer
 > algorithms.

Right.  We shouldn't do that.  If a message has multiple signatures and 
invalid ones are simply ignored then there is no problem for the good one.

-- 
Arvel

---

From: Dave Crocker <[email-masked]>
Date: Tue, 02 May 2006 23:29:09 -0700

> verifier to consider a signature failure as "unsigned".  
>   

When a signature fails to validate, the message should be processed as
if that signature is not present.

d/

-- 

Dave Crocker
Brandenburg InternetWorking
<http://bbiw.net>

---

From: Dave Crocker <[email-masked]>
Date: Tue, 02 May 2006 14:33:09 -0700

When a signature fails to validate, the message should be processed as 
if that signature were not present.

d/

-- 

Dave Crocker

---

From: Douglas Otis <[email-masked]>
Date: Wed, 3 May 2006 08:20:24 -0700

On May 2, 2006, at 2:33 PM, Dave Crocker wrote:

>> requires the
> When a signature fails to validate, the message should be processed  
> as if that signature were not present.

The process should track the number of attempts made verifying  
signatures for a message.  This concern differs from "as if that  
signature were not present."  Without a reasonable limit for the  
process, DKIM verification itself can become a threat.

-Doug

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 3 May 2006 09:45:13 -0700

>if that signature is not present.

+1; clear simple wording that is easy to implement.

>process, DKIM verification itself can become a threat.

-1; this is an edge-case that is not worth being discussed in the 
-base document.
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: "J.D. Falk" <[email-masked]>
Date: Wed, 03 May 2006 11:00:28 -0700

On 2006-05-03 08:20, Douglas Otis wrote:

> signatures for a message.

That's an implementation choice.  It doesn't need to be a requirement of 
the standard.

-- 
J.D. Falk, Anti-Spam Product Manager
Yahoo! Communications Platform Team
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Douglas Otis <[email-masked]>
Date: Wed, 3 May 2006 11:01:48 -0700

On May 3, 2006, at 9:45 AM, Paul Hoffman wrote:

> -1; this is an edge-case that is not worth being discussed in the - 
> base document.

While the base draft may not indicate what is considered to be too  
many signatures or verifications attempts, the language describing  
how an invalid signature is handled should still indicate that a  
limit SHOULD BE applied.  The base draft does not need to be specific  
about the limit, but this is safety concern.  The actual limited  
could be defined in some BCP.

-Doug