On Mar 12, 2009, at 6:24 AM, MH Michael Hammer (5304) wrote: > From: Douglas Otis, Mar 11, 2009 7:40 PM >> On Mar 11, 2009, at 11:59 AM, MH Michael Hammer (5304) wrote: >>> >>> If the DKIM-Signature header field does not contain the "i=" tag, >>> the verifier MUST behave as though the value of that tag were >>> "@d", where "d" is the value from the "d=" tag. >> >> A signature lacking an i= value defaults to the d= value, but this >> does not represent a From email-address! As someone said, domains >> do not write emails, which leaves the "on-behalf-of" identity >> *undefined*. > > Whether i= or d=, when I go to look for the ADSP record I'm only > looking at the RHS of the address. Therefore, what does it matter if > a signature lacking an i= defaults to d=? Logically, unless I have a > constraining g value and even then (note well): <key g definition > elided >
> Domains sign mail. Unless you can show that every user has access to > creating/modifying the keys in DNS. You have provided nothing that > shows there is an issue. Is this agreement with removing dependence upon the i= value? >>> There is nothing special about a DKIM signature missing an i= >>> filed. One simply uses the d= field. Seems pretty straight forward >>> to me. >> >> Why must an i= value only represent a From email-addresses when >> present, when it is equally okay for the i= value to be omitted? >> When a DKIM public key imposes a g= restriction, the i= value MUST >> contain the restricted local-part or the DKIM signature WILL NOT be >> valid. > > So what's the problem? Do you expect domains publishing an ADSP > policy to intentionally not provide an i= value and include a g= > value? The original motivation for ADSP imposing i= value dependence was in hope of causing non-From-g-restricted-signatures to be rejected. Ironically, few domains will double-sign exceptions to ADSP's requirement that i= values must matching against a From email- address. In effect, this inhibits both the intended use of the i= value and ADSP. If few domains use ADSP, few receiving MTA will reject messages on the basis of non-From-g-restricted-signature non- compliance with ADSP. When MUAs annotate using Authentication-Results headers, non-From-g- restricted-signatures represent less risk since MUAs can still determine the intended identity, whether the identity is the list- manager as Sender or the From header. Currently, ADSP dependence upon the i= value may require inclusion of a DKIM signature where the i= value is omitted, which can not be done by a non-g-restricted- signature. If non-From-g-restricted-signatures represent a significant risk, they should be considered invalid by the base specifications! > I admit that there will always be some people who will screw things > up regardless of how careful a framework is constructed and how many > warnings and cautions are provided...... so what? It's kind of like > publishing an SPF record that consists of only "-all" and then > complaining that people are not accepting your mail. By removing i= dependence, an ADSP assertion of "all" could then mean _all_ messages are signed. This reduces mistakes and keeps things simple, while also eliminating possible double signing requirements. >> It will be evident to an MUA whenever a restricted local-part does >> not match against a From header. It should also be safe for an MUA >> to annotate signed headers that match against the i= value, but not >> those that do not match, such as when the i= value is omitted or it >> omits everything but the d= value. In such cases, just the domain >> might be annotated. > > And where is the problem? Go do the lookup against the d= domain. > That is what the default is. Notwithstanding the g tag constraint, > this works fine thank you very much. In order to exclude non-From-g-restricted-signatures, all i= values that do not match against the From header must currently be double signed. This additional requirement is a problem when few wish to double sign otherwise perfectly valid DKIM signatures. >> In either case, the i= value (on-behalf-of identity) might become >> declared as being opaque and thus defined as not representing a >> specific email-address. When the i= value is declared opaque, no >> email-address should be annotated, even when it happens to match >> against the i= value. > > Conflating layers. Just because DKIM base considers it an opaque > value does not mean that ADSP must consider it an opaque value. By > choosing to publish an ADSP record one is at least indicating that a > receiver (again excepting the g tag case you specified with no i= > present - a quite artificial construct that should fail) should look > at the RHS of the string called an RFC2822From email address. ADSP records are not checked when there is a valid Author Signature. An Author Signature IS a DKIM signature! If i= values are always declared opaque, rather than conditioning opacity on not matching against a signed header email-address, then g-restricted-signatures will become a meaningless mechanism. Security must be reviewed in light of this mechanism being made meaningless. >>>> Since the ADSP draft is already internally in conflict on this >>>> point, a simple solution would be to drop the i= value >>>> requirement in ADSP. >>> >>> I see no conflict. >> >> Oops. This has been corrected off-list since version 6. Section >> 3.2 now states Author Signature. Well, Section 3.2 will need to >> change back to Author Domain if or when i= value dependence is >> removed. >> >> By removing the i= dependency from ADSP, the assertions of "all" or >> "discardable" could then apply to any DKIM signature by the domain. > > As I have written multiple times (and I'm getting tired of > repeating), while simply using d= works fine for me, using i= can > make deployment easier for quite a few domains without any > significant downside other than causing some people to get ruffled > feathers that DKIM base considers the i= string opaque for it's > purposes and ADSP imposes a constraint (for those domains which > choose to publish ADSP records) with regard to checking against the > RFC2822From email address (RHS). ADSP is not independent of DKIM. Removing ADSP dependence on the i= value enables acceptance of non-From-g-restricted-signatures. This will not affect any sub-domain convenience, nor will it lead to exploits that can not be mitigated through refusal of non-From-g- restricted-signatures or use of Authentication-Results headers. -Doug _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
