Stephen Farrell wrote:
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?
If I am understanding what you've written, we probably *do* need to distinguish
between signing within the originating ADMD, versus signing later, such as when
re-posting the message by a mailing list.
Still, I think your basic point is that a signer might or might not validate the
rfc2822.From field. DKIM does not take a position on this.
So, the degree of enforcement for the content of *any* signed field is not
stated as part of DKIM's specification.
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.
Isn't it as simple as: A signer might have practices that permit header fields
to have invalid content?
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).
Certainly would be good for us to be clear about!
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.
You lost me here.
DKIM says nothing about key management now. Why does this need to change, for
the particular case of having keys used by someone in another ADMD?
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html