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

[Dave Crocker]

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