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