Subject: [ietf-dkim] [Fwd: New Version Notification for draft-fenton-dkim-reputation-hint-00]

From: Jim Fenton <[email-masked]>
Date: Thu, 12 Feb 2009 11:31:34 -0800

FYI, I have submitted a short I-D which proposes a way to communicate a
stable identifier in the DKIM-Signature header field which might be
useful in the context of reputation.

Comments appreciated.

-Jim

-------- Original Message --------
Subject: 	New Version Notification for draft-fenton-dkim-reputation-hint-00
Date: 	Thu, 12 Feb 2009 11:28:18 -0800 (PST)
From: 	IETF I-D Submission Tool <[email-masked]>
To: 	[email-masked]

A new version of I-D, draft-fenton-dkim-reputation-hint-00.txt has been successfuly submitted by Jim Fenton and posted to the IETF repository.

Filename:	 draft-fenton-dkim-reputation-hint
Revision:	 00
Title:		 DKIM Reputation Hint Extension
Creation_date:	 2009-02-12
WG ID:		 Independent Submission
Number_of_pages: 5

Abstract:
This document defines an extension to the DomainKeys Identified Mail
(DKIM) specification to provide an identifier that may be used as a
"hint" by reputation services using DKIM wanting to maintain
reputation information at a finer level of granularity than that of
the signing domain itself.

The IETF Secretariat.

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

---

From: Sean Shen <[email-masked]>
Date: Fri, 13 Feb 2009 15:28:52 +0800

Hi, Jim,
I just read the draft and feels not sure about some point:
In the last paragraph of section 1, you said:
  " In order to permit useful reputation accrual, the value of the
   reputation tag will typically need to be stable over a relatively
   long period of time.  The use of a tag which is independent of other
   identifiers (such as email address) supports this need by providing
   continuity, even when other identifiers change. "
After reading this paragraphy, I found I was not sure about to whom the tage
belong. You said it's independent of email address. From the first example
case in section 1, it  looks like each tag belongs to a user. But a user
might have both premium and free accounts which have different potential of
abuse, as you mentiond in the section example case. 
The purpose of such a tag is to provide a finer level  of granularity than a
domain, but it's not clear which level it is.   

Best,

Sean

---

From: Jim Fenton <[email-masked]>
Date: Fri, 13 Feb 2009 11:53:55 -0800

> domain, but it's not clear which level it is.

Sean,

The use cases given in the draft are examples of how the r= value can be
applied.  I intentionally picked use cases that make use of different
levels of granularity to describe a range of ways that r= could be used.

Different domains business models, and will therefore suggest different
ways of doing finer-grained reputation.  Some domains may put the email
address, or part of it, in the r= tag, and that's OK for them to do. 
Others will probably put something else, perhaps not quite that
fine-grained, in r=.  It's up to them.  The useful thing is that the
reputation algorithm or service doesn't need to know what the business
model is in order to use the r= value; it's just a suggestion on the
part of the signer.

-Jim

---

From: "J.D. Falk" <[email-masked]>
Date: Mon, 16 Feb 2009 12:57:40 -0800

> useful in the context of reputation.

If you've got a reputation system geared towards predicting bad traffic 
(what I call the "bad/not bad" model), you have to seek identifiers which 
the bad actor cannot easily change.  It'd be trivially simply for a bad 
actor to offer a different reputation hint in each message, confusing 
reputation systems & clogging up databases -- so a smarter system will fall 
back to d=, or the last-hop IP, or other data.

If you've got a reputation system targeting towards predicting good traffic 
(the "good/not good" model, usually used as an input to a certification or 
accreditation process), then the entity will almost always want the good 
reputation of one mail stream to have a positive impact on other mail 
streams.  So while they may use i= to opaquely indicate different streams, 
they're unlikely to include a reputation hint which reduces the likelihood 
of that transitive positive reputation.

In other words: bad guys would have an incentive to use this reputation 
hint.  Good guys wouldn't; or if they do, it'll be for reasons which are 
entirely opaque to the verifier.  Just like i= today.

Suggestion: leave i= opaque, and let's see what operators (on both ends of 
the transaction) do with it.

-- 
J.D. Falk
Return Path Inc
http://www.returnpath.net/
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Suresh Ramasubramanian <[email-masked]>
Date: Mon, 16 Feb 2009 14:30:43 -0800

> the transaction) do with it.

+1 - leaving i= opaque subject to out of band agreements between
sender and receiver is the way to go.
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Jim Fenton <[email-masked]>
Date: Tue, 17 Feb 2009 15:46:11 -0800

J.D. Falk wrote:

Jim Fenton wrote:

Comments appreciated.

True.  This is noted in the Security Considerations section of the
draft.

Disagree.  One such use case is noted in the draft, where an domain has
a premium service and a free service, and tags signatures accordingly
so that users of the premium service avail themselves of the better
reputation that service might have.

But i= isn't opaque, not as a whole anyway.  It has the syntax of an
email address, and the domain part of that address MUST be the same as
or a subdomain of the d= value.

Introducing r= provides a tag that really is opaque, as a whole, and
doesn't conflict with other DKIM extensions that might want to use i=
in a non-opaque way.

-Jim

---

From: John Levine <[email-masked]>
Date: 18 Feb 2009 23:11:59 -0000

>a premium service and a free service, and tags signatures accordingly so
>that users of the premium service avail themselves of the better

Right, but that has nothing to do with i=.  They'll use something like
d=foo.example and d=premium.foo.example.  The reason they do that is
because that's the way to ensure that receivers will see them as two
streams.

>or a subdomain of the d= value.

I fear you may misunderstand what opaque means.  There are similar
syntactic constraints on message ID's, but they're just as opaque.  A
receiver can verify that the field meets the mechanical rules, but
that doesn't tell you anything useful about the field's semantics, it
just tells you whether the sender has broken software.

R's,
John

---

From: Jon Callas <[email-masked]>
Date: Wed, 18 Feb 2009 16:10:24 -0800

> email address, and the domain part of that address MUST be the same  
> as or a subdomain of the d= value.
>

I think I want to say just a few things about "opaque" as a term of  
art, and perhaps this needs to flow back into the errata or something.

When I was an API designer, we would often return from the system to  
the application an "opaque" identifier.

Usually, the opaque identifier was a pointer, either to an internal  
data structure, or another pointer that was the actual pointer to the  
structure. People who would write code could (and did) use it as a  
pointer, reach into the data structures and do stuff. This worked, but  
was unsupported. If the underlying private data structure changed, the  
code that used the opaque identifier would break.

The relatively few times the opaque identifier wasn't a pointer, it  
was an array index into structures or pointers to structures.

If you consider C's standard IO, you have "file pointers" that are  
indeed pointers into implementation-dependent things, or "file  
descriptors" that are array indexes.

These are opaque identifiers.

People can, and do, use these things but the code that does is highly  
implementation and version dependent.

So must it be with i=.

There's nothing wrong with a receiver looking at (e.g.) Yahoo!'s i=  
and noting that it is exactly an email address and processing it. But  
if Yahoo! changes to using a hex string that is the internal user ID,  
the receiver must cope.

All that opacity means is that the receiver is on their own when they  
peer into it. The majority of the time, i= will be precisely an email  
address, just as the majority of the time a C "FILE *" will be a  
pointer to a data structure. It's just not guaranteed to be portable  
nor invariant.

	Jon

---

From: Hector Santos <[email-masked]>
Date: Thu, 19 Feb 2009 08:54:45 -0500

Jon Callas wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> 

Jon, good points.

Shouldn't the errata simply say the i= is Identity Assessor defined 
and the only prerequisites is the RHS @domain syntax.

    i = opaque @ rfc4871.defined

I think must is made about "identity assessors", perhaps maybe modeled 
or framed around existing trust based services and it is they that is 
requiring the i= input.  So I think the errata is trying to say:

   "Look, we i= know its not well undefined, we see it as opaque.
    But regardless of it being opaque or not, it MUST be passed
    to Identity Assessors."

I think this is short changing that can be passed to any augmented, 
add-on technology, in-house or otherwise.

I think maybe a simple solution would to state something to the effect:

   Receivers "SHOULD" make the following information available
   for potential integrated solutions:

    - DKIM-Signature Headers

        - If multiple, only one valid is required?

    - DKIM result

        - Possible Authentication-Results  Headers

    - Additional Headers as defined by Identity Assessors the
      implementation wishes to support.

This is important for systems that happen to transform final 
destination  mail storage that is not exactly 2822.

Here is an example model as I see it:

For SMTP, lets look at the SMTP process model data points:

    CIP  = connection IP address
    CDN  = client domain name (EHLO/HELO)
    RP   = return path (MAIL FROM)
    FP   = forwarding path (RCPT TO)
    PL   = 2822 Payload (DATA)

For the sake of illustration, SPF has to his process model:

    SPF_RESULT  = SPF(CIP, CDN, RP)

That is all SPF needs to produce a result.

Like wise, DKIM-base can be modeled as:

   (1) DKIM_RESULT = DKIM(PL)

Why only PL?

Per specs, this is minimum requirement for DKIM-base. It means DKIM 
can be used in in-transient SMTP sessions or POST SMTP operations or 
even non-SMTP transport environments.  All it really needs is the 2822 
payload.  The DKIM verification function is not limited to being 
called during the SMTP session.  The mail (payload) can be accepted by 
SMTP to be processed in a delayed fashion.

In either case,

    What is DKIM_RESULT?
    Where it is saved?

This is important because it will help the design for other integrated
DKIM processors or as Dave calls this - Identity Accessors.  I call
them "Batteries." <g>

For an in-house integrated system, they can solved this more easily.
They have control of all I/O and storage.  Its all internal.

But the design for a generic service offering is different.  So it is 
they that need to define what is required. So the question becomes:

   (2) OVERALL_RESULT = DKIM_ACCESSOR( ??? )

What is passed to the DKIM_ACCESSOR() ?

That depends on the add-on application.  But I think Dave' errata is 
saying,  d=/i= must be passed to Identity Accessors.

Ok fine, but I ask why?

Is this because of some perceived or existing trusted-service out
there and that is what they needs to function?

Why not other headers? Why not the Authentication-Results?  Why can't
that be the passed?

What not passed SPF results or SMTP process state variables?

This is all important because it helps define the API, storage
methods, and the designs for making these "call outs".

So this is why I think we should basically state what are the formal 
DKIM-BASE processing outputs that "SHOULD" be stored, regardless of 
what Identity Assessors.

The pool of data that is general available will be:

  - SMTP Process Variables

    CIP  = connection IP address
    CDN  = client domain name (EHLO/HELO)
    RP   = return path (MAIL FROM)
    FP   = forwarding path (RCPT TO)
    PL   = 2822 Payload (DATA)

  - DKIM Verification

    DKIM_RESULT
    DKIM-Signature Header (from PL)
    Authentication-Results (added DKIM() verifier)

In my opinion, it is the identify assessors that need to cope and live 
with this reality of whats possible.  It it the IA that needs to 
define what it wants for input.

I don't think the DKIM specification should be changed to say only the 
I= is required to be passed.

Finally, just consider John's Levine VBR system.   Here, its process 
model would be:

    VBR_RESULT = VBR(DKIM_RESULT, VBR_HEADER)

So by stating the the DKIM-BASE system should make the Payload header 
available for potential higher level add-ons, at at minimum, it SHOULD 
consider storing or making available the 2822 message block.

-- 
Sincerely

Hector Santos
http://www.santronics.com

---

From: Douglas Otis <[email-masked]>
Date: Thu, 19 Feb 2009 09:33:10 -0800

On Feb 18, 2009, at 3:11 PM, John Levine wrote:

>> Disagree.  One such use case is noted in the draft, where an domain  
>> has a premium service and a free service, and tags signatures  
>> accordingly so that users of the premium service avail themselves  
>> of the better reputation that service might have.
>
> Right, but that has nothing to do with i=.  They'll use something  
> like d=foo.example and d=premium.foo.example.  The reason they do  
> that is because that's the way to ensure that receivers will see  
> them as two streams.

While segregating reputations through the use of signing sub-domains  
to that of an email-domain might be how DKIM could be used, it would  
be establishing a dangerous precedent to also consider this to be a  
means to meet the goals established by the DKIM charter of preventing  
domain spoofing.  This would suggest sub-domains are authoritative for  
parent domains. :^(

>>  Suggestion: leave i= opaque, and let's see what operators (on both  
>> ends of the transaction) do with it.
>>
>> But i= isn't opaque, not as a whole anyway.  It has the syntax of  
>> an email address, and the domain part of that address MUST be the  
>> same as or a subdomain of the d= value.
>
> syntactic constraints on message ID's, but they're just as opaque.   
> A receiver can verify that the field meets the mechanical rules, but  
> that doesn't tell you anything useful about the field's semantics,  
> it just tells you whether the sender has broken software.

Perhaps a better way to state what is meant when there is no direct  
association between that of the signing domain (d= value), or that of  
the "on-behalf-of" identity (i= value) would be to describe these  
values as either "Associated" or "Unassociated".

When the d= value can not be associated with an email-address domain  
(where even parent domains would also be excluded), it would represent  
a third-party signature.  When the i= value can not be associated with  
that of an email-address, there should be no expectations that it  
references a valid destination.  It seems both inaccurate and counter  
productive to describe the d= value as ever being opaque, and it seems  
safe to do so for the i= value only when not associated with other  
email-addresses within the message.  Please do not overlook the  
intended goal established for DKIM so soon.

-Doug

---

From: Hector Santos <[email-masked]>
Date: Thu, 19 Feb 2009 13:41:21 -0500

Douglas Otis wrote:
 >> ...

+1.

-- 
Sincerely

Hector Santos