Douglas Otis wrote:
On Aug 24, 2005, at 11:14 AM, Scott Kitterman wrote:
What you are asking is what won't SSP accomplish. It's difficult to
answer those questions before the design work is done. So lets quick
arguing about if it should be done. Get it done and see what it buys
us.
Before setting out on change, establish realistic expectations.
Currently your conversations should be related to that goal. What will
domain-wide assertions accomplish? What threats will this address?
There are a few areas where domain-wide assertions relating to use of a
protocol could be beneficial, such as when detecting unauthorized
servers. Beyond the immediate domain and server, things are rather murky.
BTW, I find it an interesting perpective that I am arguing in favor of
doing DKIM as presented by it's authors and you are not and yet you
attempt to justify placing the burden of imposing change on me.
Spend some effort explaining what you envision.
Provide realistic assessments of what it can accomplish with respect to
current problems.
Play devil's advocate with what new risks could be created.
When you say get 'it' done. I can only guess what you mean. Hardly a
basis for a charter. : )
It meaning the design of SSP.
What I think we can accomplish is an anti-forgery linkage between what
is signed and what is visible to the user (the domain part of the
address, not the local-part and not the pretty name) that will enable
automatic, deterministic rejection of some forgeries that cannot be
reliably rejected today.
I expect this to enable domain owners to better protect (to a degree)
their domains from forgery, phishing, and joe-jobs.
To give an example, if I receive an e-mail from a domain such as e-bay
(i.e. 2822-From: [EMAIL PROTECTED]), Ebay has published a restrictive SSP
that says messages are all signed, but please don't accept 3rd party
signing, I want to be able reject the message at SMTP time if it is
either unsigned, 3rd party signed, or has a broken signature.
On the other end of the spectrum, I want to reject messages during SMTP
that the SSP says never send mail.
There are gradations in between.
I expect that this type of capability will force forgers, phishers, and
joe-jobbers to move to other attacks less likely to be successful. In
other words, I expect them to shift from forms that are the most likely
to be successful social engineering experiments to riskier, less
sucessful forms.
The risk is that there could be a false sense of security since the
protections I envision as being feasible have substantial limitations.
This is all conceptually in the DKIM-SSP draft, so I don't know why you
feel like I need to explain it.
As I said before, let's just agree that there is work yet to be done on
SSP and quite arguing about if it should be done.
I'm really getting tired of trying to answer your handwaving about why
this is a bad idea. Just as a comparison between your gloom and doom
about the administrative burdens associated with SSP, I think that SSP
could be far simpler to deploy and maintain than SPF records and yet
that far more complex technology is one that hundreds of thousands of
domain owners have found worth the trouble.
Scott Kitterman
_______________________________________________
ietf-dkim mailing list
http://dkim.org
