[ietf-dkim] [Fwd: I-D ACTION:draft-fenton-dkim-threats-02.txt]
dotis at mail-abuse.org
Sun Jan 8 14:18:12 PST 2006
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.
> PS: The charter does say we'll do/try this too.
Could threats and derived requirement issues be split into separate
1) Threats and security concerns specific to the base DKIM
2) Threats and security concerns related to DKIM extensions:
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
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.
More information about the ietf-dkim