Hi Jim,
Jim Fenton wrote:
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.
Sure. But so what? The verifier never really knows what went on before
signing and we haven't really defined signing roles.
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.
I didn't follow all of those details, but I'd agree that, in general,
and in this case, a complex delegation mechanism is worse than none.
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.
But that depends upon how the verifier has (mis)interpreted the
signature - something I thought we generally try to steer away from.
The proper interpretation (at the dkim level) of the "SSP DSD"
signing case is surely that company.com nominated isp.com to sign
for company.com and that that's all correct (or not, whatever). A
verifier that thinks it means that isp.com says that it got the
signed-bytes directly from company.com seems to be making
decisions/assumptions at the wrong layer.
I'd still like to see a concrete case of something that can happen
here that cannot happen if no "SSP DSD" mechanism is defined.
Sorry for being obtuse, but I'm concerned that we're maybe eliminating
a requirement that has some support (unless those supporting it have
been convinced already), and where the basis for elimination is
something that can happen in any case (which basically seems to be
that funny things can happen before signing and the verifier will
be blissfully ignorant).
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.
Nope that didn't do it for me. I was thinking of something along
the lines of (a readable version of) "singing practices MUST be
sufficiently simple, that expected sets of independent practices
do not interfere with one another, nor with current email practices",
and then follow up explaining the corner case of company.com and
mailinglists.com as per the thread. (The fact that its maybe quite
hard to write down what we want to protect here, may be meaningful
IMO - it might mean we're not sure what we're protecting?)
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.
Sure, but my worry is that we define SSP so that we push people
to delegate keys (as opposed to signing) and then get (properly)
criticised for not supplying the required key management. This
isn't really a comment on the SSP requirements, but rather a
worry about the consequences of how we resolve some of these
issues, (and a definite wish to not have to start figuring
which existing key management scheme(s) to pick for dkim key
delegation;-)
S.
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html