Subject: Re: [ietf-dkim] I-D.kucherawy-dkim-reporting

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 16 Jun 2008 09:46:24 -0700 (PDT)

On Mon, 16 Jun 2008, Douglas Otis wrote:
>> It's not worthless to an implementor or administrator interested in 
>> figuring out why his/her mail isn't verifying properly.
>
> And to resolve such issues, knowing which Key Domain is being used is 
> still important, but nonetheless ignored.  If fact, the key domain is 
> likely needed to resolve issues for organizations that use sub-domains!

And the key domain is included in what the revised ARF stuff reports! 
Amazing!

>> Any developer would love to have as much of the original data as possible 
>> to reconstruct the failure scenario.
>
> Your strategy appears to ignore the _least_ easily changed identifier 
> validated by a DKIM signature.

No it doesn't.

To reconstruct a validation failure, I need all of the inputs to that 
algorithm as the verifier saw them.  This proposal provides them.  It 
really is as simple as that.

> While such a scheme might be seen as Sender friendly if adopted, this 
> would doom DKIM.  Selectors devoid of the publishing domain offers no 
> value.  To suggest otherwise would be in support of a false premise.

Indeed.  But I haven't done that.
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Douglas Otis <[email-masked]>
Date: Mon, 16 Jun 2008 08:42:25 -0700

On Jun 16, 2008, at 1:13 AM, Murray S. Kucherawy wrote:

> On Thu, 12 Jun 2008, [email-masked] wrote:
>> Adding to this, Murray Kucherawy's draft captures the i= (identity)  
>> parameter and a worthless s= (selector) parameter.  The s=  
>> parameter offers little value since the d= (key domain) parameter  
>> is missing. Only the d= parameter (upon which the s= parameter  
>> rests) represents a domain validated by a verified signature.
>

> Any developer would love to have as much of the original data as  
> possible to reconstruct the failure scenario.

Your strategy appears to ignore the _least_ easily changed identifier  
validated by a DKIM signature.  Controlling resource costs for  
collecting and distributing defensive information _requires_ stable  
identifiers.  Without some level of identity stability, any defensive  
strategy will _explode_ due to enviable abuse.  No database scheme can  
scale to accommodate virtual identifiers that only exist within a  
message!

> Not everything in this working group is about crypto and security.   
> We implementors do sometimes think about other things.

-Doug

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 16 Jun 2008 01:13:58 -0700 (PDT)

On Thu, 12 Jun 2008, [email-masked] wrote:
> parameter and a worthless s= (selector) parameter.  The s= parameter 
> offers little value since the d= (key domain) parameter is missing. Only 
> the d= parameter (upon which the s= parameter rests) represents a domain 
> validated by a verified signature.

It's not worthless to an implementor or administrator interested in 
figuring out why his/her mail isn't verifying properly.  Any developer 
would love to have as much of the original data as possible to reconstruct 
the failure scenario.

Not everything in this working group is about crypto and security.  We 
implementors do sometimes think about other things.
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html