Subject: Re: [ietf-dkim] Conflicts between -ssp-requirements and -ssp

From: "Charles Lindsey" <[email-masked]>
Date: Mon, 01 Oct 2007 11:00:57 +0100

On Sun, 30 Sep 2007 21:39:44 +0100, Michael Thomas <[email-masked]> wrote:

> Eric Allman wrote:
>> It sounds like you are arguing that "all" should be "strict" and  
>> "strict" should be eliminated; as a corollary, no Third Party  
>> Signatures should be accepted under any circumstances.  That's a valid  
>> argument, but it has nothing to do with whether the -ssp draft is  
>> accurate.
>
> No. Strict seems consistent with the requirements.  For "all", the  
> problem I'm
> having is tying the statement "I sign everything" to any other statement,
> including "I think that 3rd party signatures are groovy". They are not  
> inherently
> linked, and the SSP draft shouldn't do that. I can very easily say "I  
> sign everything"
> and have no opinion whatsoever about other kinds of signatures.
>>

The scenario you need to consider is where A asserts a policy of "I sign  
everything", and sends a correctly signed message to some mailing list B.

B can (and should) check that the signature is good, and is consistent  
with A's policy, etc. But then B add his standard mailing list boilerplate  
"NOTE WELL ..." thus breaking A's signature. He then signs the message  
again (as a 3rd party).

Now the ultimate recipients see A's signature (no longer good), plus A's  
policy. So the message is on the face of it "suspicious". So what is the  
recipient supposed to do? He is a member of the list, and is happy to  
trust the list maintainer, and can check the 2nd signature. But he is  
still receiving conflicting advice.

The only real solution to this problem is for B to add an  
Authentication-Results header (see the Mail-Vet-Discuss mailing list), and  
to incluide that header in is own signature. Maybe that is veering off  
topic for this list, but at least there should be a pointer to that sort  
of possibility.

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131                       
   Web: http://www.cs.man.ac.uk/~chl
Email: [email-masked]      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Graham Murray <[email-masked]>
Date: Mon, 01 Oct 2007 11:38:44 +0100

"Charles Lindsey" <[email-masked]> writes:

> The scenario you need to consider is where A asserts a policy of "I
> sign everything", and sends a correctly signed message to some mailing
> list B.
>
> with A's policy, etc. But then B add his standard mailing list
> boilerplate  "NOTE WELL ..." thus breaking A's signature. He then
> signs the message  again (as a 3rd party).
>
> Now the ultimate recipients see A's signature (no longer good), plus
> A's policy. So the message is on the face of it "suspicious". So what
> is the  recipient supposed to do? He is a member of the list, and is
> happy to  trust the list maintainer, and can check the 2nd
> signature. But he is  still receiving conflicting advice.
>
> Authentication-Results header (see the Mail-Vet-Discuss mailing list),
> and  to incluide that header in is own signature. Maybe that is
> veering off  topic for this list, but at least there should be a
> pointer to that sort  of possibility.

If A had used 'l=' and assuming the boilerplate is added to end of the
message and that B does not change the headers (eg to add [listname] at
the start of Subject:) then A's and B's signatures should both
validate.

---

From: Michael Thomas <[email-masked]>
Date: Mon, 01 Oct 2007 08:37:45 -0700

Charles Lindsey wrote:
> happy to trust the list maintainer, and can check the 2nd signature. 
> But he is still receiving conflicting advice.

This is something that I also took away from the draft. "strict" + 
broken/missing
signature is much more suspicious than "all" + broken/missing signature. My
suggestion would be to tie the "suspicion" to the expectation: eg 
suspicious/strict
and suspicious/all.
> and to incluide that header in is own signature. Maybe that is veering 
> off topic for this list, but at least there should be a pointer to 
> that sort of possibility.
>

This doesn't work in the abstract because Auth-res isn't necessarily 
trustable across
domains, and in fact I often don't trust who produced it even if it 
could be authenticated.

       Mike

---

From: Douglas Otis <[email-masked]>
Date: Mon, 1 Oct 2007 11:21:13 -0700

On Oct 1, 2007, at 8:37 AM, Michael Thomas wrote:

>> Authentication-Results header (see the Mail-Vet-Discuss mailing  
>> list), and to incluide that header in is own signature. Maybe that  
>> is veering off topic for this list, but at least there should be a  
> This doesn't work in the abstract because Auth-res isn't  
> necessarily trustable across domains, and in fact I often don't  
> trust who produced it even if it could be authenticated.

With the tpa-ssp extension for ssp, it is possible for an email  
domain to indicate which DKIM domains are authorized.  This scheme  
scales to any number of authorizations without inducing a large  
number DNS transactions.

http://www1.tools.ietf.org/wg/dkim/draft-otis-dkim-tpa-ssp-01.txt

This extension is also able to specify which originating headers are  
permitted.  The authorization list is intended to ensure hashed  
domain name collision is not possible.

-Doug

---

From: "Charles Lindsey" <[email-masked]>
Date: Tue, 02 Oct 2007 11:45:42 +0100

> suggestion would be to tie the "suspicion" to the expectation: eg  

Yes, I think that is the difference between "all" and "strict".

"All" means what it says. But "strict" means "We don't sent to mailng  
lists; our messages are not intended to be forwarded to anyone else; they  
are intended just for the recipient in the 'To' header and noone else (BTW  
we sign the 'To' header). So if you don't see a valid signature FROM US,  
then it is bogus, and you should throw it away".

Vicious, and even paranoid, but that's what they said :-( .
>> and to incluide that header in its own signature. Maybe that is veering  
>> off topic for this list, but at least there should be a pointer to that  
>> sort of possibility.
>>
>

A member of a mailing list needs to know two things:
   a) did the message come via the mailing list?
   b) was it sent to the mailing list by the purported "From"?
Ideally, two signatures, both valid, would put the matter beyond doubt.  
But members of mailing lists will likely trust the list maintainers, and  
so may well choose to accept the indirect validation of the first  
signature.

---

From: <[email-masked]>
Date: Tue, 2 Oct 2007 10:27:33 -0400

"A member of a mailing list needs to know two things:
   a) did the message come via the mailing list?
   b) was it sent to the mailing list by the purported "From"?"

Why would anyone care about b? It is a mailing list which by nature is somewhat anonymous and self inclusive. Either a post matches proper list content or a moderator will boot the poster with or without warning.
Thanks,

Bill Oxley
Messaging Engineer
Cox Communications

---

From: Scott Kitterman <[email-masked]>
Date: Tue, 2 Oct 2007 11:48:04 -0400

On Tuesday 02 October 2007 10:27, [email-masked] wrote:
> Why would anyone care about b? It is a mailing list which by nature is
> somewhat anonymous and self inclusive. Either a post matches proper list
> content or a moderator will boot the poster with or without warning.
> Thanks,

Well, as an example, a message saying:

"There are the following mistakes in the latest SSP draft:

1. ..
2. ..
3. .."

would have a very different meaning coming from me than from Jim Fenton.

Who is saying something is quite often relevant.

Scott K

---

From: John Levine <[email-masked]>
Date: 2 Oct 2007 16:44:53 -0000

>> Why would anyone care about b?

>Well, as an example, a message saying: ...

How is it relevant to DKIM or SSP?  For filtering purposes, if a
message is from the list, it's from the list.

R's,
John

---

From: Scott Kitterman <[email-masked]>
Date: Tue, 2 Oct 2007 13:43:33 -0400

> message is from the list, it's from the list.
True, but the question was why would anyone care.  That was an example of why 
someone would care.

Scott K

---

From: Douglas Otis <[email-masked]>
Date: Tue, 2 Oct 2007 11:06:55 -0700

> Who is saying something is quite often relevant.

This assertion in what DKIM offers requires fairly flexible  
restrictions.

Mailing lists would need to:

- Validate DKIM headers
- Restrict From addresses to be within DKIM domains
- Apply DKIM signatures after flattening

Mailing list recipients would need to:

- Validate DKIM headers
- Restrict Sender addresses to be within DKIM domains

TPA-SSP provides a solution where signatures can invoke tailored  
restrictions:

- sub-domain signatures can be authorized as valid
- sub-domain signatures can apply specific scopes

A domain may support a mailing list, transactional email, as well as  
allow participants to send messages to a mailing list.  Polices  
required of DKIM will therefore need to vary or policy will become a  
problem.  Tailored policies can be structured through use of TPA- 
SSP.  Dave Crocker once suggested sub-domain signatures be used to  
categorize emails.  Any signature from a sub-domain is _not_ valid  
for an email-address within a parent domain.  TPA-SSP can safely  
enable a sub-domain strategy as well as any other third-party strategy.

MAIL FROM is also covered by TPA-SSP.  Our systems see about 70% of  
spam appear as a bounce.  (Perhaps soon bouncing entire message  
content will be seen as analogous to that of an open proxy.)  TPA-SSP  
can also make assertions about MAIL FROM email-addresses.  This MAIL  
FROM assertion might better ensure a DSN is issued rather than dropped.

-Doug

---

From: "Charles Lindsey" <[email-masked]>
Date: Wed, 03 Oct 2007 16:46:18 +0100

> content or a moderator will boot the poster with or without warning.

It delends on the nature of the mailing list, whether it are open to  
anyone to post, and what the moderation policy is (or even if there is  
one).

Suppose, for example, that a submission to the list has been forged in the  
name of a regular contributor - so it may not be obvious that it is a  
forgery, and indeed there may be discussion on-list concerning its  
provenance. You cannot assume that list managers will necessarily be  
checking DKIM signatures.

But if it is known that the regular contributor regularly signs with DKIM,  
that makes it easier to spot the forgery.

---

From: <[email-masked]>
Date: Wed, 3 Oct 2007 11:54:53 -0400

I am not sure why anyone would forge a list contribution that contributes or why it would matter. I just want to know that an incoming email from a list is actually from that list. 

Bill Oxley
Messaging Engineer
Cox Communications

---

From: John Levine <[email-masked]>
Date: 3 Oct 2007 23:38:58 -0000

>Suppose, for example, that a submission to the list has been forged
>in the name of a regular contributor - so it may not be obvious that
>it is a forgery, and indeed there may be discussion on-list
>concerning its provenance.

I've been using mailing lists for upwards of 30 years, and I can think
of perhaps two occasions when one list member forged a message from
another.  This does not impress me as a problem that we need to solve.

> You cannot assume that list managers will necessarily be checking
> DKIM signatures.

True, but you also cannot assume that you know better than list
managers how to run their lists.  There are all sorts of techniques
that list managers use now to control the flow of messages into their
lists, none of which will go away when DKIM arrives.

R's,
John

---

From: Jim Fenton <[email-masked]>
Date: Sun, 07 Oct 2007 22:31:23 -0700

Finally getting a little caught up...

>> But he is still receiving conflicting advice.
A message where A's (the author's) signature is broken isn't
automatically Suspicious if A's SSP record says "all".  It is only
Suspicious if there is no other signature there that the verifier is
willing to accept.  One might expect that the verifier is willing to
accept signatures from mailing lists it knows about.
> suggestion would be to tie the "suspicion" to the expectation: eg

The SSP draft does not attempt to set levels of suspicion.  Either a
message is Suspicious or it is not, for the purposes of the draft.

You're right, though, that the difference between "all" and "strict" is
an expectation, as defined in section 5.3 of SSP Requirements.  There
was a design choice between having independent practice and expectation
flags in SSP and having a single flag.  We opted to combine practice and
expectation into a single flag with the three values {unknown, all,
strict} since the fourth value, "I don't sign everything but you should
expect a valid signature anyway", doesn't make any sense and it seemed
like it removed a potential source of misconfiguration if it is not
possible to express that combination.

-Jim

---

From: Michael Thomas <[email-masked]>
Date: Mon, 08 Oct 2007 08:05:16 -0700

> possible to express that combination.

I think I see what the problem is here. In the draft, you're trying to 
have a single
word summary that something is wrong ("suspicious"). The problem is that 
that
summary is just a single bit. I scanned through the draft and it doesn't 
a priori look
like it would be too difficult to just say what you mean ("strict 
failure") rather than
having the less precise summary ("suspicious"). The thing I'm *very* 
concerned
about is implementations treating "all" failure the same as "strict" 
failure. They
are not even close to the same semantics.

       Mike

---

From: Arvel Hathcock <[email-masked]>
Date: Tue, 09 Oct 2007 10:26:43 -0500

> So, do we want to allow ssp statements to say "handling=block" or
 > some equivalent?

Sorry for the late reply.  I have no problem with the above.

-- 
Arvel

---

From: "Charles Lindsey" <[email-masked]>
Date: Thu, 11 Oct 2007 19:34:41 +0100

On Wed, 03 Oct 2007 16:54:53 +0100, <[email-masked]> wrote:

> I am not sure why anyone would forge a list contribution that  
> contributes or why it would matter. I just want to know that an incoming  
> email from a list is actually from that list.

It is quite common, in some of the chattier Usenet Newsgroups, for trolls  
to forge postings in the name of other regular contributors (you see it  
less in the more technical groups). And remember that Newsgroups are often  
gatewayed into mailing lists.

In the case of mailing lists such as this one, intended for serious  
technical discussions, I doubt one will ever encounter such forgeries, but  
I am sure there must be mailing lists out there established for more  
social purposes, and in which such trolls will inevitably be found.

> From: [email-masked]  
> [mailto:[email-masked]] On Behalf Of Charles Lindsey

---

From: <[email-masked]>
Date: Thu, 11 Oct 2007 14:59:48 -0400

I frequent a social/technical board that had a spoof/troller. He was simply smacked down by the admin. Only a few were taken in and all were annoyed. I don't think that is an issue we need to solve technically.
Thanks, 

Bill Oxley
Messaging Engineer
Cox Communications

---

From: John Levine <[email-masked]>
Date: 11 Oct 2007 20:40:54 -0000

>gatewayed into mailing lists.

Well, if we assume that we can wave our wand and assume that there are
DKIM signatures on usenet messages, which seems unlikely anytime soon,
they wouldn't survive a gateway to e-mail anyway since the headers,
although similar, are not identical.

A DKIM based filter could work at the gateway, in either direction.
That would be a swell place to check signatures.

>social purposes, and in which such trolls will inevitably be found.

Nobody has ever seen such a list.  If you have actual examples to
contribute, we'd be most interested to hear about them.

R's,
John

---

From: Douglas Otis <[email-masked]>
Date: Thu, 11 Oct 2007 14:16:58 -0700

On Oct 11, 2007, at 1:40 PM, John Levine wrote:
>> I am sure there must be mailing lists out there established for  
>> more social purposes, and in which such trolls will inevitably be  
>> found.
>

Although there are broken aspects of OpenID at this time, one of its  
goals beyond simplifying the log-in access to various web-sites was  
to also permit an exchange of good and bad blogger identities.  Sound  
familiar?

http://lifein360.blogspot.com/2007/10/openid-one-world-one-login.html

-Doug

---

From: "Charles Lindsey" <[email-masked]>
Date: Fri, 12 Oct 2007 12:36:51 +0100

> although similar, are not identical.

Actually, DKIM should work quite well on Usenet if anyone wants to use it  
(quite a lot of posters routinely sign their articles with PGP, which  
makes them difficult to spoof).

And I don't see why the DKIM signature should not survive the gateway  
unless the gateway did something really stupid like removing the  
Newsgroups header (which would quite likely be signed, but is quite  
harmless if left in an email - enables people to see that it was  
originally a Usenet article). And the Gateway would be even stupider if it  
tried to alter the From, Message-Id, Date, etc which are the same in both  
media. There might be trouble if it tried to replace any Sender header  
with itself.
> That would be a swell place to check signatures.

Indeed so.

---

From: Dave Crocker <[email-masked]>
Date: Thu, 18 Oct 2007 09:50:15 -0700

Folks,

On reviewing the current SSP draft, I'm finding myself unclear about the scope 
of the document.

So I thought I'd ask a couple of very basic questions:

      1. Is the SSP specification intended (or allowed) to modify the 
semantics of the DKIM Base specification (RFC 4871)?

         I am hoping that folks do *not* intend to change the semantics of the 
base specification, since any change will disrupt adoption of the base.

      2. Does RFC 4871 contain any claims that a DKIM signature carries a 
claim by the signer that any of the body or header content is "correct" or 
"truthful"?

         I ask because I believe it does not carry any such claim and that, 
rather, a DKIM signature asserts a very generic degree of signer 
"responsibility" which does not extend to formal claims of correctness.

d/
-- 

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

---

From: Jim Fenton <[email-masked]>
Date: Fri, 19 Oct 2007 08:46:34 -0700

I'll take a shot at these...

Dave Crocker wrote:
>         I am hoping that folks do *not* intend to change the semantics
> of the base specification, since any change will disrupt adoption of
> the base.

I thought we had been very clear about this:  SSP is intended to provide
additional information beyond that in the signature(s), and particularly
in the absence of an originator signature.

>      2. Does RFC 4871 contain any claims that a DKIM signature carries
> a claim by the signer that any of the body or header content is
> "correct" or "truthful"?
>
>         I ask because I believe it does not carry any such claim and
> that, rather, a DKIM signature asserts a very generic degree of signer

4871 indeed uses a broad notion of "responsibility".  However, in the
case where the signing address is the same* as some other header field,
such as 2822.From, I don't see how a signer can be responsible for a
message that uses its own address without an implied claim that the
address is correct.

* "same" meaning that the i= address is either the identical, or that
the i= address has the same domain if i= has no specified local part.

-Jim

---

From: Douglas Otis <[email-masked]>
Date: Fri, 19 Oct 2007 12:07:30 -0700

On Oct 19, 2007, at 8:46 AM, Jim Fenton wrote:

>>  I am hoping that folks do *not* intend to change the semantics of  
>> the base specification, since any change will disrupt adoption of  
>> the base.
>
> I thought we had been very clear about this:  SSP is intended to  
> provide additional information beyond that in the signature(s), and  
> particularly in the absence of an originator signature.

If such a change does occur, it should be clearly indicated as being  
a change.

> 4871 indeed uses a broad notion of "responsibility".  However, in  
> the case where the signing address is the same* as some other  
> header field, such as 2822.From, I don't see how a signer can be  
> responsible for a message that uses its own address without an  
> implied claim that the address is correct.
>
> * "same" meaning that the i= address is either the identical, or  
> that the i= address has the same domain if i= has no specified  
> local part.

It would be a bit more accurate to use the term "signing domain",  
rather than "signing address".  An address (the i= parameter) is  
optional, after all.

The optional i=  parameter represents the identity of the user or  
agent (e.g., a mailing list manager) on who's behalf the message was  
signed.  The base specification makes no statement that this optional  
parameter SHOULD NOT be applied when the user or agent identity has  
not been validated.  (See the informative note about whether the i=  
parameter can be trusted.)  Without a stipulation that the i=  
parameter MUST BE validated, and exactly which validation mechanisms  
must be used within the base specification, it would be a significant  
change to assume inclusion of the i= parameter thereby confers  
responsibility to validate identities onto signing domains.  There  
are also cases where the i= parameter can not be applied, such as  
when the signing domain is within a sub-domain of the identity, or  
when the identity is within another domain.  Would you envision the  
blocking of messages which did not include the i= parameter  
containing the local-part?

The TPA-SSP permits less stringent authorizations rather than  
identify validations.  Identity validation goes well beyond the  
intent of DKIM.  Rather than bestowing the validity of an identity  
onto a message, an identity in question would be able to authorize  
the signing domain.

It might be useful to restate little can be assumed based upon the i=  
parameter within the SSP.  This could be changed by an SSP assertion  
that the signing domain validates all identities, and clarifies what  
this assertion actually implies.

-Doug

---

From: Jim Fenton <[email-masked]>
Date: Fri, 19 Oct 2007 14:27:12 -0700

Douglas Otis wrote:
>>> claim by the signer that any of the body or header content is
>>> "correct" or "truthful"?
>>>
>> case where the signing address is the same* as some other header
>> field, such as 2822.From, I don't see how a signer can be responsible
>> for a message that uses its own address without an implied claim that
>> the address is correct.
>>

The parameter is optional, but if absent, the signing address (what i=
represents) takes the default value of the d= parameter (preceded by an
@).   There is always a signing address.  I get tired of typing "i= (or
d= in its absence)" every time I talk about i=, since this is in the
specification, but every time I don't spell this out very explicitly I
need to write a clarifying message.

> responsibility to validate identities onto signing domains.  There are
> also cases where the i= parameter can not be applied, such as when the
> signing domain is within a sub-domain of the identity, or when the
> identity is within another domain.  Would you envision the blocking of
> messages which did not include the i= parameter containing the
> local-part?

The validation of the local-part of i= is that it must (wildcard) match
the value of g=, if present, in the key record.  An agent in possession
of a private key that does not constrain the local part (no g= in the
key record, or g=*) is one that is trusted by the domain to take
responsibility for any message on behalf of any address in the domain. 
So the i= parameter is already validated.

The cases you cite:  signing domain is within a subdomain of the
identity, or when the identity is within another domain, are
intentional.  example.com should not be taking responsibility for
messages on behalf of bigbank.com.  If it has a legitimate reason to do
this, it is delegated a key by bigbank.com and signs as that domain.

I would not envision (and can think of absolutely no reason to) blocking
messages without an i= parameter specifying a local-part.  The ability
to specify i= without a local-part was done for a reason.

-Jim

---

From: Douglas Otis <[email-masked]>
Date: Fri, 19 Oct 2007 16:16:42 -0700

On Oct 19, 2007, at 2:27 PM, Jim Fenton wrote:

> The parameter is optional, but if absent, the signing address (what  
> i= represents) takes the default value of the d= parameter  
> (preceded by an @).   There is always a signing address.  I get  
> tired of typing "i= (or d= in its absence)" every time I talk about  
> i=, since this is in the specification, but every time I don't  
> spell this out very explicitly I need to write a clarifying message.

When an i= parameter defaults, only the signing domain is specified.   
Here the term "signing domain" always applies without explanation.   
In addition, there is no such thing as a "signing address".  This  
implies a process that does not exist.

Someone might consider an email-address within a message's header  
matching an i= parameter (default or otherwise) as having been  
verified based upon this term "signing-address" rather than "signing- 
domain".  This is _not_ how the base specification has been written,  
nor is this in agreement with even an Informational Discussion  
describing use of the i= parameter.

Quote from the base specification Informative Discussion:

Constraints between the value of the "i=" tag and other identities in  
other header fields seek to apply basic authentication into the  
semantics of trust associated with a role such as content author.   
Trust is a broad and complex topic and trust mechanisms are subject  
to highly creative attacks. The real-world efficacy of any but the  
most basic bindings between the "i=" value and other identities is  
not well established, nor is its vulnerability to subversion by an  
attacker.  Hence reliance on the use of these options should be  
strictly limited.  In particular it is not at all clear to what  
extent a typical end-user recipient can rely on any assurances that  
might be made by successful use of the "i=" options.

>> agent (e.g., a mailing list manager) on who's behalf the message  
>> was signed.  The base specification makes no statement that this  
>> optional parameter SHOULD NOT be applied when the user or agent  
>> identity has not been validated.  (See the informative note about  
>> whether the i= parameter can be trusted.)  Without a stipulation  
>> that the i= parameter MUST BE validated, and exactly which  
>> validation mechanisms must be used within the base specification,  
>> it would be a significant change to assume inclusion of the i=  
>> parameter thereby confers responsibility to validate identities  
>> onto signing domains.  There are also cases where the i= parameter  
>> can not be applied, such as when the signing domain is within a  
>> sub-domain of the identity, or when the identity is within another  
>> domain.  Would you envision the blocking of messages which did not  
>> include the i= parameter containing the local-part?
>
> The validation of the local-part of i= is that it must (wildcard)  
> match the value of g=, if present, in the key record.  An agent in  
> possession of a private key that does not constrain the local part  
> (no g= in the key record, or g=*) is one that is trusted by the  
> domain to take responsibility for any message on behalf of any  
> address in the domain.  So the i= parameter is already validated.

The domain is responsible for messages it sends, with or without a  
DKIM signature.  Adding a DKIM signature allows messages  
retransmitted on their behalf to be identified as having been sent by  
that domain.  A DKIM signature makes no strong statement regarding  
whether email-addresses within a message will have been validated in  
some undefined fashion.  You appear to be claiming otherwise.  This  
seems to be rather dangerous and wishful thinking.  Don't oversell  
what DKIM provides.

> messages on behalf of bigbank.com.  If it has a legitimate reason  
> to do this, it is delegated a key by bigbank.com and signs as that  
> domain.
>
> I would not envision (and can think of absolutely no reason to)  
> blocking messages without an i= parameter specifying a local-part.   
> The ability to specify i= without a local-part was done for a reason.

Including a local-part within an optional parameter does not have a  
clear, well defined requirement.  Any reasons or requirements for  
include the i= parameter has been specified with "mights" and  
"mays".  Hence the i= parameter SHOULD NOT be relied upon.  It is  
also wholly improper to declare the i= parameter as the signing  
entity.  The signing entity is the d= domain.  Refer to the signing  
entity as the signing domain.

-Doug

---

From: "Charles Lindsey" <[email-masked]>
Date: Mon, 22 Oct 2007 12:07:42 +0100

> It would be a bit more accurate to use the term "signing domain", rather  
> than "signing address".  An address (the i= parameter) is optional,  
> after all.
>
> The optional i=  parameter represents the identity of the user or agent  
> (e.g., a mailing list manager) on who's behalf the message was signed.   
> The base specification makes no statement that this optional parameter  
> SHOULD NOT be applied when the user or agent identity has not been  
> validated.  (See the informative note about whether the i= parameter can  
> be trusted.)  Without a stipulation that the i= parameter MUST BE  
> validated, and exactly which validation mechanisms must be used within  
> the base specification, it would be a significant change to assume  
> inclusion of the i= parameter thereby confers responsibility to validate  
> identities onto signing domains.  There are also cases where the i=  
> parameter can not be applied, such as when the signing domain is within  
> a sub-domain of the identity, or when the identity is within another  

I think these questions are best addressed by examining scenarios where a  
signed message somehow does NOT originate from its purported From: (or  
Sender:), and whether the signer OUGHT (whatever that means) to have taken  
more care.

So, for an extreme example, suppose example.com is running an open relay  
and happily signs everything that passes through. So any scammer who wants  
to pretend to be From: [email-masked] simply submits his message to  
that open relay, and it comes out signed. I think we would all agree that  
example.com is being grossly irresponsible in that situation, whether he  
has technically breached 4871 or not. And if 4871 does allow that  
behaviour, then it is surely too weak, since the minimum that a signature  
shoudl imply is that this message did indeed originate within our domain.

But, to go further, if the signer goes to the trouble of including an "i="  
(which he is not obliged to do), then surely recipients are entitled to  
assume he did so for some good reason. So if he said  
i=subdomain.example.com, then surely the From/Sender can be expected to be  
 from that subdomain; and if he said i=[email-masked], then surely  
recipients can assume that 'someone' had indeed played some part in  
sending it.

Otherwise, what is the point of signatures?

---

From: Jon Callas <[email-masked]>
Date: Mon, 22 Oct 2007 13:37:17 -0700

> So if he said i=subdomain.example.com, then surely the From/Sender  
> can be expected to be from that subdomain; and if he said  
> i=[email-masked], then surely recipients can assume that  
> 'someone' had indeed played some part in sending it.
>

Absolutely not. DKIM is a protocol in which one administrative domain  
speaks primarily to other administrative domain. It's not a domain-to- 
user protocol nor a user-to-anything protocol. The i= parameter can  
be anything the signing domain wants it to be. It is unlikely to be  
an outright lie (for example, I mark all mail coming from alice with  
bob), but it may be.

Suppose you have "[email-masked]" whereby any salescritter can  
send an email coming from the sales department. Both Alice and Bob  
are sending emails, and the DKIM signer is going to mark it as  
"[email-masked]". That's well enough, because it doesn't matter to  
you if Alice or Bob sent it.

However, unbeknownst to you, Alice has told Marketing about their  
fancy mail system and because of that Marketing mail also gets marked  
as i=[email-masked]. To make things worse, Bob told the HR  
department and all their job recruiting mail also goes out from that  
MTA and thus is marked as sales as well.

The IT staff knows about this and isn't happy, but they either have  
to turn a blind eye to it or set up servers from Marketing and HR,  
and that's not in the budget. So they just turn a blind eye to it.

	Jon

---

From: Mark Delany <[email-masked]>
Date: Mon, 22 Oct 2007 14:16:52 -0700

On Oct 22, 2007, at 1:37 PM, Jon Callas wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>

I liken i= to IDENT (RFC1413). The values *may* be meaningful to the  
administrative domain, but that's all that can be said about it.

Mark.

---

From: Douglas Otis <[email-masked]>
Date: Mon, 22 Oct 2007 16:40:48 -0700

On Oct 22, 2007, at 2:16 PM, Mark Delany wrote:

> I liken i= to IDENT (RFC1413). The values *may* be meaningful to  
> the administrative domain, but that's all that can be said about it.

I agree with both of these statements.

There is only one requirement expressed by the base draft.  The  
domain of the i= parameter, when present, must be the same or within  
a sub-domain of the d= parameter, otherwise the signature is invalid.

Having the i= parameter match an address within some originating  
header may prioritize signature evaluation, as not all signatures may  
be checked.  Ensuring acceptance would be the intent of the i=  
parameter, rather than indicating who authored the message.  (See  
section 4.2.)  To even determine whether the i= parameter matches  
some header may also involve internationalization translations.  It  
seems doubtful this part of DKIM will safely play a significant role  
within any user interface.

For example:

From: [email-masked]
DKIM-Signature: i=[email-masked]; d=exmaple.com

Per DKIM base spec section 6.3

"If the message is signed on behalf of any address other than that in  
the From: header field, the mail system SHOULD take pains to ensure  
that the actual signing identity is clear to the reader."

Not including billy in the i= parameter might create acceptance  
problems based upon section 4.2, and 6.3 stipulations.

The base specification does not state that the i= parameter must be  
an accurate indicator of who authored the message.  Instead, it  
suggests that by not including a matching identity, the signature may  
not be evaluated, or that the From header may not be presented as  
desired.  Instead, the base specification offers good reasons for  
signing domains to not care whether an i= parameter has been  
validated.  From their view, the i= parameter should be included to  
improve the acceptance and presentation of your domain's messages.   
Recipients, on the other hand, should be advised to ignore this now  
meaningless parameter.

-Doug

---

From: Jeff Macdonald <[email-masked]>
Date: Tue, 23 Oct 2007 11:07:35 -0400

> administrative domain, but that's all that can be said about it.

It would be very useful. Think

d=bigmarketingcompany.com
i=@brandA.bigmarketingcompany.com

d=bigmarketingcompany.com
i=@brandB.bigmarketingcompany.com

d=bigmarketingcompany.com
i=@brandC.bigmarketingcompany.com

etc.

One signing domain, one DKIM entry in DNS, but many identities.

-- 
:: Jeff Macdonald | Director of Messaging Technologies
:: e-Dialog | [email-masked]
:: 131 Hartwell Ave. | Lexington, MA 02421 
:: v: 781-372-1922 | f: 781-863-8118 
:: www.e-dialog.com

---

From: Jim Fenton <[email-masked]>
Date: Tue, 23 Oct 2007 16:11:49 -0700

Charles Lindsey wrote:
> But, to go further, if the signer goes to the trouble of including an
> "i=" (which he is not obliged to do), then surely recipients are
> entitled to assume he did so for some good reason. So if he said
> i=subdomain.example.com, then surely the From/Sender can be expected
> to be from that subdomain; and if he said i=[email-masked], then
> surely recipients can assume that 'someone' had indeed played some
> part in sending it.
>
In addition to the points made by others, I'd like to point out that
there are no semantics associated with the presence or absence of the i=
parameter.  There is always a signing identity; if d=example.com and the
signing identity happens to be @example.com, then the i= parameter may
be omitted.

We're straying quite a bit from the SSP topic.  I'd still like to get
actual feedback on that draft.

-Jim

---

From: John Levine <[email-masked]>
Date: 24 Oct 2007 03:48:36 -0000

>i=@brandB.bigmarketingcompany.com

Useful to whom?  I have little interest as a mail receiver sorting out
an ESP's different campaigns, and I suspect I'm not alone.  (This was
the same fallacy that was behind the failed Project Lumos.)

You're welcome to put whatever tracking stuff you want into your mail,
but I'm going to maintain one reputation for you regardless of the
stuff.

R's,
John

---

From: Jeff Macdonald <[email-masked]>
Date: Wed, 24 Oct 2007 08:33:08 -0400

> but I'm going to maintain one reputation for you regardless of the

That is an interesting view. I can accomplish the same by using
sub-domains in d= instead. Are you simpy going to strip
sub-domains from d= too?

It is interesting that receivers (Hotmail/AOL/Yahoo) suggest to senders
to separate their different type of mail streams
(transactional,marketing,etc) by using IPs. The same can be
accomplished with DKIM and i=.

I also hadn't realized that DKIM was strictly meant to benefit
receivers.

---

From: John L <[email-masked]>
Date: Wed, 24 Oct 2007 11:23:39 -0400 (EDT)

> sub-domains in d= instead. Are you simpy going to strip

Honestly, I'll do whatever seems easiest in my goal to deliver the mail my 
users want, which may or may not be the mail you think they want.  The 
best thing for senders to do, as you note below, is to divide up the mail 
stream in ways that make life easier for receivers.

> accomplished with DKIM and i=.

Indeed, since that makes it easier to handle the ads their users don't 
care about differently from the transactions they want.  But I can't help 
but note that your example above was different clients, not different 
categories.

> I also hadn't realized that DKIM was strictly meant to benefit

It benefits senders to the extent that receivers can decide more 
accurately whether to deliver the mail they get sent.

Regards,
John Levine, [email-masked], Primary Perpetrator of "The Internet for Dummies",
Information Superhighwayman wanna-be, http://www.johnlevine.com, ex-Mayor
"More Wiener schnitzel, please", said Tom, revealingly.
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Jeff Macdonald <[email-masked]>
Date: Wed, 24 Oct 2007 11:34:11 -0400

On Wed, Oct 24, 2007 at 11:23:39AM -0400, John L wrote:
> users want, which may or may not be the mail you think they want.  The best 
> thing for senders to do, as you note below, is to divide up the mail stream 
> in ways that make life easier for receivers.
>
> Indeed, since that makes it easier to handle the ads their users don't care 
> about differently from the transactions they want.  But I can't help but 
> note that your example above was different clients, not different 
> categories.

Ah, I see the disconnect. bigmarketingcompany is not the same as ESP.
Here's a better example:

d=mattel.com
i=@barbie.mattel.com

d=mattel.com
i=@fisher-price.mattel.com

d=mattel.com
i=@hotwheels.mattel.com

d=mattel.com
i=@american-girl.mattel.com

---

From: John L <[email-masked]>
Date: Wed, 24 Oct 2007 11:51:08 -0400 (EDT)

> i=@american-girl.mattel.com

Unless there is some reason to think that Barbie has better list 
management practices than, say, Felicity Merriman, I suspect that from a 
receiver's point of view one piece of pricey Chinese plastic is the same 
as another.

R's,
John

---

From: Hector Santos <[email-masked]>
Date: Wed, 24 Oct 2007 11:57:43 -0400

> I also hadn't realized that DKIM was strictly meant to benefit

Did you really think DKIM will alter the deeply embedded mail filtering 
landscape?  :-)

That is why I always said, the only real true benefit of DKIM is FAILURE 
analysis.   Receivers will protect senders from FORGERY when unexpected 
FAILURE occurs, and it will protect receivers with more high true 
positives filtering.

I do hope the DMA industry does not get blinded by the false idea DKIM 
validation of their mail is going to give them a free pass.  I would 
never trust it.  But if is it FAILURE, maybe you don't want your 
reputation further ruined by passing it on.  If you don't care, when why 
should the receiver?

For us to even bother signing mail, we have to have some SSP assurance 
that receivers are going to DUMP forged mail.  Otherwise, to me, there 
is no payoff - but just glorified worthless overhead.

-- 
Sincerely

Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com

---

From: Jeff Macdonald <[email-masked]>
Date: Wed, 24 Oct 2007 14:34:00 -0400

> Did you really think DKIM will alter the deeply embedded mail filtering 

Like you at one time said, I was hoping for a deterministic result. ;)

<snip>
> For us to even bother signing mail, we have to have some SSP assurance that 
> receivers are going to DUMP forged mail.  Otherwise, to me, there is no 
> payoff - but just glorified worthless overhead.

I haven't had a chance to read the SSP doc, but I heard it uses i= for that
case.

---

From: "Patrick Peterson" <[email-masked]>
Date: Sat, 27 Oct 2007 00:24:17 -0700

> "correct" or 
I agree. RFC 4871 does not contain claims that a DKIM signature implies
content is "truthful".

Your intent is unclear from your question: if we are both right, is this
a good thing? Or do we need to modify RFC 4871?

pat

---

From: Dave Crocker <[email-masked]>
Date: Sat, 27 Oct 2007 08:13:47 -0700

> a good thing? Or do we need to modify RFC 4871?

Discussion about raw DKIM signing sometimes seems to have the underlying view 
that the From field is validated as being accurate. At the least, this seems 
to vary among different folk. I wanted to see whether there is a clear view 
one way or the other.

I'm not suggesting "fixing" DKIM.  I'm seeking clarity among the community. 
(It's a California thing.)

d/

-- 

   Dave Crocker

---

From: "Charles Lindsey" <[email-masked]>
Date: Mon, 29 Oct 2007 10:55:39 -0000

On Sat, 27 Oct 2007 16:13:47 +0100, Dave Crocker <[email-masked]> wrote:

> Discussion about raw DKIM signing sometimes seems to have the underlying  
> view that the From field is validated as being accurate. At the least,  
> this seems to vary among different folk. I wanted to see whether there  
> is a clear view one way or the other.

I think it is clear from replies so far that a DKIM signature certifes no  
more than "This is the state of the headers at the time I constructed the  
signature", which is rather weak.

OTOH, there is that mention of "responsibility" which seems to imply  
something stronger; but since "responsibility" is not defined, it is still  
rather meaningless.

I suppose there is also an implication in a signature that "I am  
authorised to issue signatures on behalf of the domain in question", but  
that is still rather weak.

But again, since the whole point of DKIM is to enable one to detect  
messages that did not originate from where they purport to have originated  
(such signatures ought to fail), it would seem that RFC 4871 really is too  
weak to fulfil that purpose.
>
> I'm not suggesting "fixing" DKIM.  I'm seeking clarity among the  
> community. (It's a California thing.)

So I think RFC 4871 ought to be "fixed" (unless we can find some way of  
fixing it in SSP, for example by enabling the SSP record to assert "we  
only sign where the From/Sender has been verified").

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 29 Oct 2007 11:19:25 +0000

> only sign where the From/Sender has been verified").

(chair headgear on)

I believe that that was all discussed during the development of
4871 and so should absolutely not be revistited now. Whether or
not SSP says somethiing about those headers is a different
matter, though is one that's not mentioned in 5016, and so I'd
expect you've a fairly high barrier to leap to get it into SSP
now.

In other words: we're not reviisting closed issues for fun.

Regards,
Stephen.

---

From: Michael Thomas <[email-masked]>
Date: Mon, 29 Oct 2007 09:44:05 -0700

Charles Lindsey wrote:
>> Discussion about raw DKIM signing sometimes seems to have the 
>> underlying view that the From field is validated as being accurate. 
>> At the least, this seems to vary among different folk. I wanted to 
>> see whether there is a clear view one way or the other.
>
> I think it is clear from replies so far that a DKIM signature certifes 
> no more than "This is the state of the headers at the time I 
> constructed the signature", which is rather weak.

I think it's somewhere between these two. DKIM implementations should
all have access control to which messages do and do not get signed. You
don't what to take responsibility for that which you are not responsible,
after all. This is especially true of origination address (from, 
sender...). I
took a poll at the interop to make certain that implementations had that
access control and was pleasantly surprised that they had considered the
issue.
> something stronger; but since "responsibility" is not defined, it is 
> still rather meaningless.
>
> authorised to issue signatures on behalf of the domain in question", 
> but that is still rather weak.

I have no idea what "strong" or "weak" mean in this context. A dkim
signature is what it is.

> So I think RFC 4871 ought to be "fixed" (unless we can find some way 
> of fixing it in SSP, for example by enabling the SSP record to assert 
> "we only sign where the From/Sender has been verified").
>

This is a useless assertion from the signer, as there is no way that
the receiver can independently verify that they are not lying. In
practice, I don't think this makes a particle of difference as signers
don't want to be taking responsibility for things they aren't responsible
for so there is incentive built in to make that relationship correct,
fsvo "correct". Sorry if that's not absolute enough for you, but the
internet is built on fsvo "correct".

       Mike

---

From: Douglas Otis <[email-masked]>
Date: Tue, 30 Oct 2007 00:35:21 -0700

On Oct 27, 2007, at 8:13 AM, Dave Crocker wrote:

> Patrick Peterson wrote:
>> I agree. RFC 4871 does not contain claims that a DKIM signature  
>> implies content is "truthful". Your intent is unclear from your  
>> question: if we are both right, is this a good thing? Or do we  
>> need to modify RFC 4871?
>

RFC 4871 does not provide a concise definition of what a valid  
signature implies, or indicate any assertion of signed content  
validity.  Nor does RFC 4871 indicate which validations are to be  
applied prior to asserting the i= parameter.  Either fields must be  
to be added to the key, or a separate policy record used in  
conjunction with a valid signature must be added.  A policy record  
for a valid signature would represent additional overhead to that of  
a content validity policy parameter added to the key record.  It  
seems some might be interested in introducing of a policy type  
parameter within the DKIM key.  Some have suggested selector domain  
label conventions as another possible approach.

Value is obtained when a mailing list adds a DKIM signature.  In such  
a case, few would expect the From field to always match that of the  
signing-domain.  It would be possible to add records within the From  
domain that authorize a different signing-domain, while also  
simultaneously asserting a practice of only using authorized signing- 
domains.  This would permit stronger, and yet more flexible policy  
statements aimed at restricting valid sources for a particular  
domain.  The tpa-ssp draft scales to an astounding degree while still  
retaining a deterministic overhead of one or two transactions.  This  
could introduce a safer and far more scalable third-party  
authorization scheme, over that of SPF.  (Assuming a third-party  
authorization mechanism would be desired.)

The concept of delegating a portion of a DNS zone, or continuous  
exchanges of public keys or locations between various administrative  
domains seems wholly unworkable for most situations, such as mailing  
lists.  Should DKIM erode the use of the mailing-list+  One would  
hope not, as mailing-lists represent a fairly practical coping  
mechanism in their own right.

-Doug