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