Subject: [ietf-dkim] Requirements clarification/addition: DKIM Signing Complete should include designated third parties

From: Scott Kitterman <[email-masked]>
Date: Wed, 9 Aug 2006 12:54:09 -0400

*** 350,356 ****
     previous scenario.  A receiver, on the other hand, may be able to
     take advantage of the knowledge the domain's practice of signing all
     mail in order to use it to bias filters against the unexpected
!    arrival of a piece of unsigned or damaged in transit mail.

  4.3.  Scenario 3: Outsourced First Party Signing

--- 350,357 ----
     previous scenario.  A receiver, on the other hand, may be able to
     take advantage of the knowledge the domain's practice of signing all
     mail in order to use it to bias filters against the unexpected
!    arrival of a piece of unsigned, damaged in transit mail, or mail
!    signed by an entity not described in the RFC2822.From sender policy.

  4.3.  Scenario 3: Outsourced First Party Signing

***************

If we are going to include a list of designated signing third parties, the 
lack of a signature from one of those parties is an equally useful input into 
bias filters.

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

---

From: Damon <[email-masked]>
Date: Wed, 9 Aug 2006 13:44:16 -0400

(Scott's ideas incorporated too)

!! arrival of a piece of unsigned, damaged in transit mail, or if
a RFC2822.From sender policy exists which specifies authoritative
domain(s), a mail signed by an entity other than described in the sender policy.

Regards,
Damon Sauer

---

From: Tony Hansen <[email-masked]>
Date: Wed, 09 Aug 2006 14:36:47 -0400

> domain(s), a mail signed by an entity other than described in the sender

add RFC2822.Sender

	Tony Hansen
	[email-masked]

---

From: Michael Thomas <[email-masked]>
Date: Wed, 09 Aug 2006 11:55:48 -0700

>>domain(s), a mail signed by an entity other than described in the sender
I'm not the chair, but I've seen considerably less consensus about 
anything other
than rfc2822.from. I'm frankly not sure I understand it very well. 
There's of course
nothing that prevents a receiver from checking SSP for any 
address/domain it wants
to, but do we now have a mandate to make assertions about any kind of 
origination
address? How do those assertions interact with each other? What does a 
strong practice
for ListID and a weak practice for Sender mean if they're in the same 
message?

Finally, is this something that can wait? Ie, are we harmed if we don't 
do it now?

       Mike

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 09 Aug 2006 22:31:45 +0100

> than rfc2822.from. I'm frankly not sure I understand it very well. 

I know I don't understand it!

Maybe a more detailed use-case would help? (Tony?)

> for ListID and a weak practice for Sender mean if they're in the same 

All good questions. And maybe not too easy to be confident in
any answers at this stage?

> Finally, is this something that can wait? Ie, are we harmed if we don't 

Again, I dunno. I believe we do have consensus that at least
rfc2822.From needs to be handled now. If more folks want
rfc2822.Sender to be handled now as well, then they should
say so I guess.

S.

---

From: Tony Hansen <[email-masked]>
Date: Wed, 09 Aug 2006 22:30:21 -0400

Stephen Farrell wrote:
>> anything other than rfc2822.from. I'm frankly not sure I understand
>> it very well.
> 

I want to make certain that what we're building with policies doesn't
prevent eCard senders or News agencies from doing what they currently
do. They should be able to 1) send a message to someone on my behalf
while 2) marking themselves as the sender and 3) being able to sign the
message. According to 2822, this minimally requires support for
RFC2822.Sender as well as RFC2822.From.

For example, consider these scenarios:

	From: [email-masked]
	Sender: [email-masked]
	DKIM-Signature: ... d=hallmark.com; ...
	Subject: Happy birthday from Tony
or
	From: [email-masked]
	Sender: [email-masked]
	DKIM-Signature: ... d=newyorktimes.com; ...
	Subject: some news story

These need to be validated against the sender.

Yes, there are a variety of issues. And to properly deal with this
issue, we also need to deal with Sender/d= above being "@bigbadguy.com".
DKIM is not sufficient in and of itself, as we all know. But we need to
be able to support these scenarios somehow.

If we don't let this be done using Sender:, then we need to have some
other way of doing it. My choice is to support the 2822 way of doing it,
which says we need to support Sender:.

	Tony Hansen
	[email-masked]

---

From: "william(at)elan.net" <[email-masked]>
Date: Wed, 9 Aug 2006 19:48:04 -0700 (PDT)

That this thread is being discussed brings up a requirement that policy 
record syntax should be capable of supporting multiple identities.

A subquestion of that is if policy record identity should or should
not be part of the query selection process (i.e. _from._policy if DNS).
That BTW brings up a separate issue about how policy record queries are
to be done, which is a protocol-related requirement and those appear 
to not be mentioned in the requirements document right now.

The question that you're actually discussing in the thread about
'RFC2822.Sender' is is what identit[y|ies] you actually want to
define for initial use and how.

-- 
William Leibzon
Elan Networks
[email-masked]

---

From: Dave Crocker <[email-masked]>
Date: Wed, 09 Aug 2006 19:49:38 -0700

>> domain(s), a mail signed by an entity other than described in the sender

Let's try an exercise:

Why?

How is the information expected to get used?  Why do we believe it will be
useful?  Do we have any indication that it will actually get used (that way, or
any other)?

-- 

  Dave Crocker
  Brandenburg InternetWorking
  bbiw.net
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Scott Kitterman <[email-masked]>
Date: Wed, 9 Aug 2006 22:51:34 -0400

> which says we need to support Sender:.

I think that this scenario is already supported by the "Signing Complete" 
practice and explicitly not desireable for the First Party (as extended by a 
possible list) Expected Practice.

I think that the current requirements are correct for this use case.  This is 
exactly the kind of scenario First Party Expected should not support.

Signing Complete deals with the case where a domain desires to support Sender 
with an associated signature and no policy record (or signs sometimes if we 
end up with such a practice) supports Sender with or without a signature.  
First Party Expected supports the case where a domain does not want to allow 
2822.Sender signatures/policies to over-ride the 2822.From.

My vote is no change needed to the current draft for this.

Scott K

---

From: "Hector Santos" <[email-masked]>
Date: Wed, 9 Aug 2006 23:08:26 -0400

Tony,

Then your domain (att.com) will need to declare a relaxed 3rd party
signature concept.

For example:

Using SSP-01 this is defined as default policy or o=~.

Using a DSAP framework, you would declare:

     OP=OPTIONAL;
     3P=OPTIONAL;

In both cases, you are using a NEUTRAL policy.

You are no longer protecting the authorization of the signature because you
essentially don't care who signs the message.

But you want to allow the 3rd party to have the message authenticity and
integrity power of DKIM.

Now, with DSAP, you can be restrictive on which 3rd party would be allowed
to sign:

     OP=OPTIONAL;
     3P=OPTIONAL;
     3PL=*.hallmark.com;*.newyorktimes.com

which Michael's document covers with requirement #5 covers.

So in my technical view, we don't need the 2822.Sender because it is already
covered with requirement #5.

--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com

---

From: Mark Delany <[email-masked]>
Date: Thu, 10 Aug 2006 03:32:40 +0000

> RFC2822.Sender as well as RFC2822.From.

Why does DKIM need to support these directly? They can continue to
send like this just fine and rely on their domain reputation or the
good graces of receivers.

Better yet, eCard senders could put their own From: address in and put
your email in the content:

	From: [email-masked]

	Howdy. mailto:[email-masked] allegedly sent this card to
	your for your birthday...

It seems bizarre to me that we want to explicitly allow an
unauthenticated 2822.From to be treated as authenticated.

One option: att.com could advertise that hallmark.com can put @att.com
in the 2822.From: and have it authenticated via hallmark.com. Is that
what you're asking for?

Mark.

---

From: Douglas Otis <[email-masked]>
Date: Thu, 10 Aug 2006 09:27:06 -0700

On Aug 9, 2006, at 7:51 PM, Scott Kitterman wrote:

>>>> I'm not the chair, but I've seen considerably less consensus  
>>>> about anything other than rfc2822.from. I'm frankly not sure I  
>>>> understand it very well.
>>>
>> I want to make certain that what we're building with policies  
>> doesn't prevent eCard senders or News agencies from doing what  
>> they currently do. They should be able to 1) send a message to  
>> someone on my behalf while 2) marking themselves as the sender and  
>> 3) being able to sign the message. According to 2822, this  
>> minimally requires support for RFC2822.Sender as well as  
>> RFC2822.From.
>>
>> issue, we also need to deal with Sender/d= above being  
>> "@bigbadguy.com". DKIM is not sufficient in and of itself, as we  
>> all know. But we need to be able to support these scenarios somehow.
>>
>> If we don't let this be done using Sender:, then we need to have  
>> some other way of doing it. My choice is to support the 2822 way  
>> of doing it, which says we need to support Sender:.
>>
>> 	Tony Hansen
>> 	[email-masked]
>
> I think that this scenario is already supported by the "Signing  
> Complete" practice and explicitly not desireable for the First  
> Party (as extended by a possible list) Expected Practice.

Actually "Signing Complete" should be as explicit assertion, whereas  
"Not Signing Complete" should be a default that indicates the First  
Party address also uses other services.  Domains being used to sign  
the First Party address may not be found listed in the policy, but  
rather this would require the history of these services be assessed  
independently.  These services could also include various mailing  
lists for example.  Having a domain name listed in the policy should  
only imply that this domain is authoritative for the First Party  
Address to allow trustworthy annotations. (It really was originated  
by First Party Address.)  Indicating Signing Complete would be an  
additional assertion that this list is also representative of the  
only sources used.

-Doug

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 10 Aug 2006 18:33:27 +0100

Doug,

Douglas Otis wrote:
> "Not Signing Complete" should be a default ...

That's a nice example of a design discussion. We're on requirements
now.

Stephen.

---

From: Douglas Otis <[email-masked]>
Date: Thu, 10 Aug 2006 11:29:20 -0700

On Aug 10, 2006, at 10:33 AM, Stephen Farrell wrote:
> Douglas Otis wrote:
>> Actually "Signing Complete" should be as explicit assertion,  
>> whereas "Not Signing Complete" should be a default ...
>

Rephrased:

The policy should be able to indicate:

  - What signing domains are authoritative for the First Party Address.
    (The policy specifies which signing domain qualify the First  
Party Address as being valid.)

      AND

  - What signing domains are exclusively used by the First Party  
Address.
   (DKIM Signer Complete)

To permit the first requirement without encumbrances, the DKIM Signer  
Complete assertion MUST BE optional.

A less stringent assertion than "DKIM Signer Complete" should also be  
possible.  This option might be called "DKIM Signer Extended".

"DKIM Signer Extended" could indicate that the "DKIM Signer Complete"  
assertion applies, and that common services are also used.

"DKIM Signer Complete" or "DKIM Signer Extended" assertions would  
apply to all listed domains.

To clarify:

A DKIM Signer Complete assertion specifies the domains listed in the  
policy represent all the signing domains used by the First Party  
Address and that only signing sources are used.

Without either "DKIM Signer Complete" or "DKIM Signer Extended" *no*  
assurance of exclusivity or restriction of sources carrying the First  
Party Address have been asserted.

-Doug

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 11 Aug 2006 09:40:28 +0100

Doug,

That's better, since it uses requirements language, but unfortunately
still not understandable (for me at any rate).

Douglas Otis wrote:
>    (The policy specifies which signing domain qualify the First Party 
> Address as being valid.)
> 
>      AND
> 
>  - What signing domains are exclusively used by the First Party Address.
>   (DKIM Signer Complete)

Are "authoritative for" and "exclusively used by" well defined? IMO
they're not (and the latter is used ambiguously as well).

I also doubt that we need either concept.

Stephen.