On Sun, 2006-01-08 at 14:19 +0000, Stephen Farrell wrote:
5. Derived Requirements
This section is incomplete, but was added in response to a specific
request. It makes sense to me because we're doing this before the WG
takes up the base and SSP drafts. To some extent we get to define
what's in the threat analysis document, so if there is consensus (and
agreement from the chairs) that we don't need this section, I'll make
it go away.
Well, I'm not so sure about that, since that section could be useful
later on.
The idea is that that section would contain whatever security (or
other I guess) requirements that we derive whilst doing the threat
analysis. Then when we're about at last call on the standards track
documents, we can check back and see if that document meets the
relevant requirements derived from the threat analysis. If it does,
fine. If not, then we should justify the divergence or fix something.
I'd personally rather we tried this and if its not turning out to
be useful (i.e. if we can't fairly easily derive some testable
requirements) then at that point we can delete the section or put
in some text as to why we're not deriving requirements.
Stephen.
PS: The charter does say we'll do/try this too.
Could threats and derived requirement issues be split into separate
drafts?
1) Threats and security concerns specific to the base DKIM
signature.
2) Threats and security concerns related to DKIM extensions:
a) authorization
b) abusive replay abatement
c) assurances for email-addresses
Splitting this effort should add clarity. Open issues should be noted
in the first DKIM threat draft. With a compilation of open issues
determined by this effort, extensions addressing these issues could be
analyzed in a subsequent and separate draft. This should allow the base
draft to make better progress. This would also delineate the benefits
and limitations of the base DKIM signature. The alternative of
combining this effort into one draft would be discussing complex issues
as general concepts, with a strong presumption of there being a forgone
conclusion.
The current combined approach seems to have reached an erroneous
conclusion. An email-address authorization scheme based upon the From
header does not provides adequate protections for the email-address
domain owner and the recipient. This approach also currently overlooks
issues related to the disruption of current practices and the potential
for the misuse of open-ended authorizations. Extensions to DKIM are
equally complex and deserve examination, just as the base draft does.
The base draft however is better defined with a better underlying
consensus, and thus more amenable to meaningful review. Solutions to
the open issues hopefully are still on the table.
-Doug
_______________________________________________
ietf-dkim mailing list
http://dkim.org