[ietf-dkim] basic question

[Douglas Otis]

On Jan 17, 2007, at 10:39 AM, Scott Kitterman wrote:

> On Wed, 17 Jan 2007 10:18:32 -0800 Douglas Otis <dotis at mail-abuse.org>
> wrote:
>>
>> DKIM's restrictions on linking signatures with a header was premised
>> upon an expectation that visual examination of headers provided a
>> means for recognition.
>
> Would you please point me to a reference for this statement?
>
> I recall saying 2822.From should be signed because it's a mandatory  
> element
> of an e-mail message.  You seem to remember a different WG  
> discussion than
> I do.

Here is the base draft description of use based upon annotation:
---
Appendix C.
...
The MUA may choose to highlight, accentuate, hide, or otherwise
display	any other information that may, in the opinion of the MUA
author, be deemed important to the end user.
---

To better understand the signature selection process, the basis is  
the trusted email-address as clearly indicated in the newly added text.

---
4.1
...
				
Another related example of multiple signers might be forwarding			
services, such as those commonly associated with academic alumni			
sites.			
				
INFORMATIVE EXAMPLE: A recipient might have an address at			
alumni.example.edu, a site that has anti-abuse protection that is			
somewhat less effective than the recipient would prefer. Such a			
recipient might have [specific authors] whose messages would be			
trusted absolutely, but messages from unknown authors which had			
passed the forwarder's scrutiny would have only medium trust.

4.2
...
When evaluating a message with multiple signatures, a verifier  
SHOULD	 		
evaluate signatures independently and on their own merits. For			
example, a verifier that by policy chooses not to accept signatures			
with deprecated cryptographic algorithms would consider such			
signatures invalid. Verifiers MAY process signatures in any order of			
their choice; for example, some verifiers might choose to process			
[signatures corresponding to the From field] in the message header			
before other signatures. See Section 6.1 for more information about			
signature choices.
---

So how is the signature confirmed to correspond with the From header  
when ALL signatures must include the From header?  The answer is that  
the contained email-address MUST be within the domain of the DKIM  
signature.  Ask yourself why this restriction was imposed.  This will  
mean that a large email provider's outbound servers may contain  
thousands of other domain's private keys!  How quickly can all those  
domains recover from a breach in this server's security when each  
change might require the coordination of more than two entities?  Who  
signed the message will be what recipients will want to know, but  
they will also need to know which Selector was used for each of the  
many different domains.  What a complete and utterly ridiculous mess!

The far safer alternative would be to allow the DKIM signature to  
clearly indicate on who's behalf the signature was being applied,  
irrespective of the email-address's domain.  This would allow the  
verifier to weed through what might be a mess of signatures and  
thereby avoid DDoS exploits.  When desired, allow the email-address  
domain to associate with the signing domain, perhaps by using a SHA1/ 
base32 tag of the signing domain. (Same overhead as a CNAME.)  If a  
server becomes compromised, only one private-key is compromised, and  
the users of that service can quickly and autonomously respond  
without needing to coordinate these changes to restore security.  The  
security update report will only need to list the one domain that was  
compromised and not thousands with all their respective Selectors.   
Why should DKIM be allowed to make MTAs such a high level security risk?

-Doug