----- Original Message -----
From: "Dave Crocker" <dhc(_at_)dcrocker(_dot_)net>
To: <ietf-dkim(_at_)mipassoc(_dot_)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