[ietf-dkim] [Fwd: I-D ACTION:draft-fenton-dkim-threats-02.txt]

[Douglas Otis]

On Jan 9, 2006, at 10:45 AM, Stephen Farrell wrote:

>
> Doug,
>
> Douglas Otis wrote:
>>
>> In several places within the current draft, declarations of  
>> benefits  assume a particular extension, SSP.  The benefits,  
>> related  limitations, caveats, and extension specific threats  
>> should be placed  into separate sections.   The list of _possible_  
>> extensions should  not be limited to just that currently defined  
>> in SSP.
>
> While I'm not sure I agree with your list (its too long for a  
> start), I do think that the less that the threats document assumes  
> about ssp, the better it'll be. So structuring it so as to be vague  
> in respect of ssp may be the right thing to do.

The general sections should be vague (make no assumptions of  
benefits, etc),  but a section specific to a range of options that  
would fall under the general SSP email-address authorization scheme  
should be mentioned there.


> I also agree that the list of possible extensions should not be  
> limited so ssp-only, but I do not agree (if you're saying so) that  
> the document has to treat each potential extension equally.

The long list was to indicate the many possible uses of the base DKIM  
signature.  Compiling the list of positive and negative aspects of  
these various choices could help select/justify the final choice(s).   
There should not be any need to treat each option equally, as some  
will have disqualifying aspects which preclude any further exploration.


> I think the wg should guide the author on the level of detail, and  
> there are clearly more than a couple of folks who consider that  
> something-like-ssp is a fairly criticial extension (yes, I know  
> there is at least one who thinks the exact opposite:-), and  
> something-like-ssp was part of the BoF and is part of the charter  
> so it won't go away just now.

Agreed.  This section for email-address authorization could include:

1) Risks associated with the misuse of "open-ended" authorizations.
2) The disruption caused by "closed" authorizations.
3) Possible coercive ratings when not publishing the record.
4) Exploitation of "open-ended" authorization being unfairly  
attributed to the mail-address domain owner.
5) Overhead when most records are not present for the email-addresses.
6) Label depth found in abusive email versus legitimate email.
7) Accommodating "closed" policies at the Mediator.
8) Increased overhead checking multiple From addresses. (Defeating 7)
9) Dictionary attacks of local-part authorizations.
10) Unintended DoS for short TTLs with authorizations.


> But before anyone starts drafting other extensions, I'd expect that  
> any other extension proposed would have to fit with the charter and  
> be addressed in sequence (i.e. earliest after the base is done) and  
> needs significant enough buy-in from the wg generally. If, for  
> example, you were to continue to develop your opaque-id ideas  
> outside the wg and then bring a more mature draft back to the wg  
> after wg-last-call on the base draft, then you might well get a  
> much better reception than if you tried to get that work done here  
> and now. (Or maybe not, I don't know.)

The threat draft should speculate about actions and counter-actions,  
so considering a wider range of mechanisms may help flush out  
neglected aspects to ensure there are fewer surprises.  Of course an  
individual writing an extensions draft to explain a mechanism does  
not mean this will become a WG draft.  Not writing the draft however  
would ensure just the opposite.

Consideration should be given with respect to rehabilitating a domain  
that has an inordinate number of signed messages being used  
abusively.  Any avenue where there is no defense will quickly become  
a busy highway of abusive traffic.

-Doug