[ietf-dkim] "I sign everything" is not a useful policy
hsantos at santronics.com
Sun Aug 6 20:09:06 PDT 2006
----- 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
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.
More information about the ietf-dkim