[ietf-dkim] new issue: requirement to enumerate receiver side benefits of SSP?

[Bill.Oxley at cox.com]

Any harm would come from benign harm, misconfigured SSP and misled
receiver policies.

Mal harm would be from spoofing authors thru valid 3rd party signers 
From: joe at foo.com
Sender: signer at bar.com
DKIM: valid signature

When bar.com SSP states I sign all mail, foo.com has no SSP entry and
joe at foo.com didn't author the message

Im sure there is other harmful methods

Bill Oxley
Messaging Engineer
Cox Communications
404-847-6397

-----Original Message-----
From: ietf-dkim-bounces at mipassoc.org
[mailto:ietf-dkim-bounces at mipassoc.org] On Behalf Of Michael Thomas
Sent: Thursday, November 30, 2006 12:11 PM
To: dcrocker at bbiw.net
Cc: ietf-dkim WG
Subject: [ietf-dkim] new issue: requirement to enumerate receiver
sidebenefits of SSP?

Dave Crocker wrote:
>
>
> Michael Thomas wrote:
>> Hi,
>>
>> One of the things I noticed from recent discussions is that we need
to
>> have clarity in SSP on what, exactly, qualifies as a valid signature
for
>> "I sign everything". 
>
>
> Michael,
>
> To carry your point farther than I suspect you intend:
>
> From the virtually all of the SSP discussions, including recent 
> exchanges, I keep thinking that we are starting with mechanism and 
> only secondarily worrying about utility.  Hence the grou confusion 
> that is persistent.
>
> Some folks think of SSP as being for unsigned mail.  Some folks think 
> of SSP to facilitate end-user interpretation.  Some folks think...  
> And so on.
>
> What we do not seem to have is anything that looks like a clear 
> consensus about what problem is being solved and why it will be useful

> to solve it.
>
> Until the group settles on specific benefits to be obtained, for which

> there is a solid basis to think recipient operators will find them 
> useful, we are chasing our collective tail.
>
> I suggest that discussion about technology -- that is, mechanisms -- 
> should be deferred until the receive-side benefits (and, for that 
> matter, the receive-side consuming component) are established.
Dave --

I view this exercise as a largely unproductive rathole. I think there's 
been a consensus
for quite a while that the information provided would be interesting to 
a pretty widely
varying set of people. Like dkim-base, I don't think we need to 
enumerate with any
precision what those benefits are as will undoubtably fall into the 
false dilemma of
trying to rank them, categorize them, etc. I can't see how that is 
helpful because it's
very clear that that way consensus does not lie. Nor need it, IMO.

On the sender/signer side there is a fairly simple benefit: SSP is an 
information
service which domains publish to give receivers more accurate details 
for their
delivery decisions. Nothing more. I think that's pretty much all of the 
justification
we need.

Much more interesting in my mind is whether there's potential *harm*
that
might come from SSP, and if so whether the draft can do anything to 
avoid that
harm, how likely the harm would be, etc.

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