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?
"Damage the verifier" makes it sound like we're breaking the verifier or
something, but I don't think that's what you mean. The problem is that,
absent SSP Delegated Signing Domains (SSP DSD), it's fairly easy for the
verifier or a later agent to determine the role of a signature by
matching the i= address (signing address) against other header fields in
the message. With SSP DSD, it's no longer possible to do that, because
the signing address bears no relationship to other header fields in the
message, other than that it was authorized by the author's SSP.
Some workarounds have been proposed whereby the signing domain uses
subdomains to work around some (but not quite all) of this ambiguity. I
believe that this removes some of the supposed simplicity that was the
motivation for SSP DSD in the first place.
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.)
In at least some cases, bad actors and good actors may share the same
domain. Suppose a bad actor shared the same domain with a good actor
and a mailing list. The bad actor could spoof a message to the mailing
list from the good actor. If the domain uses SSP DSD, the signature
would not have any way of indicating whether it was on behalf of the
good actor or the mailing list. The "damage" to the verifier is the
interpretation of a mailing list signature as being an author signature
from the good actor.
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).
See above.
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.
I thought we covered key management threats in the threat analysis
already. In any case, if it's not covered adequately, it belongs in
either the threat analysis or in -base, because there is no key
management in SSP.
-Jim
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html