ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] Consensus point on ADSP

2009-04-01 11:12:30
Jim says...
My problem is that the semantics of the signature that the mailing list
applies shouldn't depend on whether the original author happens to be in
the same domain as the list.

Charles says...
So if a particular mail happens to have foo.example in its From: header,
and has also been forwarded to a list by that same domain, then WHO CARES
whether the signature was put there by the mailing list expander, or by
the normal signing machine for that domain (maybe it had even acquired two
signatures, one from each and both using the same key)? IT DOESN'T MATTER,
since it is amply proved to be a genuine message vouched for by that
domain.

From separate conversations with Jim, I see this as the central point
of disagreement.  It's the question of whether the signatures relate
*only* at the domain level, or whether there's a concept that the
domain signs "on behalf of" an entity.

Mostly, I agree with the side of the discussion that says it's just
the domain, so don't worry.  But DKIM does make a nod to the other
side by suggesting that the domain, when signing, might consider what
it knows about the actual sender.  In RFC 4871, section 5.1; note the
last clause:
      INFORMATIVE NOTE: Signing modules may be incorporated into any
      portion of the mail system as deemed appropriate, including an
      MUA, a SUBMISSION server, or an MTA.  Wherever implemented,
      signers should beware of signing (and thereby asserting
      responsibility for) messages that may be problematic.  In
      particular, within a trusted enclave the signing address might be
      derived from the header according to local policy; SUBMISSION
      servers might only sign messages from users that are properly
      authenticated and authorized.

In a situation where, say, the domain chose not to sign the message
submitted by the original user, but did choose to sign the copy
forwarded by the mailing list.  Then you'd trip over the problem that
Jim's concerned about.

You might say that in that case, "the mailing list shouldn't sign the
message," since it wasn't signed before.  But the mailing list isn't
signing the message -- the domain is.  The domain might say that the
mailing list is properly authenticated and authorized, so I sign.  And
the mailing list may have no way to vet the original sender, one way
or the other.  Should *it* behave differently when the sender who's
posting is in the same domain than it does when the sender is not?

I do see the issue.

That said, I think it really is out of DKIM's scope, and I don't see
it as a problem with DKIM.  It's one of the examples that makes the
whole issue of authentication and mailing lists problematic, whatever
authentication mechanism you use.

My opinion, as a participant, is that this case isn't a compelling
reason to keep i= in ADSP, and that *if* we need to address this case
in the real world (which I don't think we do), we should consider it
later, when we have more experience and a better idea of how we might
deal with it properly.

Barry (as participant)
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html