Subject: [ietf-dkim] draft-otis-dkim-adsp-sec-issues-01 updated to include an error and omission section

From: Douglas Otis <[email-masked]>
Date: Mon, 18 Aug 2008 03:36:43 -0700

http://www.ietf.org/internet-drafts/draft-otis-dkim-adsp-sec-issues-01.txt
http://www.sonic.net/~dougotis/id/draft-otis-dkim-adsp-sec-issues-01.html

This draft is a response to:
http://www.ietf.org/internet-drafts/draft-ietf-ssp-05.txt

This version adds a section titled errors and omissions regarding  
ssp-05.  This draft also attempted to simplify the description of the  
underlying problem.  This draft likely requires another pass when I  
can find the time.

In essence, dkim-ssp-05 imposes a complex signature validation process  
that depends upon the recipient's discovery of advertised practices.   
Only if, or when, practices are discovered at the domain in question  
would additional requirements be imposed upon the From header field.   
Since signature validation and advertised practice discovery likely  
occurs post message acceptance, ensuring remote signing agents are  
required to have the From header field match against the restricted  
identity should help mitigate exposures caused by stolen or abused  
remote signing agent keys.

By always imposing a From header field requirement for signing agents  
with identity restricted keys, what is defined as a valid signature  
remains consistent throughout all stages of verification.  This change  
would also allow the on-behalf-of identity to always track with _what_  
the signing domain authenticated when accepting the message for  
signing, and not have this limited to being just the From email-address.

A scheme that depends upon the availability of DNS to impose  
additional requirements may invite DNS related attacks.  Dependence  
upon advertised practices also makes securing messages signed by  
remote signing agents fairly impractical since this requires  
publishing a practice at every existing node within the domain.

Two minor changes to the definition of a valid signature within this  
draft provides a simple solution that should be easy to apply prior to  
message acceptance.  The definitions do not depend upon any advertised  
practice being discovered.

My apologies for the poor quality of this draft.

-Doug

_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html