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; > [email protected];" 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; [email protected];". > 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 [email protected] and that of a user of example.com, such as: Sender: [email protected] From: [email protected] dkim-signature: [email protected]; [email protected]; 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
