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

[Douglas Otis]

On Sep 18, 2006, at 5:27 PM, 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.

Strict policy can not be applied for normal use.  Only strict  
2822.From policy can act as a basis for rejection, but this does not  
permit non-compliant services that will continue to be used for a  
long time.  In addition to the 2822.From domain setting a strict  
policy, the receiver must also hunt for 2822.From policy for each  
2822.From email-address.  In the normal case, there will not be any  
policy record.  The distribution of 2822.From email-addresses is  
greater than that of sending agents.  Even when a record is  
published, the effort represents a sizable burden upon the receiver  
in terms of resources, where seldom would there be any actionable  
information obtained that could resulting in blocking anyway.   
Annotation allows this process to be much more selective, and affords  
greater and more secure protections.

> 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).

It is my understanding the powers-to-be decided coping with  
transition is not needed at this time.  Store and forwarding  
protocols do not allow for negotiations, which necessitates  
conveyance of deprecation information.

>> 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".

Policy can be applied just as easily to the 2821.Mail_From in  
addition to the 2822.From.  A label of the associated signed-domain  
could be base32 encoded as a SHA-256 + CRC32c to ensure a  
deterministic 58 octet label size.  Any different domain would be  
required to satisfy two different algorithms simultaneously, where  
the possibilities should be sufficiently small.

   <base32 SHA-256 + CRC32c>._DKIM-mf.<mail-from domain>.

> 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).

When the 2822.From is associated with that of the signing domain via  
DKIM-MF policy, the 2821.Mail-From is assured and can be safely used  
in a DSN.

> 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).

This is something DKIM-MF policy can safely provide.  RFC4408 enables  
various DDoS and DNS poisoning attacks as previously described.   
However, a single record policy as illustrated above would not induce  
these serious issues.  The DKIM signature and the DKIM-MF policy  
record provides the requisite association for safe DSNs.  In lieu of  
RFC4408, DKIM safely improves a chance of receiving a DSN, which is  
when the DKIM-MF policy might be checked.

>> 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).

There is a broader issue being missed.  As with SPF et al, the desire  
was to bring accountability to the originator.  Just as with these  
other protocols, this will not work with DKIM either for the same  
reasons.  From our data, rejections based upon a "soft-fail" + "fail"  
only block about 9% of spam, while also imperiling DNS  
infrastructure.  When based upon just the "fail" as commonly required  
to avoid delivery issues, less than 3% of spam is blocked.  The DSN  
DDoS concern can be addressed using DKIM and a 2821.Mail_From DKIM  
policy record as described above without incurring genuine risks or  
violating proprietary algorithms.  To prevent spoofing, nothing beats  
annotation of retained email-addresses.

>> 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.

For the policy requirements, the desire to have customers provide  
delegations to their provider completely overlooks this MUST  
however.  Here policy based associations would be vastly safer.  As  
Olbermann would say, the batteries are in backwards; designations are  
significantly safer than delegations.  In either case, the signing  
domain must be trusted to act based upon the 2822.From address by  
limiting the account and selecting the signing-domain.  With DNS  
delegation, the provider must be trusted to use the correct signing- 
domain which imposes far greater risks.  In any realistic way of  
evaluating risk, DNS delegation increases risks for the 2822.From  
domain.  It would be desirable to have had semantics defined that  
allowed the provider to explicitly assert which email-address had  
been restricted, but that information can also be deduced by a  
2822.From policy association as well.  Designation simply imposes  
different provider expectations.

In either case, the provider is being trusted when designation or  
delegation is used.  There is far greater risks for both the provider  
and the 2822.From domain owner when a DNS delegation method is used.   
With DNS delegations, the provider may not see abuse reports and the  
2822.From domain owner may be attributed for having signed messages  
they did not originate, and will not have logs to prove otherwise.

>> That 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.

The threats draft missed that the sending agent must be held  
accountable and that the DKIM signature can not play this role.  As a  
result of this oversight caused by understatements of replay concerns  
among others such as use of annotations, the threat draft offers poor  
guidance for the policy effort.  The policy requirements draft  
appears to be a continuation of this short-sighted view. : (

-Doug