[ietf-dkim] Expediting the threat analysis for -core
hsantos at santronics.com
Fri Nov 18 08:54:33 PST 2005
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
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.
----- Original Message -----
From: "Dave Crocker" <dhc at dcrocker.net>
To: "Douglas Otis" <dotis at mail-abuse.org>
Cc: "IETF-DKIM" <ietf-dkim at mipassoc.org>
Sent: Friday, November 18, 2005 11:12 AM
Subject: [ietf-dkim] Expediting the threat analysis for -core
> 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
> we understand SSP far less.
> This means that having the threat analysis document include the SSP area
> 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
> Methinks it worth considering de-coupling things at the TA level, not just
> the specification level.
> Dave Crocker
> Brandenburg InternetWorking
> ietf-dkim mailing list
More information about the ietf-dkim