Eric, I think optimization should be put to the side for the moment to consider what are all the risk for not checking the SSP. Once all the risk are addressed programmatically (protocol wise), then of course, optimization should be considered. But you have to look at the worst case first. What at the risk, if any, of not checking the SSP? How do you know that a original legitimate 3rd party signer is not some how cracked outside of the DNS record itself, but the record does say, it doesn't allow 3rd party signing? Of course, one can argue that a cracker that smart will even bother dealing with an exclusive domain policy, but the worst cases still needs to be analyzed.
-- Hector Santos, Santronics Software, Inc. http://www.santronics.com ----- Original Message ----- From: "Eric Allman" <[EMAIL PROTECTED]> To: "Scott Kitterman" <[EMAIL PROTECTED]> Cc: <[email protected]> Sent: Tuesday, August 09, 2005 6:45 PM Subject: RE: [ietf-dkim] DKIM Threat Assessment v0.02 (very rough draft) > > I would have thought that validating something that the user > > actually sees would have been a primary goal? > > Not directly. The signature has an identity associated with it; that > identity (in the DKIM-Signature header field) is not displayed to the > end user, at least in the current generation of MUAs. However, we > fully expect (and encourage) verifiers to have some sort of policy > for associating a right to use a visible with the signature identity. > Such association should be driving by the Sender Signing Policy > (SSP). There is one escape clause: if the signing identity is > identical to the identity in the From header field, the verifier > doesn't have to consult the SSP. Since we expect this to be the > usual case, it should substantially improve performance. > For example, a domain might be willing to permit a Trusted Third > Party (TTP) to sign on behalf of that domain. Similarly, large > companies often have several-to-many domains (e.g., movie producers > that buy domain names for each movie); they may do promotional > mailings under a domain name different than the individual vanity > domains. More prosaically, a sender may wish to assert that they do > (or do not) permit Sender header fields that differ from the From > header field. > > So although we /do/ expect that the user will see useful information, > it isn't part of the base spec. Indeed, in a world with good > reputation systems, it may be that the signing identity will be used > solely for automated filtering --- if the message is signed by a > player known to be honest and upright and a non-spamming, > non-phishing pillar of the community, that may be good enough, and is > actually more friendly for the naive user who just wants their > mailbox to be clean. _______________________________________________ ietf-dkim mailing list [email protected] http://mipassoc.org/mailman/listinfo/ietf-dkim
