As per today's jabber session, here is the promised posting on the occurrence of
the word "sender" in the -base
draft. I have skipped any use of the word where it refers to the Sender header
field or is in the name of a document title:
Abstract
DomainKeys Identified Mail (DKIM) defines a domain-level authentication
framework for email using public-key cryptography and key server technology to
permit verification of the source and contents of messages by either Mail
Transfer Agents (MTAs) or Mail User Agents (MUAs). The ultimate goal of this
framework is to permit a signing domain to assert responsibility for a message,
thus proving and protecting message sender identity and the integrity of the
messages they convey while retaining the functionality of Internet email as it
is known today.
(dhc) Since DKIM signing is presumed to be done by any of the entities that do
sending, the word probably is fine, here. However, I suggest emphasizing that
there may be many senders for a message, so:
"protecting message sender identity" -> "protecting the identity of one of the
senders of the message"
3.4.5 Body Length Limits
...
INFORMATIVE IMPLEMENTATION NOTE: Body length limits could be useful in
increasing signature robustness when sending to a mailing list that both
appends to content sent to it and does not sign its messages. However, using
such limits enables an attack in which a sender with malicious intent
modifies a message to include content that solely benefits the attacker. It
is possible for the appended content to completely replace the original
content in the end recipient's eyes and to defeat duplicate message detection
algorithms. To avoid this attack, signers should be wary of using this tag,
and verifiers might wish to ignore the tag or remove text that appears after
the specified content length, perhaps based on other criteria.
(dhc) I think the use of "sender" here refers to the signer, but it might refer
to the originator. I'm not sure. Who is really the source of the threat?
h=
...
INFORMATIVE EXPLANATION: By "signing" header fields that do not actually
exist, a signer can prevent insertion of those header fields before
verification. However, since a sender cannot possibly know what header fields
might be created in the future, and that some MUAs might present header
fields that are embedded inside a message (e.g., as a message/rfc822 content
type), the security of this solution is not total.
(dhc) sender -> signer
s=
...
This tag is intended to permit senders to constrain the use of delegated
keys, e.g., where a company is willing to delegate the right to send mail in
their name to an outsourcer, but not to send IM or make VoIP calls. (This of
course presumes that these keys are used in other services in the future.)
(dhc) senders -> signers
5.1 Determine if the Email Should be Signed and by Whom
...
A SUBMISSION server MAY sign if the sender is authenticated by some secure
means, e.g., SMTP AUTH. Within a trusted enclave the signing address MAY be
derived from the header field according to local signer policy. Within a
trusted enclave an MTA MAY do the signing.
(dhc) signer -> submitter
6.2 Communicate Verification Results
...
INFORMATIVE ADVICE to MUA filter writers: Patterns intended to search for
results header fields to visibly mark authenticated mail for end users should
verify that such header field was added by the appropriate verifying domain
and that the verified identity matches the sender identity that will be
displayed by the MUA. In particular, MUA filters should not be influenced by
bogus results header fields added by attackers.
(dhc) given that this section specifies MUA behavior, there are bigger issues
than wording choice. however, to deal with that smaller point:
sender -> author
B.6 Third-party Message Transmission
Third-party message transmission refers to the authorized sending of mail by
an Internet application on behalf of a user. For example, a website providing
news may allow the reader to forward a copy of the message to a friend; this is
typically done using the reader's email address. This is sometimes referred to
as the "Evite problem", named after the website of the same name that allows a
user to send invitations to friends.
One way this can be handled is to continue to put the reader's email address
in the From field of the message, but put an address owned by the site into the
Sender field, and sign the message on behalf of the Sender. A verifying MTA
should accept this and rewrite the From field to indicate the address that was
verified, i.e., From: John Doe via news(_at_)news-site(_dot_)com
<jdoe(_at_)example(_dot_)com>.
(dhc) I am not sure which entity the term "the Sender" is referring to, here.
But again, this is wandering in the space of the MUA, I think.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html