On Sat, 2006-02-11 at 23:09 -0800, Jim Fenton wrote:
The threat document is an analysis of DKIM, not systems that encompass
DKIM in concert with other mechanisms such as SenderID, SPF, and CSA.
This was a concern raised regarding the impact of message replay abuse,
which is definitely part of the threat draft. _You_ have suggested in
the past, the message replay abuse problem could be resolved with
SenderID when used in conjunction with DKIM.
Verification of the HELO can happen in many ways. There was not any
mention of how this would be done.
If there is anyone else on the list who feels that this should be looked
at more closely, please speak up. Otherwise, I will assume that there
is a lack of consensus on this change (although I will leave it to the
WG chairs to formally make that determination).
The introduction of the threat draft established an expectation of DKIM
used as a basis for acceptance. There should be a section that focuses
upon threats related to that specific use. At the least, there should
be an attempt to explain how message replay abuse will not affect the
acceptability of the sign-domain, the basis for your Low impact rating.
There are three basic issues raised, where some solutions were suggested
to resolve these issues. Why should major issues should be left
unresolved, if only in theory? This is not the protocol draft.
-Assessing the signing-domain using only signed message content is
difficult, and will likely include the unsigned message envelope.
-The message path as described by SenderID (when mediators are
blocked), or a list of HELOs could offer a means to bypass a defensive
strategy that delays acceptance to avoid an abusive message replay
threat.
-A desire to sign all messages will likely include unvetted sources,
and a proper signing-domain assessment (not prone to corruption) will
require time.
For statements that are not understood, a specific question usually
helps.
-Doug
_______________________________________________
NOTE WELL: This list operates according to
http://dkim.org/ietf-list-rules.html