[ietf-dkim] Use of "sender" in -base

[Eric Allman]

>> 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"

It doesn't really have to be even one of the senders (although 
presumably it is).  How about we just change "sender" -> "signer"?

>> 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?

I agree with Paul here; changing it to "attacker" is fine, 
particularly since it is non-normative.  I think we can also drop 
"with malicious intent", since that's implied by the word "attacker".

>
>
>> 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

Done.

>> 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

Done.

>
>
>
>> 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

I assume you mean "sender" -> "submitter" here.

>
>> 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

Done.

>
>
>> 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.com <jdoe at example.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.

Rewritten to:

        One way this can be handled is to continue to put the
        reader's email address in the From header field of the
        message, but put an address owned by the site into the Sender
        header field, and sign the message on behalf of that address.
        A verifying MTA should accept this and rewrite the From
        header field to indicate the address that was verified, i.e.,
        From: John Doe via news at news-site.com <jdoe at example.com>.

eric