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
