ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] Re: Responsibility vs. Validity

2007-11-28 15:27:52
Jim Fenton wrote:
Michael Thomas wrote:
Jim Fenton wrote:
Michael Thomas wrote:
Frank Ellermann wrote:
Jim Fenton wrote:

we could easily add verbiage to SSP stating that domains publishing
SSP records other than "unknown" MUST additionally ensure that they
only sign messages purporting to come from themselves when the
address in the From: header field is valid.  That way, we're putting
the additional burden on those who publish SSP records but are not
trying to modify the meaning of RFC 4871 at all.
Good idea, a connection to 4409, 4954, and 5068.
So the implication here is that that sort of domain could never run a
mailing
list that resigns messages? That doesn't seem right to me.
That's precisely one of the motivations for the local-part of the i=
tag.  If a message from this list, for example, were signed with
i=ietf-dkim(_at_)mipassoc(_dot_)org, the signing address would not match
jdoe(_at_)mipassoc(_dot_)org, so there's no confusion about whether it's an
originator signature or a mailing list signature.
I'm completely lost, sorry. I guess I have no idea what you mean by
"From:
header field is valid" or "coming from themselves".

It seems that my language wasn't precise enough, so let me take another
shot at it.

It has been noted that when a signing domain "claims responsibility for
the introduction of a message into the mail stream" it is not actually
asserting the validity of any part of the message.  This is relevant to
SSP because it has a dependency on whether the Signing Address (i=
address or its default) matches the address in the From: header field.

I propose to solve that problem by adding language similar to the
following to the SSP draft:

Domains publishing SSP records indicating practices other than
"unknown" MUST ensure the validity [correctness] of the address in the
From: header field for messages to which they apply an Originator
Signature.


In other words, before applying an Originator Signature, make sure the
message isn't spoofed.

I'm having trouble reconciling this with section 5.1:

5.1.  Determine Whether the Email Should Be Signed and by Whom

  A signer can obviously only sign email for domains for which it has a
  private key and the necessary knowledge of the corresponding public
  key and selector information.  However, there are a number of other
  reasons beyond the lack of a private key why a signer could choose
  not to sign an email.

     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.


This is basically saying that you shouldn't sign for things you
don't want to take responsibility for, which I'd think is pretty
obvious that you wouldn't want to take responsibility for something
that could be a forgery. My question is whether we're trying to put too fine a point on this, and whether trying to clarify things makes it even more murky. Also: I'm wondering whether the point Dave seems to be making is anything more than a theoretical problem. Who in their
right mind would assert responsibility for something that is a
possible forgery? And if they do, why should anybody care about
their promiscuity?

FWIW, the new proposed text didn't really help me. Maybe tightening up the
text in 5.1 to be a bit more explicit might be a better approach?

      Mike
_______________________________________________
NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html

<Prev in Thread] Current Thread [Next in Thread>