On Feb 25, 2008, at 3:35 PM, Jim Fenton wrote: > Doug, > > Much as I appreciate your personal appeal, it's really the rough > consensus of the working group, and not my opinion, that matters.
Jim, Thank you for your feedback. Of course consensus matters, but so does compatibility with RFC 4871. The SSP-03 draft will cause valid DKIM signatures applied by the From domain to be non-compliant with SSP "all" assertions. This happens when the i= parameter is used to indicate the on-behalf-of user/agent, but this identity does not represent the From email-address. Domains attempting to clarify which identities have been authenticated by setting the i= parameter are prevented from doing so without applying multiple signatures, or leaving user/agent identities ambiguous. Use of multiple or ambiguous signatures creates new risks. > If I understand correctly, the difference between the approach you > favor and the one that I favor is as follows: > > Approach A (favored by Doug): Check the g= tag on the key referenced > by a valid signature, if present, compare it to the local-part of a > From address to determine if the signature is an Author Signature. No, the g= tag is to be used by untrustworthy systems. When the key g= tag restricts the identity, and the i= identity is not found within the From header, even a valid signature MUST BE considered to have UNKNOWN DOMAIN SIGNING COMPLIANCE. It does not matter whether the domain makes policy assertions with respect to this specific and unusual case. This type of signature MUST BE excluded from being considered compliant with any domain policy, and SHOULD NOT cause trust for the domain to be applied. After excluding restricted key signatures containing a non-From header identity from being considered DOMAIN COMPLIANT, then only the domain of the signature, and the domain of the From header email-address require evaluation. This approach permits the i= parameter to _always_ represent the user/agent without the identity even being contained within the message itself. The A Approach is thus far more compatible with RFC 4871. > Approach B (favored by Jim): Compare the i= value on a valid > signature (or its default value) against a From address; if the i= > value has a local-part, then it must match the local-part of that > From address. This is directly in conflict with RFC 4871's definition for the i= parameter. > If there is a g= tag in the key, then there must be a matching local- > part in the i= of the signature in order for the signature to be > valid, so the approaches are approximately equivalent in this case. > > If there is not a g= tag (or if its value is *), and if there is no > local-part in the i= of the signature, then the approaches are also > equivalent. > > The difference appears when there is not a g= tag (or if its value > is *) and the i= contains a local-part. Approach A would consider > this to be an Author Signature regardless of the local-part, and > approach B would only consider this to be an Author Signature if the > local-parts match. This overlooks the exclusion that any evaluation process should make. In the Approach B, the UNKNOWN DOMAIN SIGNING COMPLIANCE when the key g= tag restricts the identity, and the i= identity is not found within the From header is never notices unless policy is being evaluated. This makes Approach B less safe, and less compatible with RFC 4871. > My rationale for B is that it allows a domain to apply a signature > not representing an author sharing the domain. Approach B may require an ambiguous signature or two overlapping signatures. In the case of just a single ambiguous signature, the identity of the user/agent on whose behalf the signature was added must be guessed by looking for headers that might exist above the From header. Requiring two signatures may tend to prevent in session evaluations from being practical. In essence, Approach B requires possible removal of information permitted by RFC 4871 from the signature, where restoration of this information may necessitate a second signature. > While we haven't gone through the details of how mailing list > signing might work, there might be times when such an agent might > want to sign a message, but explicitly not as the author. It also > does not require the retention (or re-retrieval) of the key > information in evaluating whether something is an Author Signature. Approach A requires restricted keys for non-From identities to be noted, but this notation SHOULD BE done regardless of any policy assertion. For Approach A, beyond that specific notation step, only the domains of the signature and the From email address then play a role in signature compliance. > As I understand it, your rationale for A is that it allows the local- > part of i= to be used for an opaque tag representing but not > revealing the identity of the user or agent for which the signature > is being applied. Exactly. This parameter is the _ONLY_ identity currently defined upon which a verifier may employ to defend against abuse related to compromised systems or malicious users having the freedom to use any From header address they wish. A user's freedom to use any From email-address is independent of the signing domain's policy assertions. > My response to this is that there are lots of other places an opaque > tag could be put, since it is local to the use of a particular > domain, and can be done without interfering with the ability of a > domain to sign as other than an author. Only Approach B interferes with an ability to identity the agent/ user. No other tags have been defined for this purpose. Defining yet another tag for the same purpose is not needed when compatibility with RFC 4871 is retained. -Doug > > > -Jim > > Douglas Otis wrote: >> Jim >> >> As the cut-off approaches, this is an appeal for you to reconsider >> where agreement might be found. >> >> Risks associated with the use of g= restricted keys signing >> messages where i= identities are not found within the From header >> exists whether policy is asserted or not. A g= restricted key >> signifies the signing is restricted due to limited trust. In other >> words, the message signed by such keys may not be controlled by the >> domain's signing practices, whether any policy records are >> published or not. >> >> Being aware of the risk associated with local-part restricted keys >> REQUIRES the presence of this restriction be indicated the DKIM >> validation process, or this risk can not be accurately assessed. >> The risk related to the use of g= restricted keys does not change >> substantially when the domain also asserts they sign "all" >> messages. Domains asserting such policy are also likely more >> cautious about the distribution of these local-party restricted >> keys. Why limit weighing this risk with local-part restricted >> keys to just rare situations where domains assert a DKIM policy? >> Otherwise, use of restricted local-parts not within the From header >> is likely indicative of messages attempting to phish or spam using >> keys purloined from someone's laptop. >> >> You seem fairly determined to keep your version of the "Author >> Signature" definition you feel designed to address this concern, >> but only in fairly limited situations. This definition, in many >> cases, prohibits use of user/agent specific information regarding a >> token directly associated with signatures without also implementing >> multiple signatures, or expecting verifiers to guess identities by >> picking the higher header within the message header stack. This is >> most unfortunate, as the value DKIM may have had in curbing abuse >> depends, to a substantial degree, upon the definition expressed >> within RFC 4871 for the i= parameter. This definition permits the >> i= parameter to serve as a token for the entity introducing the >> message (on whose behalf the signature was added). This token >> enables simpler feedback reports, and defensive measures that can >> be used by receiving domains. "They can use multiple signatures >> when they wish to be specific" sounds too much like "let them eat >> cake." This statement represents an excuse for an awkward and >> erroneous definition that overlooks the intent of RFC 4871, and the >> increased overhead, complexity, and risk. >> >> A defence afforded by meaningful tokens of the user/agent is not >> affected by a value being opaque and matches nothing within the >> message. Such an opaque value would be compliant with RFC 4871. >> The i= identity's real value is found as a token that can track >> sources within a domain of compromised systems. Whether the token >> represents an obscured machine or person does not matter. Even an >> i= identity changing every day still provides useful information >> when dealing with large domains where blocking at the domain is >> truly onerous. >> >> In addition, the Author Signature restatement of the definition for >> the i= parameter is plain wrong. One can not say the i= parameter >> represents on whose behalf the signature was added, and then say >> this identity must also represent the email-addresses found within >> the From header. Such a definition must be wrong in many cases. >> DKIM is not about ensuring that the identity of an individual >> matches that of an email-address contained with the message. Such >> matching is completely optional, since DKIM is _not_ attempting to >> replace S/MIME or OpenPGP. As such, there is no reason for DKIM >> policies to then stipulate what identities are permitted to >> represent the on-behalf-of entity. The recognizable identity >> offered by DKIM is the _DOMAIN_. >> >> Your Author Signature definition forces recipients into guessing >> which header might contain the identity on whose behalf the >> signature was added. This may happen when, to be compliant with >> the Author Signature definition, the signature remains ambiguous as >> a path of least resistance. Guessing identities then opens the >> door for spoofing, especially when multiple signatures are added, >> but perhaps in the wrong order. It is ironic most DKIM messages >> are not processed during the SMTP transaction, where a policy >> definition expecting use of multiple signatures only makes this >> goal less obtainable. This definition causes the signature >> processing overhead to be more complex, and more error prone, and >> less safe. Anyone using DKIM naively thinking that, because they >> sign all their messages using RFC 4871, they can then make a DKIM >> policy assertion they sign "all" their messages, will be in for a >> rude awakening due to your definition of Author Signature. >> >> -Doug >> >> >> >> _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
