Subject: Re: [ietf-dkim] Proposal: Removal of AUID (i= tag/value)

From: Hector Santos <[email-masked]>
Date: Fri, 01 Apr 2011 13:01:33 -0400

Jim Fenton wrote:

> I am formally proposing that the i= tag
> and supporting text be removed from 4871bis.
> 
> [snip]
> 
> In a conversation with Dave Crocker and Murray Kucherawy, they noted the 
> use of the local part of i= as an opaque identifier.  Its use as such an 
> identifier is not described in any standard, but the relaxation of the 
> current restrictions on the use of i= (that the domain-part be a 
> subdomain of d=, etc.) would result in an incompatibility with RFC 
> 4871-compliant verifiers.  It is, however, possible to remove it 
> entirely without creating a compatibility problem.

By remove, does that mean implementators can safely begin to not offer 
it for Domain signers to use or consider?

Documenting this stuff to layman operators is HARD especially when we 
don't even have a firm grip of its utility or what value it offers. :)

If its one more useless thing we don't have to ambiguously document 
for customer to understand and use with no real verification payoff, 
then +1 to remove i= from DKIM.

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

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

---

From: Jim Fenton <[email-masked]>
Date: Fri, 01 Apr 2011 10:12:47 -0700

On 4/1/11 10:01 AM, Hector Santos wrote:
>> In a conversation with Dave Crocker and Murray Kucherawy, they noted 
>> the use of the local part of i= as an opaque identifier.  Its use as 
>> such an identifier is not described in any standard, but the 
>> relaxation of the current restrictions on the use of i= (that the 
>> domain-part be a subdomain of d=, etc.) would result in an 
>> incompatibility with RFC 4871-compliant verifiers.  It is, however, 
>> possible to remove it entirely without creating a compatibility problem.
>

I should probably have used the term "deprecate" rather than "remove".  
That's correct, an implementation compliant with 4871bis would not 
normally use the i= tag/value in signatures.

> don't even have a firm grip of its utility or what value it offers. :)

That's part of the reason for deprecating the feature:  if people don't 
understand the utility of it, and it is not being used, then it is only 
adding complexity to the spec.

> then +1 to remove i= from DKIM.

Thanks.

-Jim

---

From: Hector Santos <[email-masked]>
Date: Fri, 01 Apr 2011 14:18:52 -0400

> normally use the i= tag/value in signatures.

Ok, so if we begin to "REMOVE" it from the documentation, which I 
think would be better because deprecation suggest some documentation 
regarding the deprecated mechanics remains,  the question is then is 
what advice is provided to current DKIM verifier implementations in 
regards to being prepared to handle legacy usage.

In other words, for current DKIM signers, the advice might be they may 
begin to not offer it in their Signer Setups and for future DKIM 
signer setups, to not consider it at all. For example, this is right 
on for me because we are still getting all the setup and GUI help done 
and removing i= tag would be great to finishing it. I don't have to 
worry about past signer compatibility versions so I can just get rid 
of it.

But for verifiers, old or new, the question is whether the software 
can be simplified to remove the handling legacy usage.  The issue is 
not that software can keep the old logic intact even its not going to 
be used, the issue is when legacy usage is found, what outcome comes 
from it?

Off hand, and I have to go back, I believe seeing some systems using 
Authetication-Results to always include a i= as part of its A-R header 
result whether it was defined or not and when not, a default value is 
displayed.  For example, this is the A-R result for my signature into 
this IETF-DKIM list:

    Authentication-Results: sbh17.songbird.com;
	dkim=pass (1024-bit key) header.i=@isdg.net

My isdg.net signer domain setup does not have a i= defined, yet it is 
showing one in the A-R record when verified by sbh17.songbird.com.

Does that mean, a proposal to remove i= in DKIM-BASE, would imply an 
update to the A-R draft is necessary?

---

From: Michael Thomas <[email-masked]>
Date: Fri, 01 Apr 2011 10:40:43 -0700

On 03/31/2011 02:33 PM, Jim Fenton wrote:
> The direction of the DKIM specifications since RFC 4871 have been to
> rely less and less on the AUID (agent or user identifier, the i= value
> on the signature) to the point that it provides no security benefit.
>    

The working group was bamboozled into the false dilemma
that DKIM had to produce a singular "output". It has all
gone down hill from there. Things that use heuristics like
spam filters thrive with more information, and suffer with
less. So we've destroyed information in the name of aesthetics
while the main consumers of the output thrive on the messy
details.

Mike

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 1 Apr 2011 14:04:04 -0700

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Michael Thomas
> Sent: Friday, April 01, 2011 10:41 AM
> To: Jim Fenton
> Cc: IETF DKIM WG
> Subject: Re: [ietf-dkim] Proposal: Removal of AUID (i= tag/value)
> 

My recollection was that we decided DKIM has to produce at least one specific output, and that the spec needed to identify what that one particular item was.  We never precluded it from making other information available.

OpenDKIM makes the entire signature and result available to the caller, so it can use whatever it wants.  And that doesn't make it non-compliant.

---

From: SM <[email-masked]>
Date: Fri, 01 Apr 2011 14:25:08 -0700

Hi Hector,

[snip]

>update to the A-R draft is necessary?

RFC 5451 is a proposed standard.  It is not a product of the DKIM 
WG.  It's up to the author of that RFC to see whether an update is necessary.

Regards,
-sm

---

From: Hector Santos <[email-masked]>
Date: Fri, 01 Apr 2011 18:03:43 -0400

Just trying to "connect the dots."

SM wrote:
> RFC 5451 is a proposed standard.  It is not a product of the DKIM WG.  
> It's up to the author of that RFC to see whether an update is necessary.
> 
> Regards,
> -sm
> 
>

---

From: Tony Hansen <[email-masked]>
Date: Fri, 01 Apr 2011 18:18:02 -0400

On 3/31/2011 5:33 PM, Jim Fenton wrote:
> on the signature) to the point that it provides no security benefit.  On
> the other hand, a malformed AUID can cause a DKIM signature not to
> verify, and i= currently adds to the complexity of the DKIM
> specification.  For this reason, I am formally proposing that the i= tag
> i= was introduced in RFC 4871 as a mechanism to:
>
> (1) Allow a parent domain to sign for a subdomain, simplifying the
> management of keys.  So if example.com had several subdomains and wanted
> to use the same keys to sign for all of them, it could put the actual
> domain name being used in the i= value (e.g., marketing.example.com) and
> the location where the keys were stored in the d= value (e.g., example.com).
>
> (2) Support finer-grained verification in conjunction with the g=
> tag/value in the key record.  We have already decided to remove the g=
> tag/value in 4871bis.
>
> (3) Support matching with the From address to determine if a signature
> was an Author Signature in SSP.  SSP became ADSP, and WG consensus was
> to match the domain of the From address against the SDID instead.
>
> In order to remove i= from the specification, we need to: ....
> Comments, please.

Interesting. I've been thinking in exactly 180 degrees from that, from 
the point of view of "what would need to be added to make i= useful?" 
The problem I see with i= is the opacity, and as an opaque value with no 
semantics for the localpart of it. If there were a way for a domain to 
indicate exactly what semantics the signer is using for the i= value, 
the combination of that plus the i= value can then be used in various 
ways by the recipient verification engine. For example, our 
implementation would put the username@domain into the i= value when it 
was dealing with an authenticated user mail submission, and otherwise 
leave it blank. If there were a way in the DNS key record to indicate 
those semantics, the recipients could use that information for 
additional processing.

So, -1 without full consideration of what could be done to make it useful.

     Tony Hansen
     [email-masked]

---

From: Michael Thomas <[email-masked]>
Date: Fri, 01 Apr 2011 18:39:15 -0700

> OpenDKIM makes the entire signature and result available to the caller, so it can use whatever it wants.  And that doesn't make it non-compliant.

Read: All outputs are equal, but some outputs are more equal than others.

Mike

---

From: "John R. Levine" <[email-masked]>
Date: 1 Apr 2011 21:51:16 -0400

> For example, our implementation would put the username@domain into the 
> i= value when it was dealing with an authenticated user mail submission, 
> and otherwise leave it blank. If there were a way in the DNS key record 
> to indicate those semantics, the recipients could use that information 
> for additional processing.

Three questions spring to mind:

a) What does "authenticated user" mean, in general for domains you don't 
know?

b) Why should I believe your authenticated user flag?

c) Even if I do believe you, so what?

If bigisp.net has i=[email-masked] and assures you that Boris signs in 
before sending mail, what does that mean?  If the goal is to give every 
user his own reputation stream, the right way to do that is to use 
different signing domains, e.g. d=boris-example-com.bigisp.net.  If you 
want the mail to have both Boris' reputation and the ISP's, sign it twice.

Since the DKIM spec ignores unknown fields in the DKIM-Signature line, 
domains who know each other and want to exchange sorting hints can always 
do so with a private field.  The point of standardizing something like i= 
is to give it useful semantics for mail from people you don't know, but if 
you don't know them, you can't believe any assertions they make, so 
there's no point.

Also, I really do not want to provide a way for mail systems to say, we 
authenticate all our users, so you can just block mail from the ones who 
are sending spam.  Ugh.

Regards,
John Levine, [email-masked], Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. http://jl.ly

PS: My understanding has always been that the motivation for i= was to 
work around uncooperative DNS managers who refused to install enough key 
records to provide a different d= for each reputation stream.  I believe 
that such people exist, but I don't see why it's our job to enable them.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 1 Apr 2011 22:05:35 -0700

Hi SM,

Anyone can propose such an update.  By the rules established in RFC5451, it needs to be modified via publication of an RFC that passes through the IESG.  The DKIM WG could do it, or so could an individual submitter with sponsorship of an AD (or equivalent).

I consider this a low priority though, because after RFC4871bis publishes, signers will gradually stop including "i=", which means verifiers will either switch to producing A-R fields with "header.d" instead of "header.i", or they will still produce the default value of "i=" for their consumers which is probably what they do now for "d="-only signatures anyway.

-MSK
________________________________________
From: [email-masked] [[email-masked]] On Behalf Of SM [[email-masked]]
Sent: Friday, April 01, 2011 2:25 PM
To: Hector Santos
Cc: IETF DKIM WG
Subject: Re: [ietf-dkim] Proposal:  Removal of AUID (i= tag/value)

Hi Hector,

[snip]

Regards,
-sm

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sat, 2 Apr 2011 00:02:17 -0700

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Jim Fenton
> Sent: Thursday, March 31, 2011 2:34 PM
> To: IETF DKIM WG
> Subject: [ietf-dkim] Proposal: Removal of AUID (i= tag/value)
> 
> [...]

[as regular participant, not document editor]

I find myself undecided, and I need to think about it a little more.  I certainly agree that simplifying the specification by removing stuff that provides little use is a good idea, and we've done so with "g=" as well and I'm fine with that.

OpenDKIM's statistics show that almost half of signatures use "i=", in contrast to how few used "g=" in other than the default way.  Of those that do, only about 35% are using it in other than the default way.  So that's at least 17% of signatures overall that are trying to do something with "i=".  That's non-trivial.

Moreover, it's substantially more than the percentage that appear to be using "x=", but we're not considering removing that here.

So it seems like we've got this theory that simpler is better, but we're applying that theory piecemeal.

---

From: Hector Santos <[email-masked]>
Date: Sat, 02 Apr 2011 04:03:01 -0400

Murray S. Kucherawy wrote:

> Moreover, it's substantially more than the percentage that 
> appear to be using "x=", but we're not considering removing 
> that here.
>
> So it seems like we've got this theory that simpler 
> is better, but we're applying that theory piecemeal.
> 

It may not be your intent, but lets not indirectly instill the idea x= 
should be a considered candidate for removal.  This DKIM feature has 
an easy understanding, feel and grasp for utility. It is easy to 
explain to producers and consumers, easy to employ and simply 
something people can actually use if so desired.

i= is a much different issue.

For its functionality, I can't speak I had a full understanding for 
its use cases other than an intent for user level signings. I also 
never understood why it remained over the years when it seemed to be 
something yet fine tuned and there was still the long time concerns of 
its DNS scalability.  Yet, it hung around but seem to become one of 
the DKIM features that would not be used much.

 From the software angle, when the key record g= tag is no longer part 
of the spec, then i= is less software wise required.  Can't speak for 
OpenDKIM, but in the ALT-N (verifier) API, any i= value defined in the 
signature is only applied when a key record g= tag value is defined.

 From the testing standpoint, I found a need to modified the API to 
add an verifier CheckGranularity=1|0 option because we found false 
positives with computational valid signatures but an failed NO 
SIGNATURE result due to a failed g=/i= granularity wildcard string 
comparison checks.  The check option was provided with a noted concern 
it might promote a security loophole if disabled.

 From a documentation standpoint (F1 online help, etc) in describing 
the what, why and when to use reasons for his particular i= option, 
was not easy to do especially when it came to the DNS management aspects.

-- 
Hector Santos

---

From: "John R. Levine" <[email-masked]>
Date: 2 Apr 2011 08:46:32 -0400

> Moreover, it's substantially more than the percentage that appear to be 
> using "x=", but we're not considering removing that here.

I suspect I'm not the only person who'd be thilled if we got rid of x=, 
since it's yet another unverifiable assertion, but I figure we're draining 
one swamp at a time.

Regards,

---

From: Dave CROCKER <[email-masked]>
Date: Sat, 02 Apr 2011 20:32:21 +0200

On 4/1/2011 11:04 PM, Murray S. Kucherawy wrote:
> My recollection was that we decided DKIM has to produce at least one specific
> output, and that the spec needed to identify what that one particular item
> was.  We never precluded it from making other information available.

Just to be very clear about the actual terms of the specification:

 From RFC 5672
>    This Update defines the output of that library to include the yes/no
>    result of the verification and the "d=" value.  In other words, it
>    says what (one) identifier was formally specified for use by the
>    signer and whether the use of that identifier has been validated.
>    For a particular library, other information can be provided at the
>    discretion of the library developer, since developers of assessors --
>    these are the consumers of the DKIM library -- well might want more
>    information than the standardized two pieces of information.
>    However, that standardized set is the minimum that is required to be
>    provided to a consuming module, in order to be able to claim that the
>    library is DKIM compliant.

The language "at least one" does not quite match the actual semantics, since it 
means that the "output" of DKIM can be variable.

The distinction that needs to be made is between formally-specified output vs. 
implementation-specific access to DKIM internals.

d/
-- 

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

---

From: Michael Thomas <[email-masked]>
Date: Sat, 02 Apr 2011 11:49:49 -0700

> implementation-specific access to DKIM internals.

i= was never intended to be "DKIM internals". That's why the entire gambit to
make d= the only show in town sucked.

Mike

---

From: Scott Kitterman <[email-masked]>
Date: Sat, 2 Apr 2011 15:01:43 -0400

On Saturday, April 02, 2011 02:49:49 PM Michael Thomas wrote:
> Dave CROCKER wrote:
> > The distinction that needs to be made is between formally-specified
> > output vs. implementation-specific access to DKIM internals.
> 
> i= was never intended to be "DKIM internals". That's why the entire gambit
> to make d= the only show in town sucked.

+1.

I don't particularly agree with the idea that the work of the working group is 
'done', but it does seem that we'd be better off if we stopped 'improving' 
things sooner rather than later.

Scott K

---

From: Tony Hansen <[email-masked]>
Date: Mon, 04 Apr 2011 13:54:34 -0400

If you want to skim this message, at least please read the comments at 
the bottom.

On 4/1/2011 9:51 PM, John R. Levine wrote:
>> For example, our implementation would put the username@domain into 
>> the i= value when it was dealing with an authenticated user mail 
>> submission, and otherwise leave it blank. If there were a way in the 
>> DNS key record to indicate those semantics, the recipients could use 
>> that information for additional processing.
>
> a) What does "authenticated user" mean, in general for domains you 
> don't know?
>
> If bigisp.net has i=[email-masked] and assures you that Boris signs 
> in before sending mail, what does that mean?  If the goal is to give 
> every user his own reputation stream, the right way to do that is to 
> use different signing domains, e.g. d=boris-example-com.bigisp.net.  
> If you want the mail to have both Boris' reputation and the ISP's, 
> sign it twice.
>
> domains who know each other and want to exchange sorting hints can 
> always do so with a private field.  The point of standardizing 
> something like i= is to give it useful semantics for mail from people 
> you don't know, but if you don't know them, you can't believe any 
> assertions they make, so there's no point.

I disagree with both 1) the assertion about the right way to provide 
per-user reputation streams and 2) your statement about "the point of 
standardizing something like i=".

For #2, DKIM is most useful for positive identification, and i= would 
similarly be most useful for positive identification. Whether you say 
i=[email-masked] or d=auntmary.bigisp.net, that provides useful 
information beyond the d=bigisp.com (or i=@bigisp.com).

For #1, the reputation still resides mostly on the bigisp.com's 
reputation -- you have to trust that reputation to provide useful 
per-user information before you can trust the per-user information -- 
the two don't stand alone. You also would need to have separate DNS 
entries for each individual user.

> Also, I really do not want to provide a way for mail systems to say, 
> we authenticate all our users, so you can just block mail from the 
> ones who are sending spam.  Ugh.

Flip that around: I want to give positive warm fuzzies to mail from the 
users that are authenticated by bigisp.com and are on my positive list.

> work around uncooperative DNS managers who refused to install enough 
> key records to provide a different d= for each reputation stream.  I 
> believe that such people exist, but I don't see why it's our job to 
> enable them.

That's part of the problem with i=: different people had different ideas 
about how it could be useful. And those notions have all gotten 
conflated together into i=. Hence my initial idea of a way to specify 
what information *is* being put into i= by the domain signer.

There're several pieces of secondary information that the domain signer 
can potentially provide. One is information on the user associated with 
the message, another is information on the stream class of the message 
that's been discussed in a separate part of this thread. I'm certain 
that there are a few others.

Perhaps the thing to do *is* to remove i= and then really work on what 
those secondary pieces of information should be. These can all be noted 
by separate extension keywords connected together by the DNS entry and 
the signature.

     Tony Hansen
[email-masked]

---

From: "John R. Levine" <[email-masked]>
Date: 4 Apr 2011 17:49:05 -0400

> information beyond the d=bigisp.com (or i=@bigisp.com).

Is this really true?  My signatures all have an i= that tells you in a 
fairly easy to decode way which user sent the mail.  Does anyone use it? 
Do people really want to use DKIM to do per-user sorting of mail from 
senders who can't manage their own users?

> users that are authenticated by bigisp.com and are on my positive list.

I believe that's what we call "human shields."  Um, no.  This whole model 
of bigisp sending a mixture of legit and forged mail, and using i= to 
assert nice things about the legit mail seems awfully strained.  In my 
experience, if I get a message with a credible signature, one of the 
things that "credible" means is that the From: address is real enough to 
use for message sorting.

> by separate extension keywords connected together by the DNS entry and

We're clearly long past the point where i= can have any useful semantics 
other than as an auditing token for the sender (and, presumably, his 
friends with private knowledge of what his tokens mean.)

I wouldn't be opposed to a strawman proposal of putatively useful sender 
assertions, so long as there's also an explanation of how you decide when 
the assertions are credible.  Lacking private knowledge, the only self 
assertions that should be useful are negative ones, which is more or less 
what ADSP is supposed to be, but you also have the competence issue of 
guessing whether the person making the assertions understands what he's 
saying.

Regards,

---

From: "J.D. Falk" <[email-masked]>
Date: Mon, 4 Apr 2011 15:17:53 -0700

> OpenDKIM's statistics show that almost half of signatures use "i=", in contrast to how few used "g=" in other than the default way.  Of those that do, only about 35% are using it in other than the…

I was about to ask you if there were stats on i= usage.  I agree, that's far too many to just dump it without figuring out why those 35% are using it.

So, count this as -1 towards removing it, at least until we know more.

--
J.D. Falk
the leading purveyor of industry counter-rhetoric solutions

---

From: Michael Thomas <[email-masked]>
Date: Mon, 04 Apr 2011 16:13:22 -0700

> things that "credible" means is that the From: address is real enough to 

An assertion from a large ISP-like domain with only the d= is essentially
useless. Ok, it came though bigisp.com, now what? Bigisp by definition is
going to have some bad actors, so without some other means of differentiation
the signature's domain only tells you that it's from somebody who's going to
have bad actors.

i= is one means for identifying sub-domain level granularity, but it could be
done other ways as well. You could sign an "X-Evil: yes" header as well. The
bigger problem with i= is that its semantics were underspecified because the
working group didn't want to go there. So unsurprisingly we're now in a position
where we have a large user base of signers who put something in i= and we're
not quite sure what they mean by it. Chickens: roost.

Mike

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 5 Apr 2011 10:29:15 -0700

> From: [email-masked] [mailto:[email-masked]] On Behalf Of John R. Levine
> Sent: Friday, April 01, 2011 6:51 PM
> To: Tony Hansen
> Cc: IETF DKIM WG

You had me up to (c).  If I do believe you, why wouldn't I act on your assertions?

---

From: Tony Hansen <[email-masked]>
Date: Tue, 05 Apr 2011 14:32:05 -0400

> You had me up to (c).  If I do believe you, why wouldn't I act on your assertions?

I'm not much interested in the "authenticated user" for domains I don't 
know. However, I'm *very* interested in the "authenticated user" for 
domains that I *do* know.

As for what "authenticated user" means, I think it's a user whose 
identity the domain has verified to their satisfaction, such as through 
a login process.

     Tony Hansen
     [email-masked]

---

From: "John R. Levine" <[email-masked]>
Date: 5 Apr 2011 14:47:38 -0400

> You had me up to (c).  If I do believe you, why wouldn't I act on your 

Because very few assertions are useful in mail sorting.  As it happens, 
all of the i= fields in mail I sign are real, in the sense that they 
reflect an account name that signed in with a password.  Now that you know 
that, how will you change your mail handing?

Regards,

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 5 Apr 2011 12:12:56 -0700

> From: John R. Levine [mailto:[email-masked]]
> Sent: Tuesday, April 05, 2011 11:48 AM
> To: Murray S. Kucherawy
> Cc: IETF DKIM WG

I have lots of mailboxes internally that have mail shoveled to them based on From:.  If the mail is from a source that I trust, "i=" would be just as useful that way.

As a filtering agent at the border, or one protecting lots of sites (a cloud-based filter maybe), I could use "i=" as supplementary reputation information if it's from a domain that I generally trust.  So mail from example.com, which has a good reputation or is whitelisted, can be further vetted using "i=" since I implicitly trust it's being used properly.

---

From: "John R. Levine" <[email-masked]>
Date: 5 Apr 2011 15:29:28 -0400

> I have lots of mailboxes internally that have mail shoveled to them 
> based on From:.  If the mail is from a source that I trust, "i=" would 
> be just as useful that way.

We all filter on From:.  If you know the domain is well-behaved, what's 
the point of using i= rather than From: ?

I'm not trying to be perverse, but this feels a lot like an answer looking 
for a question.

> example.com, which has a good reputation or is whitelisted, can be 
> further vetted using "i=" since I implicitly trust it's being used 
> properly.

Again, I have trouble reading this as other than human shields.  If 
example.com is mostly OK, why should it be anyone else's job to sort out 
the stuff that's not OK?

R's,
John

---

From: "John R. Levine" <[email-masked]>
Date: 5 Apr 2011 15:35:41 -0400

> domains that I *do* know.

Maybe I'm hopelessly dense, but I don't understand why you would want to 
use i= rather than From: if you already know the domain is OK.

As I mentioned to Murray, any mail with d=iecc.com has an i= based on an 
authenticated user.  Now that you know that, how will you change your mail 
handling?

Regards,

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 5 Apr 2011 13:31:40 -0700

> Sent: Tuesday, April 05, 2011 12:36 PM
> To: Tony Hansen
> Cc: IETF DKIM WG

I would associate reputation with "i=" values, because I know they're "stable" from example.com, and filter based on that.

A real-world example is gmail.com, which is generally well-behaved but occasionally gets a stand-out crap-sender.  If I know their use of "i=" is consistent, then I can assess and associate reputation based on those tags.

It's more of a fine-grained assessment than "gmail.com is generally good, so accept their stuff."  Now I can say:

- give gmail.com unknown "i=" values the benefit of the doubt
- give gmail.com "i=" values with bad reputations less room to play
- what's left is gmail.com values that seem to be good, so let them through

It's the first case, i.e. what to do with unknown "i=" values from a domain I generally trust, that might be useful.

---

From: Hector Santos <[email-masked]>
Date: Tue, 05 Apr 2011 16:47:38 -0400

> the point of using i= rather than From: ?

+1

> I'm not trying to be perverse, but this feels a lot like an 
> answer looking for a question.

> example.com is mostly OK, why should it be anyone else's job to sort out 

Isn't that a conflict?

If the other stuff is not ok, then we have invalid signatures which 
are not candidates for the proposed DKIM reputation assessment model.

Lets keep in mind the origins for its usage when POLICY was still 
focused WG interest and it applied to dealing with all signature 
violations, including a conceivable fraud attempt in masking i=.

But with reputation being the key focus now, because i= would already 
have a  verifiable relationship with the d= value, I see less value in 
passing this to the engine unless it is something that reflects the 
5322.From address and even then, the 5322.From is also hash bound 
signature requirement.

So with a reputation mindset only, I can only see i= useful for 
logging or tracing.

---

From: Dave CROCKER <[email-masked]>
Date: Tue, 05 Apr 2011 14:23:48 -0700

> the point of using i= rather than From: ?

This thread has a basic flaw:  it is predicated on a a particular interpretation 
of i=, which is undocumented and certainly not standardized.

If folks want to have a discussion about filtering based on a validated author 
identifier or address, they should start with a construct that is standardized 
to provide that.  Currently, there is no such construct.

As for any thought that i= could be made into that construct, I think the 
reasons that are not practical have been explained at length.

d/
-- 

   Dave Crocker

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 5 Apr 2011 15:10:08 -0700

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Dave CROCKER
> Sent: Tuesday, April 05, 2011 2:24 PM
> To: IETF DKIM WG

Of course, but a signature bearing a "d=" representing an ADMD with which I have an a priori arrangement to interpret "i=" in a particular way could be useful.  Such out-of-band arrangements certainly can't be standardized, but that doesn't mean there's no possible use for it at all anywhere, does it?

---

From: Dave CROCKER <[email-masked]>
Date: Tue, 05 Apr 2011 16:06:20 -0700

On 4/5/2011 3:10 PM, Murray S. Kucherawy wrote:
>> This thread has a basic flaw:  it is predicated on a a particular
>> interpretation of i=, which is undocumented and certainly not
>> standardized.
>
> Of course, but a signature bearing a "d=" representing an ADMD with which I
> have an a priori arrangement to interpret "i=" in a particular way could be
> useful.  Such out-of-band arrangements certainly can't be standardized, but
> that doesn't mean there's no possible use for it at all anywhere, does it?

I thought the discussion here was about standardized mechanisms.  At the least, 
we have some history of confusion between what is standardized and what is not.

As for what can be done outside of standardization, between consenting ADMDs, 
I'm socially liberal...

d/
-- 

   Dave Crocker

---

From: Tony Hansen <[email-masked]>
Date: Tue, 05 Apr 2011 19:05:02 -0400

> of i=, which is undocumented and certainly not standardized.

And thus we come full circle, back to the original suggestions that we 
remove i= and the counter suggestion we provide a mechanism for a 
signing domain to specify how they put information into i=.

Several notes:

1) What started this was a suggestion to remove i=, essentially because 
in its current form it's unusable.

2) I countered with a suggestion that before we decide to remove it, we 
need to understand if there were any way to make it useful, such as by 
letting the signing domain indicate how it *is* using the i= construct.

3) Making it useful doesn't require recycling bis back at proposed; it 
only requires that i= not be removed so that the other work can proceed 
behind bis to fill in the gaps.

4) I don't recall seeing this particular suggestion coming up on the 
list before, but I may have missed it amongst the flood of messages in 
the past few years.

>  reasons that are not practical have been explained at length.

5) Perhaps it *is* too late to salvage i=.

6) If it *is* too late to salvage i=, I think the discussion is still 
good and might lead to us discovering what *would* be useful.

     Tony Hansen
     [email-masked]

---

From: Hector Santos <[email-masked]>
Date: Tue, 05 Apr 2011 20:29:24 -0400

Lets also keep mind that i= predated any reputation assessment 
modeling the WG cogs took on which was first out of scope as oppose to 
the focus with the chartered policy standard proposal.  Hence DKIM 
verification output modeling was based on a security model to protect 
against any signature declaration violations. That included fraud 
protection for any optional signer usage of i=.

Take Policy out of the picture, with the focus mainly on reputation 
assessment of valid signatures, from what I see, the modeling based on 
a d= signer domain feed to independent trust assessment service is 
technically limited.   Maybe the problem is such, in the name of 
getting trust into the DKIM picture, too much emphasis was placed on 
just using one identity for a specific form on trust modeling.

I voted to remove because I personally didn't see any value in it, it 
was ambiguous to explain why/when someone should consider it, and I 
was seeing false positives where the signature was computationally 
correct but failed with the allowable value checking against d= value. 
  This promoted a new verifier option to skip this granularity check.

But if it remains even with improved semantics and we have no more 
focus on policy to help protect against violations, it seems we might 
need to feed it to reputation models.

--
HLS

---

From: Franck Martin <[email-masked]>
Date: Wed, 6 Apr 2011 13:40:29 +1200 (FJT)

+1

My understanding is that i= does not need to represent a valid email address, it just need to be in a kind of valid email address format.

So if we keep i= as is in the spec, we can conclude the standard process and give a meaning of i= outside this spec in another RFC?

----- Original Message -----
From: "Tony Hansen" <[email-masked]>
To: "IETF DKIM WG" <[email-masked]>
Sent: Wednesday, 6 April, 2011 11:05:02 AM
Subject: Re: [ietf-dkim] Proposal: Removal of AUID (i= tag/value)

Several notes:

     Tony Hansen
     [email-masked]

---

From: Dave CROCKER <[email-masked]>
Date: Tue, 05 Apr 2011 18:48:06 -0700

> So if we keep i= as is in the spec, we can conclude the standard process and give a meaning of i= outside this spec in another RFC?

How is a receiver ever going to know that this new meaning applies?

There is an installed base if i= generation and consumption.  Changing i= later 
creates an amiguity with that installed usage.

d/
-- 

   Dave Crocker

---

From: "John R. Levine" <[email-masked]>
Date: 5 Apr 2011 22:28:21 -0400

>> So if we keep i= as is in the spec, we can conclude the standard process and give a meaning of i= outside this spec in another RFC?

No, it's not backward compatible.  My signatures all have a fully 
compliant i= value which is not an e-mail address.  (Take a look.)

Fortunately, the DKIM spec is upward compatible, and we can invent new 
fields.

So, if people think that a "real ID" assertion would be of value, write up 
a draft and it can be an experimental add-on to DKIM.  I say experimental 
since we have, as far as I can tell, no actual experience with such a 
thing.

Regards,

---

From: Hector Santos <[email-masked]>
Date: Tue, 05 Apr 2011 23:03:01 -0400

Franck Martin wrote:
> +1
> 
> My understanding is that i= does not need to represent a 
> valid email address, it just need to be in a kind of valid 
> email address format.

The specification requires the domain part of i= to either match the 
d= domain or be a subdomain of the d= domain.  Examples:

     d=example.com; i=[email-masked]           valid
     d=example.com; i=[email-masked]       valid
     d=example.com; i=[email-masked]            invalid

If the public key has a g= value, then a wildcard string comparison is 
done.  Since the default value g= is *,  the g=/i= test would always 
be a true.

Now, it is possible to have the hash verification of the signature to 
be valid yet, the i=/d= and i=/g= granularity checking fail to return 
a invalid signature result which by DKIM standards is a NO SIGNATURE 
status.

> So if we keep i= as is in the spec, we can conclude the 
> standard process and give a meaning of i= outside this spec 
> in another RFC?

We are so close, yet so far. :)  Wouldn't it be better to fix whatever 
is wrong with it or remove it now?

The reason it is technically safe to remove is mostly because it is 
optional and invalid signatures are not considered by reputation. 
Since for valid signatures the only feed to reputation is the signer 
domain, there is no harm.

Legacy Signers can still add the i= tag to be hash bound to the 
signature. So even if there is a fraudulent attempt to tamper with i=, 
the hash verification would fail and the outcome would be the same - 
no valid signature.

---

From: Hector Santos <[email-masked]>
Date: Tue, 05 Apr 2011 23:15:08 -0400

> compliant i= value which is not an e-mail address.  (Take a look.)

It appears to be an email address and the mipassoc.org verifier failed 
your signature:

   Authentication-Results: sbh17.songbird.com;
	dkim=permerror (verification error: multiple DNS
	replies for `164d0.4d9bcfc5.k1104._domainkey.iecc.com')
	header.i=[email-masked]

Silent ponders.....

Should a verifier use the first TXT response for this public key 
164d0.4d9bcfc5.k1104._domainkey.iecc.com query?

A verbal signing practice failed Levine's expectation for a non-email 
address i= value.  Can that be translated to an automated POLICY based 
violation rule?

-- 
HLS

---

From: Franck Martin <[email-masked]>
Date: Wed, 6 Apr 2011 16:50:56 +1200 (FJT)

----- Original Message -----
> From: "John R. Levine" <[email-masked]>
> Cc: "Franck Martin" <[email-masked]>
> Sent: Wednesday, 6 April, 2011 2:28:21 PM
> >> So if we keep i= as is in the spec, we can conclude the standard
> >> process and give a meaning of i= outside this spec in another RFC?
> 
Yes, I said it needs to follow an email format, but it is not an email address (do not email there!)
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Franck Martin <[email-masked]>
Date: Wed, 6 Apr 2011 16:59:40 +1200 (FJT)

I there a meaning given in the spec?

It just says (from memory) that it must follow a specific format for the signature to pass. There may have been an intent here (authenticated user) but I don't think the spec gives i= a strong meaning.

I could use i=[email-masked] d=mipassoc.org with a from: [email-masked], and have dkim verification pass, no?

PS: I'm arguing not for the sake of arguing, but being lazy, I prefer to do with what there is than what has to be built.
PPS: "Everyone knows bananas have the best reputation" - pointy hair boss.

----- Original Message -----
From: "Dave CROCKER" <[email-masked]>
To: "Franck Martin" <[email-masked]>
Cc: "IETF DKIM WG" <[email-masked]>
Sent: Wednesday, 6 April, 2011 1:48:06 PM
Subject: Re: [ietf-dkim] Proposal: Removal of AUID (i= tag/value)

d/
-- 

   Dave Crocker

---

From: Jeff Macdonald <[email-masked]>
Date: Sat, 16 Apr 2011 12:37:03 -0400

Although I have been a big fan of i=, I now support the removal of it.

(I've been on vacation the last 3 weeks, so I apologize for this late comment).

On Thu, Mar 31, 2011 at 5:33 PM, Jim Fenton <[email-masked]> wrote:
> In order to remove i= from the specification, we need to:
>
> - Remove section 2.6 (definition)
> - Remove i= tag definition from 3.5
> - Remove i= from example at the end of 3.5
> - Remove "s" flag from t= tag definition in 3.6
> - Remove section 3.9 (Signing by Parent Domains)
> - Remove section 3.10 (relationship between SDID and AUID) or change it
> to reflect SDID-only information
> - Remove reference to i= tag in 6.1.1 paragraph 5
> - Remove section 8.13 (Inappropriate Signing by Parent Domains)
> - Remove i= from examples in A.2 and A.3
> - Change IANA registries to retain i= tag in signature and "s" flag in
> key record as deprecated
>
> That's what I could find, but I may have missed something.
>

-- 
Jeff Macdonald
Ayer, MA