ietf-dkim Digest, Vol 108, Issue 2 Send ietf-dkim mailing list submissions to 	gfky-hddl@mipassoc.org To subscribe or unsubscribe via the World Wide Web, visit 	http://mipassoc.org/mailman/listinfo/ietf-dkim or, via email, send a message with subject or body 'help' to 	qvci-mnfi-qkwxudx@mipassoc.org You can reach the person managing the list at 	qght-rnrq-bhlpv@mipassoc.org When replying, please edit your Subject line so it is more specific than "Re: Contents of ietf-dkim digest..." Today's Topics:    1. SSP-02 the problem with Author Signature (Douglas Otis)    2. Re: SSP-02 the problem with Author Signature (Douglas Otis) ---------------------------------------------------------------------- >From udcat@mail-abuse.org  Sat Apr 26 15:50:00 2008 Message: 1 Date: Mon, 18 Feb 2008 15:33:54 -0800 From: Douglas Otis  Subject: [ietf-dkim] SSP-02 the problem with Author Signature To: DKIM List  Message-ID: <568BFD6A-292E-46B4-B766-BCABB4AB120C@mail-abuse.org> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Per RFC 4871: The signature's i= parameter is "expected" to contain on-behalf-of   information: ---- i=  Identity of the user or agent (e.g., a mailing list manager) on   behalf of which this message is signed... . INFORMATIVE DISCUSSION: This document does not require the value of   the "i=" tag to match the identity in any message header fields. This definition is fairly useful since it allows signing domains to   provide a reporting token within the i= parameter for verifiers to use   to identify the agent creating a problem.  This token can be obscured   and be a transient hash of the account used to access their outbound   servers, for example. SSP-02: 2.8. Author Signature   An "Author Signature" is any Valid Signature where the identity of   the user or agent on behalf of which the message is signed (listed in   the "i=" tag or its default value from the "d=" tag) matches an   Author Address (From header email-address) in the message. 3.3. SSP Record Syntax "all" All mail from the domain is signed with an Author Signature. Translation: Only signatures on-behalf-of the From header email-address are   considered compliant with an "all" SSP policy.  This is in conflict   with RFC 4871.  Not all signatures are on-behalf-of the entity   represented by the From header, of course.  Essentially, this   necessitates the i= parameter not be used when the identity might   conflict with the identity contained within the From header.  The i=   parameter, as the only parameter defined as providing a higher   granularity of the message sources, will no longer be useful in these   cases.  How does this help verifiers cope with abuse?  It doesn't. Per RFC 4871, a signature is valid when the signed on-behalf-of   identity, the i= parameter, does not relate to the From header email-  address.   However, the SSP-02 definition prevents the i= parameters   from being useful in this role.  As a result, in many cases, this   parameter is now unable to identify the actual agent or user who   introduced the message when using an obscured hash of the identity the   agent when it is related to the Resent-From or Sender header. -Doug ------------------------------ >From udcat@mail-abuse.org  Sat Apr 26 15:50:00 2008 Message: 2 Date: Tue, 19 Feb 2008 03:04:08 -0800 From: Douglas Otis  Subject: Re: [ietf-dkim] SSP-02 the problem with Author Signature To: Douglas Otis  Cc: DKIM List  Message-ID: <6B3D6655-BF96-4216-9E16-A6B0DF3C5A25@mail-abuse.org> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Expanding upon the effect of the SSP-02 Author Signature definition   based upon a conversation with Jim... Jim suggested that to comply with SSP-02, signatures will not make use   of the i= parameter, since the i= parameter is needed only for g=   restricted keys. Instead of a practice that offers an explicit token (even one that is   opaque) identifying the user/agent that introduced the message, once   again examining the header stack and guessing which header might apply   again becomes necessary.  It is also unknown whether the entire header   stack will have been captured within the signatures hash, so this   guessing may also be prone to the introduction of spoofed headers   while attempting to resolve top most identifiers. Secondly, this also means that MUAs attempting to highlight who the   signature indicates as having introduced the message is also prone to   getting this wrong, because the signature's identity (i=) MUST BE   absent whenever the entity introducing the message is _not_   represented by the email-addresses within the From header. : ( Although unlikely, some domains may feel compelled to sign the message   twice.  One signature to comply with the SSP-02 Author Signature   definition, and another to clarify who actually introduced the   message. : ( As a result, instead of DKIM offering a "reportable" or "displayable"   identifier clarifying who introduced the message, this identifier must   again be guessed. : ( Jim's example as to why this definition is needed offers yet another   problem with this scheme. In Jim's example, there are users and a mail-list in example.com.    Example.com SSP asserts they sign "all" messages. Messages signed by the mailing-list contain the identifier of "mailing-  list" that is not found within the From/Sender/Resent-* headers,   whereas all the "user" messages will be signed with the i= parameter   either containing the identity within the From header, or left blank,   especially when the user is represented by a header further up the   header stack. It is unknown whether the entire stack is included   within the signature hash, so again guessing is needed when selecting   a specific top most identifier and might be prone to spoofing.  When   the i= parameter is blank, the identity of who introduced the message   is in doubt.  In addition, messages signed by the mailing-list are   also non-compliant with the "all" signed assertion, so they are likely   to be rejected. The goal of this scheme was to "protect" the From line in a message   for all legacy MUAs.  This does not work. Protecting the From line MUST BE the role of the signer, and not that   of the verifier.  The signer should not offer keys to untrustworthy   entities.  When i= points to the Sender header, and this key is g=   restricted, and the From header contains a user within the domain,   message filtering will be able to identify this type of message as   being fairly odd, and modern MUAs will be able to highlight the   identity, making this message also appear odd to the recipient.  IMHO,   RFC 4871 should have declared such non-From header signatures with g=   restricted keys as being invalid. The g= restricted key used for non-From headers represents the corner   case of all corner cases.  This extremely odd use is the primary   reason for the extremely convoluted Author Signature definition. Recommendation: 1) Change "Author Signature" to "Author Domain Signature". 2) Change "Author Signing Policy" to "Author Domain Signing Policy". 3) Accept the premise that when the "Author Domain" signs the message,   the message is complaint with the "Author Domain's Signing Policy" _by   definition_. 4) Only when the message is not signed by the "Author Domain", is the   "Author Domain Signing Policy" in need of checking. -Doug ------------------------------ _______________________________________________ NOTE WELL: This list operates according to  End of ietf-dkim Digest, Vol 108, Issue 2 *****************************************