[ietf-dkim] Re: requrements-01// security concerns regarding policy domain designations rather than delegations

[Stephen Farrell]

Frank,

You may have missed my reply to Doug on this thread. Please read
that and try to move the discussion on to issues that we can track
and resolve. There has already been plenty of open ended discussion
and now its time to get the ssp-reqs document done and move on the the
protocol.

Thanks,
Stephen.

Frank Ellermann wrote:
> Douglas Otis wrote:
>  
>> DKIM is unrelated to the message envelope
> 
> True, more below.
> 
>> Requiring the 2821.Rcpt To to match a 2822.To or CC header
>> field email-address is not practical.
> 
> Of course, anything not matched is by definition a BCC.
> 
>> Any assumption that a DKIM signature can be used as a basis
>> for acceptance or rejection introduces very serious denial of
>> service issues.
> 
> It's THE job of SSP to change this.  Or maybe ONE job, this
> algorithm transition stuff is also relevant, but I don't care
> where and how it's done (as long as Phil says that it's okay).
> 
>> The DKIM signature does safely permit the following when a
>> signing domain has been designated by an email-address:
> 
> [...skipping annotation...]
>>   - Safe DSNs based upon 2821.Mail Froms.
> 
> No, as you said above "DKIM is unrelated to the"..."envelope".
> 
> To avoid abusive DSNs to innocent bystanders you always need a
> verified Return-Path.  Minimally you've to trust that it's no
> nonsense (e.g. if it came from a source where that's hopefully
> guaranteed).
> 
> If you think that _DKIM_ (not the cases discussed in 4408+4409)
> safely permits safe DSNs I'd like to know how that's supposed
> to work.  IMO it simply does not allow this, and that's no bug
> or bad thing, it's a consequence of the "unrelated" (to SMTP).
> 
>> There should be a general understanding of the futility and
>> perils using a DKIM signature as a sole basis of acceptance
>> or rejection.
> 
> If a policy makes 2822-compatible statements about signatures,
> then using it isn't futile or perilous.  Nobody's forced to
> publish dangerous policies, nobody's forced to evaluate them,
> this is a completely voluntary business, same idea as SPF (or
> SenderID, modulo its known IAB-appeal IESG-note fine print).
> 
>> Abuse MUST be handled by identifiers tracking the actual
>> sending agent.
> 
> Maybe, but that's not a "MUST" for SSP reqierements, it belongs
> into another document like 2821bis or BASE.
> 
>> What are the underlying security concerns related to some
>> email-address policy and how can security be generally
>> improved upon by this policy?
> 
> Isn't that already covered by the threats RFC ?  For the "SSP
> requirements" it would be a waste of time if it tries to list
> all potential security considerations of a future SSP proper.
> 
> Frank
> 
> 
> _______________________________________________
> NOTE WELL: This list operates according to 
> http://mipassoc.org/dkim/ietf-list-rules.html
>