Hi Stephen, welcome back from your vacation! :-)
There is a lot to be said here, but I think it all comes down to answering
the baseline scenario that "looks and feels" like Jim/Mike's scenario; the
baseline scenario when there is no DKIM signature header:
From: president(_at_)company(_dot_)com
Sender: listadmin(_at_)mailinglist(_dot_)com
To: someone(_at_)phishingtarget(_dot_)com
Date: Wed, 23 Aug 2006 01:14:57 -0400
Subject: Important new stuff!
How or what will a verifier us to extract policy information from this
message transaction?
What domain are we protecting in the above available header block?
company.com? mailinglist.com? We can't look up the ISP.COM records because
we don't see any information about it.
Should we use mailinglist.com? From the company.com standpoint,
mailinglist.com is not a signer. The verifier does not know that, so should
it use mailinglist.com or the Sender: domain? Where is the inherent trust
there to suggest mailinglist.com was acting of the behalf of company.com?
If we use company.com, we will see there is a 3PS signing requirement
associated with the designated ISP.COM. With no DKIM signature header
present, we have strong evidence it is bad.
There is really much more to say here, but it really comes down to the above
because what we decide here should also apply when there is a signature
present. Or does the policy lookup rule change when there is a DKIM
signature header available?
--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com
----- Original Message -----
From: "Stephen Farrell" <stephen(_dot_)farrell(_at_)cs(_dot_)tcd(_dot_)ie>
To: "Jim Fenton" <fenton(_at_)cisco(_dot_)com>
Cc: <ietf-dkim(_at_)mipassoc(_dot_)org>
Sent: Wednesday, August 23, 2006 5:57 AM
Subject: Re: [ietf-dkim] Delegating responsibility: a make vs. buy
designdecision
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
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html