On Fri, 08 Jul 2011 14:54:43 +0100, Murray S. Kucherawy <[email protected]> wrote:
>> -----Original Message----- >> [mailto:[email protected]] On Behalf Of Charles Lindsey >> Sent: Friday, July 08, 2011 3:52 AM >> 1. The fact that DKIM choose headers to sign from the bottom up (for >> good >> reason) facilitates certain attacks (not against DKIM, but certainly >> against somone/something) needs to be drawn to the attention of >> implementors of identity assessors, so that they can take appropriate >> action. > > That's not part of what DKIM tells an assessor, nor is the list of > signed header fields, so I don't see why that would be a useful thing to > highlight. For example, if a message contains two Subject: fields, the > assessor doesn't know which was signed; could be neither. It still gets > an SDID out of the verification and nothing more (possibly not even that > if the signature failed). Of course that's not what DKIM tells the assessor; it is part of what is written in our document. But the significance of that fact when taken in conjunction with non 5322-compliance is not obvious (evidently so, because it took several years for some member of this list to spot it). Hence the reason why it is essential to draw explicit attention to it. And as for the "list of signed header fields", I expect assessors to be told more than that (the SDID in only the minimal reporting requirement). Surely we all agree that an assessor would like to know if an 'l=0' was given, for example. But the point is moot, since the assessor also has the whole message before it, and can explore it himself as needed. >> 2. The fact that an attacker (whilst following DKIM to the letter) can >> use >> it, in conjunction with duplicated headers, to add credence to his >> message >> also needs to be drawn to their attention. > > Same answer. All you get is an SDID, if that. The credence you add to > the content comes from what you do with that value. An assessor that > gives a thumbs-up to any signed message without at least considering > which SDID signed it is faulty. But how the assessor works is not in > scope here. And the first thing an assessor is likely to do is to look whether the SDID bears any resemblance to the AUID. If it does not, his suspicions will be aroused and he will want to examine further. But if it agrees (or appears to), and if the SDID is from a domain that has not (yet) acquired a bad reputation, then he may let it go. -- Charles H. Lindsey ---------At Home, doing my own thing------------------------ Tel: +44 161 436 6131 Web: http://www.cs.man.ac.uk/~chl Email: [email protected] 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
