Subject: [ietf-dkim] New Issue: Treatment of verification failure not really a goal

From: Jim Fenton <[email-masked]>
Date: Mon, 24 Mar 2008 21:30:59 -0700

Most of the sections under 3.2, "Operational Goals", are really goals in 
the sense of "I want a mechanism that...".  So "I want a mechanism that 
permits incremental adoption for incremental benefit" makes complete 
sense.  As does "I want a mechanism that minimizes the amount of 
required infrastructure."

But section 3.2.1, "Treat verification failure the same as no signature 
present" doesn't strike me as a goal, but rather a consequence of the 
way that the mechanism works.  I would probably rather have something 
that can treat verification failure more harshly, but it doesn't work 
that way.  This really ought to be merged with section 5.4, "Unverified 
or unsigned mail" instead.

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

---

From: Dave Crocker <[email-masked]>
Date: Mon, 24 Mar 2008 22:29:12 -0700

> or unsigned mail" instead.

Let's try to tackle your last point, first.  Section 5.4 is a description of the 
architecture.  It's certainly a reasonable place to observe that failures are 
treated the same as no signature, as indeed 5.4 does.  However that is different 
from describing higher-level goal-like issues, which is what section 3 is 
intended to be.  By 'higher-level' I mean the stuff of significant constructs 
that motivate the work.

Now to your primary point:  DKIM's treating failures the same as no-signature is 
an unusual characteristic that captures folk's interest. From a pedagogical 
point of view, it warrants highlighting as an distinctive construct.

Whether it deserves its own, explicit listing or whether it should be folded 
into one of the other entries (such as the current 3.2.2) is another matter. It 
seems to get enough attention to warrant being cited on its own, but I do see 
your point that it feels different from the other 'operational' goals.  I am not 
sure how to reconcile that.

Do you see the current Overview document form as doing any particular damage to 
one's understanding of DKIM?

d/

-- 

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

---

From: Jim Fenton <[email-masked]>
Date: Mon, 24 Mar 2008 22:35:00 -0700

Dave Crocker wrote:
>
>
> Jim Fenton wrote:
>> Most of the sections under 3.2, "Operational Goals", are really goals 
>> in the sense of "I want a mechanism that...".  So "I want a mechanism 
>> that permits incremental adoption for incremental benefit" makes 
>> complete sense.  As does "I want a mechanism that minimizes the 
>> amount of required infrastructure."
>>
>> But section 3.2.1, "Treat verification failure the same as no 
>> signature present" doesn't strike me as a goal, but rather a 
>> consequence of the way that the mechanism works.  I would probably 
>> rather have something that can treat verification failure more 
>> harshly, but it doesn't work that way.  This really ought to be 
>> merged with section 5.4, "Unverified or unsigned mail" instead.
>
> Let's try to tackle your last point, first.  Section 5.4 is a 
> description of the architecture.  It's certainly a reasonable place to 
> observe that failures are treated the same as no signature, as indeed 
> 5.4 does.  However that is different from describing higher-level 
> goal-like issues, which is what section 3 is intended to be.  By 
> 'higher-level' I mean the stuff of significant constructs that 
> motivate the work.
>
> Now to your primary point:  DKIM's treating failures the same as 
> no-signature is an unusual characteristic that captures folk's 
> interest. From a pedagogical point of view, it warrants highlighting 
> as an distinctive construct.
>
> Whether it deserves its own, explicit listing or whether it should be 
> folded into one of the other entries (such as the current 3.2.2) is 
> another matter. It seems to get enough attention to warrant being 
> cited on its own, but I do see your point that it feels different from 
> the other 'operational' goals.  I am not sure how to reconcile that.
>
> Do you see the current Overview document form as doing any particular 
> damage to one's understanding of DKIM?

It's just that the other goals sections do a good job of stating the 
value proposition of DKIM, and this is a different sort of thing that I 
think waters down what is otherwise a very strong section of the 
document.  If you can't come up with another place to cite it on its 
own, I'd suggest listing it as the last rather than the first 
Operational Goal.

-Jim