Dave,
I agree that there are separate threats issues with the DKIM base protocol.
That should be worked out.
But I don't agree that SSP is far less understood. I'm an implementer. It
is clearly understood and it sounds to me that there are many others who
clearly understand it and more importantly, its value.
This is more about understanding the impact and your willingness to accept
the level of impact it will have at its various levels. "Who moved my
cheese?" Keep in mind as an implementator, I am the among the last set of
people who want to break things for customers!
To me, this is an easy exercise. It is about defining a signing protocol
(BASE). That is the easy part. But it also about defining how to obtain a
payback value from it (SSP) in a maximized backward compatible manner.
You can sign or tag or do whatever you want. It is meaningless, if it
doesn't have a signer verification concept and if you want implementations
to begin supporting this, you will need to provide a reason for it.
Otherwise, it just more junk passed thru.
SSP needs a break down of each policy to see what the threat and impact per
policy. So I agree the threats/impact for the base system should worked out
separately. I think its possible to get the core design worked out, because
SSP needs it. SSP is just more about honoring the policies that the core
helps creates.
So here is what I suggest:
DKIM Core Signing - Threats and Impact
DKIM Core Verification - Threats and Impact
DKIM SSP Verification - Threats and Impact
Divide and conquer!
--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com
----- Original Message -----
From: "Dave Crocker" <dhc(_at_)dcrocker(_dot_)net>
To: "Douglas Otis" <dotis(_at_)mail-abuse(_dot_)org>
Cc: "IETF-DKIM" <ietf-dkim(_at_)mipassoc(_dot_)org>
Sent: Friday, November 18, 2005 11:12 AM
Subject: [ietf-dkim] Expediting the threat analysis for -core
Folks,
My impression is that the threat analysis for SSP is far, far more
challenging than for the core DKIM services. At the least, this is
because
we understand SSP far less.
This means that having the threat analysis document include the SSP area
of
concerns is certain to protract producing the document. Since the threat
analysis document is in the critical path of producing the core document,
that means delays in getting out the base specification of the working
group.
Methinks it worth considering de-coupling things at the TA level, not just
the specification level.
d/
--
Dave Crocker
Brandenburg InternetWorking
<http://bbiw.net>
_______________________________________________
ietf-dkim mailing list
http://dkim.org
_______________________________________________
ietf-dkim mailing list
http://dkim.org