[ietf-dkim] "I sign everything" is not a useful policy

[Damon]

+1

 I don't agree with everything in DSAP and would take you to task on one or two.
However, I believe that it is doable in our lifetimes and if we worked
really hard, could be worked out in this working session. Without it,
SSP's a big piece of duct tape.

Regards,
Damon Sauer

On 8/6/06, Hector Santos <hsantos at santronics.com> wrote:
>
> ----- Original Message -----
> From: "Dave Crocker" <dhc at dcrocker.net>
> To: <ietf-dkim at mipassoc.org>
> Sent: Sunday, August 06, 2006 5:37 PM
> Subject: Re: [ietf-dkim] "I sign everything" is not a useful policy
>
>
> > Rather than cross over the line into that bit of architecturally
> > experimental specification, why is is not sufficient to leave things
> > with the simpler -- albeit more passive -- stance that a sender talks
> > about themselves but refrains from telling the evaluator what to do
> > with the information?  Yes, that is at odds with a classic model of
> > protocol specification, but we are juggling among
> > constraints, here.
>
> In my view, the power of DKIM-SSP is 100% about protocol consistency.  I
> don't wish to be redundant, but this is how the DSAP introduction concludes:
>
> [you may substitute DSAP for SSP]
>
>   DSAP does not attempt to evaluate the reputation of the sender or
>   client.  A good intention client can use DSAP as well as the bad
>   intention client.  The main objective of DSAP is to establish a
>   protocol consistency between all client types and to use the
>   deviation from the consistency as part of a failure detection system
>
> This is not different  than any other C/S negotiation handshake concept
> such as with the PPP protocol where there is a LCP stage to negotiate the
> link. If the expected link attributes are not met, the connection is not
> made.
>
> It was not different as with IEMSI (pronounced I-EM-SI) in the old fidonet
> days where the common storage,  the NodeList (akin to DNS)  describes the
> host server capabilities and attributes.  Both the client and server know
> what was expected.
>
> Similarly,  it is no different when an SMTP client calls a SMTP host and the
> host exposes its EHLO capabilites which the client works with.  If the
> client does something the server did not expect, we can presume there will
> be some level of protocol inconsistency and failure.   But if the client
> sends a fraudulent HELO or a RETURN PATH and the server doesn't check them,
> well, then we have problems like we have today.
>
> SSP Policies and attributes are defined by the owner in some common storage
> we call DNS,  The owner uses them to create DKIM data. The verifier, if it
> cares for security, which I presume it will,  will uses them to confirm the
> DKIM data, if any.   If something is not quite kolsher, the natural
> presumption is to assume a failure.
>
> Now the real question here, is it practical?  Is it feasible?  It is doable?
>
> For me, as a practioneer in the field,  I say yes.  It is possible and the
> implementation code is really quite simple.
>
> --
> Hector Santos, Santronics Software, Inc.
> http://www.santronics.com
>
>
>
>
>
> _______________________________________________
> NOTE WELL: This list operates according to
> http://mipassoc.org/dkim/ietf-list-rules.html
>