----- Original Message ----- From: "Jim Fenton" <[EMAIL PROTECTED]> To: "Stephen Farrell" <[EMAIL PROTECTED]> Cc: <[email protected]> Sent: Thursday, November 03, 2005 11:27 AM Subject: Re: [ietf-dkim] DKIM proposed charter tweak
> I really like Hector's table, and the terminology he has introduced to > make it easier to talk about the SSP policies. I think we still need to > talk through the specifics of the table once we get chartered, as there > will be some disagreement over the content of specific cells. For > example, I'm not convinced of the utility of the "weak" policy. But > that's good stuff to address once we get chartered. > > However, as Hector says, "How a system reacts is implementation and > local policy based." I'm concerned that the specificity of the table > will lead people to think it's cast in stone. It's not. We need to be > careful about the way we frame it. > I was hoping to extract the states in the ideal model which should initially excludes fuzzy and subjective interpretations. Once this is sorted out, then it can be fine tuned into a practical implementation model. This allows you to perform model simulation to quickly recognize what are the failure points, the impact and design requirements. It helps prepare you for a "Threat Analysis." Example: The technical question for the software algorithm would be what happens if a 3rd party signature exist but the SSP has a WEAK policy definition? From a ideal modeling of the protocol standpoint, it is a violation of the domain specification to have this type of transaction. That's the theory. Now we begin to discuss it from a practical standpoint and we may decide to relax or remove this policy condition. However, when you do, you need to also recognize this creates a threat Entry Point. Once the threat is recognized, you might tweak the protocol so its no longer a threat entry point. So the idea of whether a WEAK policy has an valid SSP place, should not be a concern yet, as it is a possible situation that can occur. We need to work out the consistency of the ideal model first. In this case, I concur with Arvel's proposal for a WEAK SSP policy because it is a very real possible form of transaction. This can help alleviate some concerns with roaming users using domains on email services. With WEAK, the domain is declaring that the signature is optional, but only the OA domain can sign the transaction. Email Services are allow to use the domain on behalf of the user but it should not sign the message. If the DKIM ready Email Service chooses to ignore the SSP policy by signing it, then we have a Threat Entry point. The point is that, at this point, not yet, I think we should avoid the politics and merits of whether the email service should or can ignore it or whether it is good or not to do SSP, but rather recognized what are the results if the ideal modeling and implementation is not perform. Following this approach in my engineering research of DKIM, showed me the SSP requirement, not an option to reduce a significant amount of the threat entry points. That is all I am trying to extract from all this at this point. For the record, we design, developed and sell: - A List Server - A SMTP server - A Gateway for multiple Offline and Online MUAs DKIM with SSP will entail a tremendous amount of work for us. So for us, there has to be a high payoff that a) solves a major email fraud problem and b) the customers are very comfortable with. I also have to be able to promote it too. It would be very disappointing if major work is done and no one uses it. In my view, DKIM without SSP will offer little value, not scale well and increase deception since the odds will be very good that DKIM sans SSP will produce a high level of spoofing simply because spammers know the receivers will not be required or expected to do any SSP verification. -- Hector Santos, Santronics Software, Inc. http://www.santronics.com _______________________________________________ ietf-dkim mailing list http://dkim.org
