Subject: RE: [ietf-dkim] user level ssp

From: Arvel Hathcock <[email-masked]>
Date: Thu, 07 Sep 2006 12:30:00 -0500

> At base the former seems to move SSP from being a basic means of 
> checking for rogue mail, into recruiting the receive-side to be an agent
> of the From-field domain owner, for enforcing potentially complex 
> operational rules. 

IMO, "recruiting the receive-side to be an agent of the From-field domain owner" probably goes too far.  I certainly don't feel I am an "agent" of the RFC2821.mail domain owner when I do my SPF checks.  Nor am I the servent of the PRA by virtue of doing Sender-ID.  Rather, those who employ SSP are "agents" working on their own behalf in an attempt to utilize another authenticity vector in order to provide the most trustworthy mail service they can.

"for enforcing potentially complex operational rules" - SSP is simply an gathering mechanism.  Any complex operational rules are at the discretion of the receiver post-SSP right?

> Absent compelling demonstration of market need, 

I believe that the need and duty to protect ones domain from unauthorized use is (or should be) presuppositional and therefore needs no demonstration.  However, are you saying that the market has no need for SSP?  What constitutes "compelling" and are we qualified to determine that in the IETF?

> why are we considering something that, to my knowledge, 
> has no experiential base for the scale and complexity 
> of the open Internet?

SPF provides, at least partially, the experiential base for something like SSP doesn't it?  It is deployed widely, is DNS based, and is more complex than SSP.  Yet the market seems to have embraced it.

-- 
Arvel 

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

---

From: Dave Crocker <[email-masked]>
Date: Sat, 09 Sep 2006 09:22:07 -0700

Arvel,

Arvel Hathcock wrote:
> "for enforcing potentially complex operational rules" - SSP is simply
> an gathering mechanism.  Any complex operational rules are at the
> discretion of the receiver post-SSP right?

I sure hope so.

Therefore, each proposed SSP flag needs to be evaluated in terms of the 
receive-side's view of cost/benefit.

    How beneficial is it likely to be seen as being?

    How is it likely to get used by receive-side sytems?

    What is our basis for believing these answers?

> I believe that the need and duty to protect ones domain from
> unauthorized use is (or should be) presuppositional and therefore
> needs no demonstration.  However, are you saying that the market has
> no need for SSP?  What constitutes "compelling" and are we qualified
> to determine that in the IETF?

I certainly did not say that the problems SSP seems to be trying to 
solve are not problems.  Nor did I say that every SSP feature is 
problematic.

I have two, basic concerns with the discussions so far:

1. DKIM-Base permits specification of an accountable identity, whereas 
SSP is trying to detect invalid identities.  These are very different 
goals.  The latter is complex, subtle and involves quite a bit of human 
factors for which society, as a while, actually has a mixed record. This 
makes the topic extremely problematic.

2. The discussion has been covering many different issues, so we seem to 
be conflating things quite a bit.  Worse, the discussion is often not 
very precise about the details of need, use or benefit.

>> why are we considering something that, to my knowledge, has no
>> experiential base for the scale and complexity of the open
>> Internet?
> 
> SPF provides, at least partially, the experiential base for something
> like SSP doesn't it?  It is deployed widely, is DNS based, and is
> more complex than SSP.  Yet the market seems to have embraced it.

There is a sizable installed base of SPF records, although adoption has 
tapered off. In any event, it tells us only about publishing, i.e., 
send-side.

It does not tell us about receive-side efficacy.

I do not recall seeing reports about the impact of SPF on detection of 
bogus mail.

d/

-- 

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