I think I've caught up on this thread, but have a couple of
questions/comments.
1. Jim/Mike's scenarios allow for a spoofed message to be inserted
between the supposed originating domain (company.com) and the common
signing domain (mailinglists.com). For the verifier, why is this
so different? Such messages could in any case be inserted inside
company.com - so is it only a matter of the likelihood or is there
some qualitative difference that could damage the verifier?
2. (Overlaps with #1.) The scenarios nicely demonstrate how the
verifier can't tell exactly what's happened, but don't seem to
say exactly how the bad actor benefits, nor what damage might
occur to the verifier. Be good to document that explicitly. (This
might be just my ignorance of course, but its not very clear to
me.)
3. If we could describe what we do/don't want to happen as a
security requirement that'd be good to include in the requirements
document (along with the problematic scenarios).
4. If there is a requirement to achieve similar functionality via
delegation of keys, then we (as a WG) need to be very clear about
how those keys are managed, or else have to provide a convincing
argument that such management is not our problem. (Any such key
management being non trivial.) It is at least arguable that the
overall system would be less secure due to problems with key
management, when compared to problems arising from corner cases,
or bad behaviour happening, prior to delegated signing.
Stephen.
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html