[ietf-dkim] Delegating responsibility: a make vs. buy design decision

[Stephen Farrell]

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.