On Jun 16, 2009, at 10:51 AM, SM wrote:
At 08:00 16-06-2009, Cullen Jennings wrote:
My focus is mostly on what this errata means to implementations in
the field. That would be implementations of both DKIM the narrow
signing protocol and implementations that use the information DKIM
provides. I think the document should be clear on
The proposed update does not affect the DKIM verification process.
It can affect the DKIM signing process and the post-verification
process. I'll use your message as an example. The DKIM-Signature
header for your message contains "d=cisco.com;
i=fluffy(_at_)cisco(_dot_)com;" According to RFC 4871, the domain is taken
from the "i=" tag and in the absence of that tag, we fallback to the
"d=" tag. For this message, we would use "cisco.com" for the
assessment. I'm taking a narrow view of the assessment.
It was pointed out that some DKIM signers use a DKIM-Signature
header such as "d=example.com;
i=fluffy1(_at_)core5(_dot_)example(_dot_)com;".
According to RFC 4871, we would use ["core5.example.com"] as the
domain for the assessment. With the proposed update, the "i=" tag
and the fallback behavior is ignored. We use "example.com" for the
assessment.
Correct, but this change would reduce DKIM protections!
The intent of the i= parameter is to permit finer grain header and
intra-domain resolution. This resolution ability is lost when always
defaulting to the use of d=. The use of the d= parameter does not
differentiate between a mailing list of
forum(_at_)core5(_dot_)example(_dot_)com and
that of a user of example.com, such as:
Sender: forum(_at_)core5(_dot_)example(_dot_)com
From: jon(_dot_)doe(_at_)example(_dot_)com
dkim-signature: i=forum(_at_)core5(_dot_)example(_dot_)com;
d=forum(_at_)example(_dot_)com;
Neither reputation OR annotations are better handled when limited to
JUST the d= parameter.
The i= parameter, when not included, would be "@<d=value>". This is
the only time that d= should be used!
Some DKIM signers may have to change the way they were signing
messages if they are passing domain related information through the
"i=" tag instead of the "d=" tag. The DKIM post-verification
process also has to be modified to pass the domain from the "d=" tag
instead of the one from the "i=" tag.
This does not work unless separate sub-domain and selectors are setup
to contain separate keys. This also means that users of example.com
messages will have a valid signature when signed by a subdomain of
example.com. As such, this type of change will necessitate the use of
sub-domains and multiple signatures, which the i= conventions would
have avoided.
1) what is the interoperability problem. Can someone succinctly
See the above example.
The above example creates problems. It does not solve any. The i=
value remains optional, and does default to the d= value anyway!
summarize this? When I read the document, I get that there is a
problem but it less clear what it is or why some implementation
would end up doing something that did not work with other
implementations.
Some people got creative. :-)
Some people are attempting to mitigate intra-domain spoofing. A REAL
problem! DKIM is better than path registration, so don't emasculate
this difference!
2) what needs to be changed in implementations to fix this? Again,
can anyone succinctly summarize this. I do not think an implementor
that
See the above example.
did not follow the list could easily read the current draft and
figure out if there code was OK or not and what changes where
needed to their code to make it OK
To keep it simple I'd say "use the d= tag only".
This will not allow domains that might have an intra-domain problem
from establishing finer grain resolutions, or to clarify whether a
message was sent on-behalf-of their list, or on-behalf-of some user
within their domain.
I'm not really sure what you mean by a reputation intent and non-
repuation intent or when a signer or verifier would want one or the
other.
reputation intent - help us blacklist, whitelist you, etc.
non-reputation intent - the DKIM signer placed some obfuscated
information in the "i=" and it was probably not meant to be used for
reputation.
Yes, the i= value CAN be used for intra-domain reputation. This would
occur only when the domain is otherwise good, but when there might be
problems with some accounts having fun with replay abuse.
-Doug
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html