----- Original Message -----
From: "Jim Fenton" <fenton(_at_)cisco(_dot_)com>
To: "Stephen Farrell" <stephen(_dot_)farrell(_at_)cs(_dot_)tcd(_dot_)ie>
Cc: <ietf-dkim(_at_)mipassoc(_dot_)org>
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