On Fri, 08 Jul 2011 14:54:43 +0100, Murray S. Kucherawy
<msk(_at_)cloudmark(_dot_)com> wrote:
-----Original Message-----
[mailto:ietf-dkim-bounces(_at_)mipassoc(_dot_)org] 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: chl(_at_)clerew(_dot_)man(_dot_)ac(_dot_)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