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

From: Dave Crocker <[email-masked]>
Date: Thu, 08 Jun 2006 08:43:10 -0700

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 [email-masked] <[email-masked]>.

(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

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 8 Jun 2006 10:00:46 -0700

>to the originator.  I'm not sure.  Who is really the source of the threat?

It seems to be clearly that "sender" means "attacker" here. sender -> attacker

>(dhc)  signer -> submitter

This one confuses me. Did you mean "if the sender is authenticated" 
-> "if the submitter is authenticated"?

+1 to the rest.

---

From: Dave Crocker <[email-masked]>
Date: Thu, 08 Jun 2006 10:08:27 -0700

Paul Hoffman wrote:
>>> 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....
>> (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?
> 

hmm. yeah.  but i guess the interesting part is that it means an entity that
handles the message after signing but before delivery.  that means it is some
sort of post-signing intermediary (ummm, sender...)

>>> 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.>>>
>>
> This one confuses me. Did you mean "if the sender is authenticated" ->
> "if the submitter is authenticated"?

yes, sorry.  i did mean sender -> submitter.

if the submitter is authenticated.

d/

-- 

  Dave Crocker

---

From: Jim Fenton <[email-masked]>
Date: Mon, 12 Jun 2006 11:48:46 -0700

> sort of post-signing intermediary (ummm, sender...)
Agree with Paul's comment.  I'd just change the word; we don't need to
delve into what sort of attacker we're talking about here.

-Jim

---

From: Eric Allman <[email-masked]>
Date: Wed, 21 Jun 2006 15:07:20 -0700

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

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

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

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

> 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
> 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 [email-masked] <[email-masked]>.
>
>
> (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 [email-masked] <[email-masked]>.

eric

---

From: Dave Crocker <[email-masked]>
Date: Wed, 21 Jun 2006 21:46:15 -0400

> presumably it is).  How about we just change "sender" -> "signer"?

all your suggestions sound dandy.  thanks!

d/

-- 

  Dave Crocker

---

From: Tony Hansen <[email-masked]>
Date: Wed, 21 Jun 2006 23:05:55 -0400

I have an issue with one item, below.

Eric Allman wrote:
>>> 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

Two points here:

   *	Such rewriting MUST be done *after* the verification pass has been
performed. (Obviously it can't be done before, unless the From: header
is not in the h= field list.)

   *	Once such rewriting is done, this message will never re-verify
again. This would *prevent* a subsequent entity, such as the MUA, from
doing its own verification. It would be nice if there were some way of
preserving the original From: contents if reverification is necessary so
that any such rewriting can be reversed for the reverification.

	Tony Hansen
	[email-masked]

---

From: Eric Allman <[email-masked]>
Date: Thu, 22 Jun 2006 10:04:48 -0700

...
>>        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
>    *	Such rewriting MUST be done *after* the verification pass has
> been performed. (Obviously it can't be done before, unless the
> From: header is not in the h= field list.)
>
> again. This would *prevent* a subsequent entity, such as the MUA,
> from doing its own verification. It would be nice if there were
> some way of preserving the original From: contents if
> reverification is necessary so that any such rewriting can be
> reversed for the reverification.

Reasonable points.  I've changed "should" to "could", and added 
"(However, such rewriting must be done after the verification pass is 
complete, and will break any later attempts to re-verify.)"

Does this work for you?

eric