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