Re: [ietf-dkim] RFC4871bis - whether to drop -- k: Key type
Another way to look at it is that k= is useless, but it's not harmful, so it'd be more productive to argue about the warts that are both useless and harmful. I don't know that it's completely useless, but I'll defer to Jon on this point: Is the actual cost of parsing k=rsa from the key and a=rsa-blah from the signature substantially less than trying to feed a non-RSA-key blob into an RSA function only to have it error out? If detecting that the key and the signature are incompatible before actually trying to use the crypto functions involved actually saves substantial compute cycles then I'd say it's not useless. Otherwise I believe it's redundant and can be removed. I thought for a while that this had the same purported attack vector as has been claimed for h=, but now I'm convinced otherwise. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] RFC4871bis - whether to drop -- h: Acceptable hash algorithms
-Original Message- From: Douglas Otis [mailto:do...@mail-abuse.org] It seems suitable to either reject or annotate a stern warning, those messages where the domain refutes the algorithm claimed in the DKIM signature. Doug, I'm still not convinced, but you have me thinking about it. You're claiming that an attacker might craft a message claiming to use a hash called something like MD6, and the absence of h=md6 in the corresponding key named by d= and s= in the signature should cause a rejection or an appropriate annotation. But that would presuppose the a= in the signature contains something like rsa-md6 and, further, that the verifier knows what that means. Otherwise, wouldn't the verifier in that case just kick the signature out claiming an unknown signing algorithm? Given that there are currently only two possible values for a= in a signature, the only actual attack vector here is an rsa-sha1 signature from a site that claims h=sha256 or vice-versa. Is that still something about which we should be concerned? -MSK ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] chained signatures, was l= summary
On Fri, 05 Jun 2009 18:27:06 +0100, Doug Otis doug.mtv...@gmail.com wrote: On Jun 5, 2009, at 6:36 AM, Charles Lindsey wrote: No, that is NOT what section 1.6 of RFC 5451 says. It requires removal of any pre-existing A-R header claiming to be valid with in its [the ADMD's] boundaries, which essentially means (AIUI) any A-R header that might be mistaken for one that might/would/should have been created within that same ADMD. By selecting specific A-R headers to remove, header content might be processed post delivery, and then appear to match against some trusted domain. For sure, individual recipients may wish to check signatures etc. for themselves, espeicially if they have doubts about the policies applied by their local assessors. If the local assessor has unnecessarily removed sone A-R that is actually covered by the signature, then that becomes impossible. And if they have doubts about the policies of sone earlier mailing list expander, they might wish to see exactly what that expander had actually done to the message. For such forensic investigations, removing useful information (aka dumbing down) is always a dumb thing. The safest solution would be to remove _all_ A-R pre-existing A-R headers from different environments ... But that's not what the standard says. Note that Appendix B.6 of RFC 5451 contains an example exactly equivalent to the one I have just given, including the retention of A_1 (and even S_1). IMHO, appendix B.6 is overly optimistic for today's environment. Maybe so, but that document is a proposed standard, and unless you have plans to get it revised, we must try and work with it as it stands. Nothing in that example is contrary to what that standard says normatively. -- Charles H. Lindsey -At Home, doing my own thing Tel: +44 161 436 6131 Web: http://www.cs.man.ac.uk/~chl Email: ...@clerew.man.ac.uk snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K. PGP: 2C15F1A9 Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5 ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] chained signatures, was l= summary
By selecting specific A-R headers to remove, header content might be processed post delivery, and then appear to match against some trusted domain. I believe the Security Considerations of RFC5451 covers this adequately. For sure, individual recipients may wish to check signatures etc. for themselves, espeicially if they have doubts about the policies applied by their local assessors. If the local assessor has unnecessarily removed sone A-R that is actually covered by the signature, then that becomes impossible. +1 The safest solution would be to remove _all_ A-R pre-existing A-R headers from different environments ... But that's not what the standard says. +1 IMHO, appendix B.6 is overly optimistic for today's environment. Have you seen actual attacks like this in the wild already? Maybe so, but that document is a proposed standard, and unless you have plans to get it revised, we must try and work with it as it stands. Nothing in that example is contrary to what that standard says normatively. +1 (BTW, does this still qualify as being on topic for this list?) ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] RFC4871bis - whether to drop -- h: Acceptable hash algorithms
On Jun 8, 2009, at 2:53 AM, Murray S. Kucherawy wrote: -Original Message- From: Douglas Otis [mailto:do...@mail-abuse.org] It seems suitable to either reject or annotate a stern warning, those messages where the domain refutes the algorithm claimed in the DKIM signature. Doug, I'm still not convinced, but you have me thinking about it. You're claiming that an attacker might craft a message claiming to use a hash called something like MD6, and the absence of h=md6 in the corresponding key named by d= and s= in the signature should cause a rejection or an appropriate annotation. But that would presuppose the a= in the signature contains something like rsa- md6 and, further, that the verifier knows what that means. Otherwise, wouldn't the verifier in that case just kick the signature out claiming an unknown signing algorithm? Given that there are currently only two possible values for a= in a signature, the only actual attack vector here is an rsa-sha1 signature from a site that claims h=sha256 or vice-versa. Is that still something about which we should be concerned? This feature provides a means to thwart exploits that will likely leverage an introduction of a new algorithm. Email is replete with examples of adoption taking years. As such, Jon is wrong about there only being two states for a signature. As you have indicated,three states are already supported : 1) Invalid 2) Valid 3) Algorithm Refuted While initially, Algorithm Refuted may not play a major role, in the coming years it might. No one can predict the future, so why not be prepared? After all, the DKIM standard will need to retain the tags for this feature. This feature assists with a difficult problem created by the lack of negotiations for algorithm support between sender and receiver. Since DKIM strives to be widely applied and relied upon, providing a means to improve algorithm agility remains prudent, nor is having this feature in place harmful. This feature provides an enhanced agility only when senders start asserting algorithms not initially listed by the standard. This feature becomes especially useful when these new algorithms are not always supported receivers, such as the example of MD6. Since all compliant deployments of DKIM support both sha256 and sha1, this feature does not offer an value at this time. In these cases, the receiver should be able to determine whether the signature in invalid. This feature will have value only when a new algorithm is asserted by the sender that is not supported by the receiver. In the case of a new algorithm, only the domains using the new algorithm would be exposed to bad actors spoofing their new algorithm. These domains should be able to take additional steps, such the inclusion of as pass-phrases, to mitigate the potential spoofing. Without this feature, other domains would be unable to refute the use of the new algorithm, and so email handling would be unable to refuse what should have otherwise been detected as an obvious spoof. -Doug ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] chained signatures, was l= summary
On Jun 8, 2009, at 3:24 AM, Charles Lindsey wrote: On Fri, 05 Jun 2009 18:27:06 +0100, Doug Otis doug.mtv...@gmail.com wrote: On Jun 5, 2009, at 6:36 AM, Charles Lindsey wrote: By selecting specific A-R headers to remove, header content might be processed post delivery, and then appear to match against some trusted domain. For sure, individual recipients may wish to check signatures etc. for themselves, espeicially if they have doubts about the policies applied by their local assessors. If the local assessor has unnecessarily removed some A-R that is actually covered by the signature, then that becomes impossible. The use of the DKIM l=, z= and x= features provide a means for recipients to separately evaluate DKIM signatures without reliance on intermediary assessors. In addition, the A-R header does not capture the IP address when assessing path registration protocols, which means that safe recipient reassessment might only be possible in the case of DKIM or reverse DNS. And if they have doubts about the policies of sone earlier mailing list expander, they might wish to see exactly what that expander had actually done to the message. For such forensic investigations, removing useful information (aka dumbing down) is always a dumb thing. Removal of foreign A-R headers provides better security. Since A-R header fails to capture source IP addresses for path registration schemes, the forensic value of this header is very limited, to the point of being dangerous. Reliance upon the A-R header offers providers permission to modify messages. Some providers offer their services free, however there remains a profit motive where their security may overlook embedded iFRAMEs referencing malware injected into one of their third-party ad servers. A-R header may indicate to recipients that the message originated from Big-Bank, but ads might appear from a different entity. In this case, the goal of DKIM is has been lost. Unfortunately, the introduction of ads is fairly common, and the authserv-ids may not offer a means to consolidate or identify who is being trusted. There are significant risks and problems created when dealing with A-R headers. DKIM without A-R headers does not invite questionable practices likely to create many duped victims. An appearance of a message being from someone trusted can be worse than a message with an unknown status when the content source is in doubt. The safest solution would be to remove _all_ A-R pre-existing A-R headers from different environments ... But that's not what the standard says. Wrong. See RFC 5451 section 5, complete removal is suggested for maximum security. It also suggests: A more robust border MTA could allow a specific list of authenticating MTAs whose information should be let in, removing all others. Note that Appendix B.6 of RFC 5451 contains an example exactly equivalent to the one I have just given, including the retention of A_1 (and even S_1). IMHO, appendix B.6 is overly optimistic for today's environment. Maybe so, but that document is a proposed standard, and unless you have plans to get it revised, we must try and work with it as it stands. Nothing in that example is contrary to what that standard says normatively. No. Nor does the RFC warn of encoded headers or header reordering. Headers may be altered during handling. In addition, the Trust Environment can use any type of token, and not just those derived from a host name. The lack of uniformity or standardized means of ensuring uniqueness means little should be assumed regarding any A-R header not generated by the receiving MTA. -Doug ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] chained signatures, was l= summary
The use of the DKIM l=, z= and x= features provide a means for recipients to separately evaluate DKIM signatures without reliance on intermediary assessors. In addition, the A-R header does not capture the IP address when assessing path registration protocols, which means that safe recipient reassessment might only be possible in the case of DKIM or reverse DNS. [...] Could we please not re-re-re-rehash these A-R issues on ietf-dkim? They were already covered on mail-vet-discuss more times than I can count. The archives of that list are public in case anyone really needs to go through them all again. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] chained signatures, was l= summary
On Jun 8, 2009, at 3:37 PM, Murray S. Kucherawy wrote: The use of the DKIM l=, z= and x= features provide a means for recipients to separately evaluate DKIM signatures without reliance on intermediary assessors. In addition, the A-R header does not capture the IP address when assessing path registration protocols, which means that safe recipient reassessment might only be possible in the case of DKIM or reverse DNS. [...] Could we please not re-re-re-rehash these A-R issues on ietf-dkim? This was in response Charles making the statement: For such forensic investigations, removing useful information (aka dumbing down) is always a dumb thing. These headers represent an active and potentially hazardous component used in email annotation. Unless the border MTA is willing to assert the A-R headers not removed are safe, the A-R headers should be removed. The point of rehashing information excluded from the A-R header was to emphasize the point that these headers were not intended to play a role in forensics. Otherwise, the source of a message would have been important. -Doug ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
