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

From: "Rolf E. Sonneveld" <[email-masked]>
Date: Fri, 01 Apr 2011 22:14:45 +0200

On 4/1/11 1:31 AM, Franck Martin wrote:
> I had the feeling that Y! was using the local part of i= to do differentiation in reputation. ie various streams within the same domain.
>
> I know the spec intent recommends, different domains for different streams, but then....
>
> Intuition would tell me, that few people are willing (or understand) to have different domains for different streams.

+1. And as DKIM d= information already is shown to end users by some UA 
implementations (e.g. Gmail shows 'this message was signed by <domain>, 
when clicking on details) the need/advise to use different domains for 
different streams conflicts with the threat of phishers registering 
look-alike domains.

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

---

From: Franck Martin <[email-masked]>
Date: Sat, 2 Apr 2011 09:04:44 +1200 (FJT)

I would suggest we deprecate i= and add st= (if not already used) that would let the sender specify a stream category. It would be limited to say 20 (or so) chars and we could specify a set of standard words (but not limited to). I'm thinking of things like transactional, marketing, password-reminder, sub-confirmation, billing, corporate, personal,...

It would be left to the receiver to use them or not of course.

I understand some of these words could be abused, but then the receiver could build a confidence factor in domain/stream association, etc...

With IPv6 we may loose IP reputation, this is a way to bring it back within DKIM.

PS: http://postmaster.facebook.com/outbound gives a good idea of streams in IPv4 world with DKIM equivalent, but they may be about the only ones to do that with DKIM.

----- Original Message -----
From: "Rolf E. Sonneveld" <[email-masked]>
To: "Franck Martin" <[email-masked]>
Cc: "Jim Fenton" <[email-masked]>, "IETF DKIM WG" <[email-masked]>
Sent: Saturday, 2 April, 2011 8:14:45 AM
Subject: Re: [ietf-dkim] Proposal:  Removal of AUID (i= tag/value)

/rolf

---

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

I'm told that adding something like this to 4871bis would require that 
it go around again at Proposed Standard, rather than progress to Draft 
Standard.

It might be possible as a separate extension to DKIM, however.  I have 
an expired draft along these lines, 
draft-fenton-dkim-reputation-hint-00.  But it didn't include the 
specific stream names.

-Jim

On 4/1/11 2:04 PM, Franck Martin wrote:
> From: "Rolf E. Sonneveld"<[email-masked]>
> To: "Franck Martin"<[email-masked]>
> Cc: "Jim Fenton"<[email-masked]>, "IETF DKIM WG"<[email-masked]>
> implementations (e.g. Gmail shows 'this message was signed by<domain>,

---

From: Franck Martin <[email-masked]>
Date: Sat, 2 Apr 2011 11:53:58 +1200 (FJT)

Yes, could be good to do it as a separate extension, I thought also about specifying an X-Header that would be signed by DKIM. 

Another way is to have a dkim tag that specify the header that indicates the stream classification

Many ways to kill the same bird.

As for the stream name, I think giving a few codified ones, would help the receiver in making decision, but if sender wants to use his own, then be free to do so.

Should we resurrect your draft, or go another way? Which way you want to go? (How does it work in IETF?)

----- Original Message -----
From: "Jim Fenton" <[email-masked]>
To: "Franck Martin" <[email-masked]>
Cc: "Rolf E. Sonneveld" <[email-masked]>, "IETF DKIM WG" <[email-masked]>
Sent: Saturday, 2 April, 2011 9:33:10 AM
Subject: Re: [ietf-dkim] Proposal:  Removal of AUID (i= tag/value)

-Jim

---

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

Taking out "i=" doesn't create a back-compatibility problem because new signers won't add "i=" so old verifiers don't use it, and new verifiers ignore "i=" so old signers will still work.  So that won't derail a Draft Standard effort.

Adding something new, however, will.  The best bet would be to add the "st=" or equivalent in a new draft, updating the IANA registries accordingly.  Then RFC4871bis can still get Draft Standard, and the new tag becomes official on its own.
________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Jim Fenton [[email-masked]]
Sent: Friday, April 01, 2011 2:33 PM
To: Franck Martin
Cc: IETF DKIM WG
Subject: Re: [ietf-dkim] Proposal:  Removal of AUID (i= tag/value)

-Jim

---

From: Dave CROCKER <[email-masked]>
Date: Sun, 03 Apr 2011 13:47:55 +0100

On 4/1/2011 10:04 PM, Franck Martin wrote:
> I would suggest we deprecate i= and add st= (if not already used) that would
> let the sender specify a stream category.
...
> With IPv6 we may loose IP reputation, this is a way to bring it back within

Why doesn't the d= value satisfy this function just as well?

Remember that d= can have sub-domains, to distinguish different streams.

d/--

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

---

From: Franck Martin <[email-masked]>
Date: Mon, 4 Apr 2011 09:02:49 +1200 (FJT)

----- Original Message -----
> From: "Dave CROCKER" <[email-masked]>
> Cc: "IETF DKIM WG" <[email-masked]>
> Sent: Monday, 4 April, 2011 12:47:55 AM
> > With IPv6 we may loose IP reputation, this is a way to bring it back
> > within
> > DKIM.
> 
> 
I'll answer: Paypal and ADSP

Yes it can be done, are people doing it: no

people are using their domain name for their corporate email and application, they are not ready to do corp.mydomain.com

http://postmaster.facebook.com/outbound

Facebook is mixing up their corporate email with their users email...
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Dave CROCKER <[email-masked]>
Date: Sun, 03 Apr 2011 22:12:06 +0100

OK.  So the capability exists, but people choose not to use it.  Some people in 
fact choose to disable this capability; note that a) ADSP is an add-on, not the 
DKIM core, and b) the actual uptake of ADSP on the receive side is not known to 
be large.

So the suggestion is to add a second capability that performs the same function 
as the first, on the theory that, this time, folks will use it for that purpose?

The logic sequence has some problems, but I don't believe it's reflection of the 
current situation is one of them.

d/

-- 

   Dave Crocker

---

From: Franck Martin <[email-masked]>
Date: Mon, 4 Apr 2011 09:25:59 +1200 (FJT)

As you say my intuition is that people do not want to sub-domain, because it has a large pain factor.

However what is easy, is to modify the content of the email. We could add a new tag in the dkim spec like st=, but I'm not sure this is feasible with the various current DKIM software today.

So the best option is to define a new email header and have it signed by DKIM.

>From a sender point of view this is easier to do (vs creating a sub domain, remapping mail servers,...)

>From a receiver point of view, are people willing to adapt their reputation engine, to take into account this new header? I have no idea.

Note on ADSP: yes ADSP is an add-on, but I think people moved away from it, when they found out that DKIM would not survive some forwarding for their corporate email... Therefore too many valid emails were discarded. Using ADSP with a specific domain is possible, but then people were not ready in separating mail streams by domain.

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

d/

-- 

   Dave Crocker

---

From: Dave CROCKER <[email-masked]>
Date: Sun, 03 Apr 2011 22:31:11 +0100

> As you say my intuition is that people do not want to sub-domain, because it

I did not offer that intuition nor an interpretation of it.

As for pain, most tasks incur a reasonably stable level of pain.  One can take 
different approaches in design that moves it around, but usually doesn't 
eliminate it.

The exercise, right now, has characteristics uncomfortably similar to chasing 
one's tail.

d/
-- 

   Dave Crocker

---

From: Jim Fenton <[email-masked]>
Date: Sun, 03 Apr 2011 20:40:37 -0700

My draft is expired, and I'm not particularly passionate about this so 
it's probably best if you do your own draft.  I can send you the XML for 
my draft as a starting point if you want; feel free to use any of it 
that you want.

-Jim

On 4/1/11 4:53 PM, Franck Martin wrote:
> From: "Jim Fenton"<[email-masked]>
> Cc: "Rolf E. Sonneveld"<[email-masked]>, "IETF DKIM WG"<[email-masked]>

---

From: "John Levine" <[email-masked]>
Date: 4 Apr 2011 04:09:16 -0000

>Many ways to kill the same bird.

If there is a reason why people aren't able to use a d= domain per
stream, I wish someone would explain in simple terms that even a
dimwit like me can understand.

The only arguments I'm aware of is that hostile or incompetent DNS
managers refuse to install key records, which isn't a very good reason
to add cruft to a standard and "I want to do it some other way" which
is even worse.

R's,
John

---

From: Franck Martin <[email-masked]>
Date: Mon, 4 Apr 2011 22:21:01 +1200 (FJT)

----- Original Message -----
> From: "John Levine" <[email-masked]>
> To: [email-masked]
> Cc: [email-masked]
> Sent: Monday, 4 April, 2011 4:09:16 PM
you can lead a horse to water....

I'm curious of the reasons too, I see some data points, but cannot conclude any statistics...

May be from the people who do statistics on DKIM, do you see a fair percentage of DKIM signed sub-domains?
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Hector Santos <[email-masked]>
Date: Mon, 04 Apr 2011 09:58:43 -0400

Dave CROCKER wrote:
>> I would suggest we deprecate i= and add st= (if not already used) 
>> that would let the sender specify a stream category.
> ....

Key difference here.  IP Reputation is a bad ip filtering model.  DKIM 
was designed for a Panning for Gold mail model.

-- 
HLS

---

From: "McDowell, Brett" <[email-masked]>
Date: Mon, 4 Apr 2011 08:04:15 -0600

> DKIM core, and b) the actual uptake of ADSP on the receive side is not known to 

One new-ish data point:  I believe Hotmail is leveraging the ADSP records from domains they trust to be operating with consistency.

---

From: "John R. Levine" <[email-masked]>
Date: 4 Apr 2011 10:47:02 -0400

> Characterizing our 'customers' for this standard as "hostile or 
> aincompetent" doesn't seem like posturing ourselves for success.  There 
> are deployment considerations that impact adoption of many (all?) technical 
> standards.  We ignore them at our peril.

Hmmn.  Where I come from, the people who run the DNS are the support 
staff, not the customers, but whatever.

In any event, if an organization can't deal with installing a handful of 
innocuous TXT records in its DNS, their heads are going to explode when 
they have to deal with IPv6 and DNSSEC.  Dave Crocker should probably 
chime in here, but kludges to work around short term deployment problems 
are rarely a good way to do long term standards development.  The problems 
go away, but the kludges don't.

I think it would be a fine idea to come up with tools to help maintain the 
necessary DNS records.  In the small scale at least, I can report that 
it's very simple and my monthly DKIM key rotation is completely automated. 
Large organizations have larger issues, but the right thing to do is to 
help to deal with the problem.

Regards,
John Levine, [email-masked], Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. http://jl.ly
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: "McDowell, Brett" <[email-masked]>
Date: Mon, 4 Apr 2011 08:17:21 -0600

On Apr 4, 2011, at 12:09 AM, John Levine wrote:

> to add cruft to a standard
> and "I want to do it some other way" which
> is even worse.

Characterizing our 'customers' for this standard as "hostile or incompetent" doesn't seem like posturing ourselves for success.  There are deployment considerations that impact adoption of many (all?) technical standards.  We ignore them at our peril.

---

From: "McDowell, Brett" <[email-masked]>
Date: Mon, 4 Apr 2011 09:45:24 -0600

I believe the context for your earlier comments that I responded to was the discussion about deprecating i= and/or adding a new st= tag.  I hope my comments were not interpreted as supporting either of those changes.  That was not my intention.

On Apr 4, 2011, at 10:47 AM, John R. Levine wrote:

> necessary DNS records.  

Agreed.  But probably out-of-scope for this WG, yes?  MAAWG, OTA, BITS, APWG, etc. seem like better fora for this kind of deployment support.

> In the small scale at least, I can report that 
> Large organizations have larger issues,

Indeed, and those differences are not to be underestimated.  I've been surprised to hear from other deployers just how hard this for them to operationalize at scale.  These are folks who generally don't participate in IETF so we don't see a lot of first-hand reports on this mail list (at least I haven't).

> but the right thing to do is to 

... and the root cause of the problem, which just might be a missed opportunity to optimize something in the spec itself.  

I was only chiming in for the sake of keeping our tone open to specification changes based on real world deployment challenges (at least for the remaining duration of this WG).  But here's where I agree with John:  we haven't seen any deployment challenges documented in an actionable way that would suggest specification changes.  There's a lot of anecdotal evidence (like what I share above ;-) but not much actionable detail.

-- Brett

---

From: "John Levine" <[email-masked]>
Date: 4 Apr 2011 15:58:41 -0000

>One new-ish data point:  I believe Hotmail is leveraging the ADSP records from
>domains they trust to be operating with consistency.  

As has often been pointed out, if it's domains you already know
something about, you don't need ADSP.

ADSP is only the most obvious of assertions that people make about the
mail they send.  If you don't know the sender, you can't believe the
assertions, so they're useless.  If you do know the sender, you don't
need the assertions, so they're not useful.

This is why x= is either useless ot not useful.

R's,
John

---

From: Wietse Venema <[email-masked]>
Date: Mon, 4 Apr 2011 11:30:59 -0400 (EDT)

> to add cruft to a standard and "I want to do it some other way" which

To give a productive spin to the discussion:

One little-known DKIM fact is that one does not need a different
DNS record per d= domain. One strategically-chosen wild-card under
_domainkey.example.com suffices (e.g. one per sub-organization).

I agree that a different DNS record per d= domain can be a barrier
for non-trivial organizations that have non-trivial latencies due
to bureaucracy or even outsourcing, while bad guys in their small
shops can crank out DNS records with negligible effort.

	Wietse

---

From: Alessandro Vesely <[email-masked]>
Date: Mon, 04 Apr 2011 18:46:45 +0200

> dimwit like me can understand.

Attaching multiple meanings to the same datum produces non-orthogonal
structures that may result in idiosyncrasies.  (If Joe Marketeer's
address is [email-masked] rather than [email-masked], he
may want to sign with d=example.com irrespectively of the message stream.)

As vague as the concept of /message stream/ is, I don't think it is
necessary to invent a new header field for it, since the List-Id
exists already, and "SHOULD be included in the signature" according to
the current spec.

Likewise, there is an auth tag in A-R for the authenticated id.  (The
only use of such token for unknown domains seems to be in connection
with _submission._tcp SRV RRs to devise dictionary attacks.)

+1 for softly deprecating the AUID.
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 4 Apr 2011 11:23:06 -0700

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Franck Martin
> Sent: Sunday, April 03, 2011 2:26 PM
> To: [email-masked]
> Cc: IETF DKIM WG
> However what is easy, is to modify the content of the email. We could
> add a new tag in the dkim spec like st=, but I'm not sure this is
> feasible with the various current DKIM software today.

We can't add anything to DKIM without delaying significantly the goal of advancing it to Draft Standard.  On the other hand, you can register a new tag in your own RFC without interfering with that progress.

> domain, remapping mail servers,...)

You can do that if you think it'll work.  The header field registry also is extensible.

> From a receiver point of view, are people willing to adapt their
> reputation engine, to take into account this new header? I have no
> idea.

I think you need some data to show this works and will get uptake.  But if you have that, then getting something like that standardized is easy.  Just don't underestimate the size of that "if".

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 4 Apr 2011 11:27:22 -0700

> Sent: Monday, April 04, 2011 3:21 AM
> To: John Levine
> Cc: [email-masked]

I'm happy to search our data if you can describe what I'm looking for.  If you're referring to a comparison between "d=" and "i=" values, we do that already:

http://www.opendkim.org/stats/report.html#i_tag

(The anchor tag in the current report has a typo, so if you go before the next update, you'll need to search for "i=" yourself.)

If you mean something else, describe for me what you're looking for and I'll give it a go.

---

From: Douglas Otis <[email-masked]>
Date: Mon, 04 Apr 2011 11:39:27 -0700

On 4/4/11 7:47 AM, John R. Levine wrote:
>  ... kludges to work around short term deployment problems are rarely
>  a good way to do long term standards development. The problems go
>  away, but the kludges don't.

Why are A and AAAA records used to locate mail servers and not limit 
discovery to just MX records?  The reasoning was to allow simple 
installation of email without a need for "special" DNS resources.  This 
improvised "ease of deployment" method now requires searching for A, 
AAAA and MX records, which then means any host can be considered a 
target or a purported source of abusive email.  How long will this 
improvised discovery method remain?

Adding to the improvised discovery problem, there are now two punycode 
conversions, the 2003 and 2008 version, along with Asian and local 
domains using UTF-8 directly.   How long will the improvised punycode 
method remain?   After all, resolving a domain expects both punycode AND 
UTF-8 to be attempted where aliases might also be discovered.  It seems 
RFC5321 continued use of improvised punycode and failed to clarify what 
form an alias might take.

 From the outset I opposed the g= component of the key, and the i= 
portion of the signature.  Nevertheless there remains a need for a 
convention able to opaquely identify internal sources for reporting and 
abuse tracking purposes.  Adding headers separate from the signature 
obfuscates a relationship.  Rather than changing code able to handle i= 
parameters, it would be reasonable to remove any wording that suggests 
this parameter offers identification, and leave this definition to be 
defined through extensive use.  There is little experience with domain 
based reputation, where it is also clear that normally open IPv6 address 
reputations would be ineffectual at responding to abuse.

Although there are potentially more domain names than their are IPv6 
addresses, domain names offer a means to consolidate authority through 
domain hierarchy.  It would also be a poorly considered improvised 
method to use sub-domains to sign for a domain since this would muddle 
authority hierarchy.  A sub-domain should not claim authority over a 
parent domain.

Keep the i= parameter and define it as being opaque.

-Doug

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 4 Apr 2011 11:48:45 -0700

> From: [email-masked] [mailto:[email-masked]] On Behalf Of John R. Levine
> Sent: Monday, April 04, 2011 7:47 AM
> To: McDowell, Brett

We've been doing that in OpenDKIM for a while now, even for experimental stuff like ATPS.  People seem to really like them.

Someone could propose some tools or procedures to manage this stuff and use them to update the Deployment document or publish something orthogonal, if keen to do something like that in the IETF context.

---

From: Franck Martin <[email-masked]>
Date: Tue, 5 Apr 2011 08:04:24 +1200 (FJT)

----- Original Message -----
> From: "Murray S. Kucherawy" <[email-masked]>
> To: "IETF DKIM WG" <[email-masked]>
> Sent: Tuesday, 5 April, 2011 6:23:06 AM
> > From: [email-masked]
> > [mailto:[email-masked]] On Behalf Of Franck Martin
> We can't add anything to DKIM without delaying significantly the goal
> of advancing it to Draft Standard. On the other hand, you can register
> a new tag in your own RFC without interfering with that progress.

Yes I know, this is not what I was asking. For instance, in openDKIM, can I add an st= tag (or any other tag) easily or will that oblige you to modify the code and therefore make a new release of openDKIM?

> 
> > So the best option is to define a new email header and have it
> > signed
> > by DKIM.
> >
> I think you need some data to show this works and will get uptake. But
> if you have that, then getting something like that standardized is
> easy. Just don't underestimate the size of that "if".
> 

Yes, anyone can submit something to the IETF queue, but will it take, that's another story.
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: "MH Michael Hammer (5304)" <[email-masked]>
Date: Mon, 4 Apr 2011 15:34:00 -0400

> From: [email-masked] [mailto:ietf-dkim-
> [email-masked]] On Behalf Of Franck Martin
> Sent: Monday, April 04, 2011 6:21 AM
> To: John Levine

We DKIM sign separately for subdomains. That is, the d= is the
subdomain. We do this because they are different mailstreams. WE don't
do anything special or significant with i=.

---

From: Franck Martin <[email-masked]>
Date: Tue, 5 Apr 2011 08:12:39 +1200 (FJT)

----- Original Message -----
> Sent: Tuesday, 5 April, 2011 6:27:22 AM
> I'm happy to search our data if you can describe what I'm looking for.
> If you're referring to a comparison between "d=" and "i=" values, we
> do that already:
> 
> (The anchor tag in the current report has a typo, so if you go before
> the next update, you'll need to search for "i=" yourself.)
> 
the question is:
What are the domains that use a sub-domain for d= ?

for gTLDs, what are the instances of d= where there are 3 levels in the domain where the 2nd and 1st level is identical.

eg:
d=mail1.example.com
d=mail2.example.com
d=mail3.example.com

We could infer that example.com use different mail streams as they use different sub-domains to sign their emails

for ccTLDs, in general you need to go one level deeper

eg:
d=mail1.example.com.au
d=mail2.example.com.au
d=mail3.example.com.au

---

From: Franck Martin <[email-masked]>
Date: Tue, 5 Apr 2011 08:21:33 +1200 (FJT)

I think you are thinking it as only a DNS issue.

But creating a sub-domain, means that the from needs to match too, therefore you may need to remap all your corporate email addresses from [email-masked] to [email-masked] to separate from the emails sent by your application at iecc.com (if you want to keep the first party signing)

I'm not sure that many email admins like to play with MS-Exchange and their boss email address...

Or did I misunderstood the spec?

----- Original Message -----
From: "John Levine" <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Sent: Monday, 4 April, 2011 4:09:16 PM
Subject: Re: [ietf-dkim] Proposal:  Removal of AUID (i= tag/value)

R's,
John

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 4 Apr 2011 13:24:29 -0700

> From: Franck Martin [mailto:[email-masked]]
> Sent: Monday, April 04, 2011 1:04 PM
> To: Murray S. Kucherawy
> Cc: IETF DKIM WG
> Yes I know, this is not what I was asking. For instance, in openDKIM,
> can I add an st= tag (or any other tag) easily or will that oblige you
> to modify the code and therefore make a new release of openDKIM?

As you might expect, a version of OpenDKIM that doesn't know anything about a new tag will ignore it (like the RFC says).  A later version that adopts the new tag will parse and apply it.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 4 Apr 2011 13:30:35 -0700

> Sent: Monday, April 04, 2011 1:13 PM
> To: Murray S. Kucherawy
> for gTLDs, what are the instances of d= where there are 3 levels in the
> domain where the 2nd and 1st level is identical.
> 
> eg:
> d=mail1.example.com
> d=mail2.example.com
> d=mail3.example.com
> 
> We could infer that example.com use different mail streams as they use
> different sub-domains to sign their emails
> 

So for the 3.5M signatures we've seen, compare each of them to all of the other ones to see if one is X.<domain> while the other is just <domain>?

I'll see what I can come up with.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 4 Apr 2011 13:31:21 -0700

> Sent: Monday, April 04, 2011 1:22 PM
> To: John Levine
> But creating a sub-domain, means that the from needs to match too,

Why?  That's an ADSP thing, not a DKIM thing.

---

From: Franck Martin <[email-masked]>
Date: Tue, 5 Apr 2011 08:38:47 +1200 (FJT)

----- Original Message -----
> Sent: Tuesday, 5 April, 2011 8:30:35 AM
> Subject: RE: [ietf-dkim] Proposal: Removal of AUID (i= tag/value)
> So for the 3.5M signatures we've seen, compare each of them to all of
> the other ones to see if one is X.<domain> while the other is just
> <domain>?

or Y.<domain>

---

From: "MH Michael Hammer (5304)" <[email-masked]>
Date: Mon, 4 Apr 2011 16:45:40 -0400

> [email-masked]] On Behalf Of Murray S. Kucherawy
> Sent: Monday, April 04, 2011 4:31 PM
> To: Franck Martin

I think his goal is to have it be a 1st party signature (From and d=
match) even absent an ADSP assertion. I'm not sure I agree that this is
just "an ADSP thing, not a DKIM thing". We don't publish ADSP yet I have
had receivers tell me that our doing this is useful to them.

Mike

---

From: Tony Hansen <[email-masked]>
Date: Mon, 04 Apr 2011 16:57:55 -0400

Franck may have been asking a different question:
     as an openDKIM user, is there a way to add an additional value to 
be added to the signature?

Tony

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 4 Apr 2011 14:06:03 -0700

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Tony Hansen
> Sent: Monday, April 04, 2011 1:58 PM
> To: IETF DKIM WG

No, it's not extensible in that way right now.  But it could be.  Anyone can free to open a feature request on SourceForge if you think it would be useful.

---

From: Steve Atkins <[email-masked]>
Date: Mon, 4 Apr 2011 13:59:51 -0700

> But creating a sub-domain, means that the from needs to match too, therefore you may need to remap all your corporate email addresses from [email-masked] to [email-masked] to separate from the emai…

There's a tautology there.

You're saying "I'd have to do <first part signing> (if I want to do first party signing)."

There's no DKIM requirement to do that, and signing an email From: [email-masked] with d=corp.iecc.com (or d=foo.blighty.com) is just fine.

If someone chooses to do solely "first party signing" (for some non-DKIM related reason) they're sacrificing many of the advantages of using DKIM to authenticate email, and the ability to differentiate streams of email is one of those advantages.

Cheers,
  Steve

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 4 Apr 2011 14:33:23 -0700

> From: MH Michael Hammer (5304) [mailto:[email-masked]]
> Sent: Monday, April 04, 2011 1:46 PM
> To: Murray S. Kucherawy; Franck Martin

In that case, it's neither.  DKIM doesn't make a binding between "d=" and anything else in the message (except "i=", sort-of).  Anyone that tries to make a distinction between first party and not first party is doing something outside the scope of DKIM.

A message stream, in the context of DKIM, should be evaluated based on the "d=" value, and nothing else.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 4 Apr 2011 14:35:48 -0700

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Murray S. Kucherawy
> Sent: Monday, April 04, 2011 2:33 PM
> To: MH Michael Hammer (5304)

...or "i=", if that's your preference.

---

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

> _domainkey.example.com suffices (e.g. one per sub-organization).

Not really.  The part to the left of _domainkey is the selector, so you 
can wildcard selectors (which I do, see this message), but not domains.

What you want is a DNS record for sel._domainkey.*.example.com, but don't 
suggest that unless you want to open a famous can of worms that have big 
bloody fangs.

Regards,

---

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

> Why?  That's an ADSP thing, not a DKIM thing.

Right.  For people who still want to use ADSP, you're welcome to use two 
signatures.

Regards,

---

From: Douglas Otis <[email-masked]>
Date: Mon, 04 Apr 2011 14:57:53 -0700

On 4/4/11 1:59 PM, Steve Atkins wrote:
> On Apr 4, 2011, at 1:21 PM, Franck Martin wrote
> You're saying "I'd have to do<first part signing>  (if I want to do first party signing)."
>
Don't assume public keys referenced from subdomains are authoritative 
and equal to public keys referenced from the domain in question.

The domain name scape is becoming fairly complex with introduction of 
new TLD, SLD, and aliased domains written in different languages using 
different encoding.  There is a difference from [email-masked] signed by 
<vital.edu>, and the same message signed by <alumni.vital.edu>.  The 
later case might call into question the validity of the From, especially 
from an authority standpoint.   When dealing with a new name space 
defined in truly foreign languages,  it may be hard to judge whether a 
second level domain represent a new "dot", "co", or essentially a domain 
that might be controlled by completely different entities.
> If someone chooses to do solely "first party signing" (for some non-DKIM related reason) they're sacrificing many of the advantages of using DKIM to authenticate email, and the ability to different…
There is no requirement that the i= matches with the From local-part, 
where the i= parameter could be used to differentiate message streams as 
well.  The benefit found using i= over the signing by subdomains is it 
does not _assume_ two domains are controlled by the same entity.

-Doug

---

From: Michael Adkins <[email-masked]>
Date: Mon, 4 Apr 2011 21:29:20 +0000

>Facebook is mixing up their corporate email with their users email...

That's not true and nothing on that page suggests that we do.

---

From: Hector Santos <[email-masked]>
Date: Mon, 04 Apr 2011 19:03:45 -0400

Murray S. Kucherawy wrote:
> In that case, it's neither.  DKIM doesn't make a binding between 
> "d=" and anything else in the message (except "i=", sort-of). 

Sort of?

The difference is INVALID_SIGNATURE and thus NO_SIGNATURE results.

> Anyone that tries to make a distinction between first party and 
> not first party is doing something outside the scope of DKIM.

Until ADSP is not longer a chartered item or chair is arm twisted to 
officially shutdown the IETF WG Policy standardization efforts, it is 
still in scope to make that distinction.  Lets not forget about threat 
analysis RFC that warns us about anonymous and unauthorized mail 
signing streams and how policy is one solution to this security 
problem.  Even without Policy in the form of ADSP, when it is in the 
form of Trust is also POLICY concept. When you begin adding 
"independent trust assessment service" into DKIM scope and spec, this 
inherently introduces first vs third party distinctions.

> A message stream, in the context of DKIM, should be evaluated 
> based on the "d=" value, and nothing else.

We know this is the intent - trust the signer, trust the signer, trust 
the signer, and if you trust the the signer, nothing else matters,. 
But the unfortunately facts no matter how many times this mantra is 
rammed in, it still remains to be a very difficult concept to sell or 
prove that it the the only workable thing in town for evaluation.  The 
basic problem is a high potential for lack of consistent high quality 
outputs.  It is hard for any process in the world can get high quality 
output without having impurities filtering component.

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

---

From: Michael Adkins <[email-masked]>
Date: Mon, 4 Apr 2011 21:50:06 +0000

---

From: Franck Martin <[email-masked]>
Date: Tue, 5 Apr 2011 16:00:06 +1200 (FJT)

Ooops, sorry... I was dreaming you were using facebook.com for corp emails, but I see you use fb.com

My mistake.

---

From: "Rolf E. Sonneveld" <[email-masked]>
Date: Tue, 05 Apr 2011 12:33:10 +0200

> There's no DKIM requirement to do that, and signing an email From: [email-masked] with d=corp.iecc.com (or d=foo.blighty.com) is just fine.

Correct.

> If someone chooses to do solely "first party signing" (for some non-DKIM related reason) they're sacrificing many of the advantages of using DKIM to authenticate email, and the ability to different…

Please let's make a clear distinction between DKIM as the protocol and 
DKIM as it can be used to provide this or that functionality. Of course 
it's not always easy to draw a line between the two, but let's try it, 
in order to get the discussion right:

   1. RFC4871bis defines the core DKIM spec. That's what the protocol
      is, providing various options, tags, possible tag values,
      canonicalizations, hash options, selector options, signing
      options, selector choices, etc.
   2. Second, we can build upon that DKIM foundation to provide use
      profiles. These use profiles need to be described within their own
      RFC's which can have status informational, experimental etc. Each
      of the RFCs will reference 4871bis and from that starting point,
      define a set of restrictions to model the proposed functionality.

Ad 2. To give some examples of use profiles:

    * of course, the first thing that comes to mind is to use DKIM as
      mechanism to build reputation services on. For this use profile
      not many restrictions will be required, but restrictions like MUST
      NOT or SHOULD NOT use l= can be part of that spec. Such a spec
      could also give some guidance re. the use of i=
    * define such a thing as 'first party signing'; that use profile RFC
      will restrict the d= to be the same as the domainpart of the From
      address.
    * idem, for 'third party signing', describing do's and dont's for
      this particular use profile
    * use an ADSP-like policy combined with DKIM, for example to advise
      recipients to discard all mail from the d= domain. I know of one
      big bank here in NL using an spf record "v=spf1 -all" to notify
      the recipients they never send mail with that domain. An
      equivalent of this could be designed as DKIM use profile, using a
      policy like ADSP or some other yet-to-be-defined policy.
    * define a use profile which defines a restriction in the key
      retrieval protocol, with a 'verifier MUST use DNSSEC' to retrieve
      the public key; if no DNSSEC communication path is available,
      treat the message as unsigned, or treat it with a confidentiality
      level 'none'.
    * a use profile that describe the use of domains and subdomains to
      differentiate between streams
    * a use profile that describe the use of a new st= tag to
      differentiate between streams
    * etc. etc.

It seems to me that we're constantly mixing the possible uses of DKIM 
with the core specification of DKIM. By differentiating the two, 4871bis 
can be finished and DKIM can start to bear fruit.

/rolf

---

From: "Charles Lindsey" <[email-masked]>
Date: Wed, 06 Apr 2011 12:10:32 +0100

>       could also give some guidance re. the use of i=

and lost more examples snipped

> can be finished and DKIM can start to bear fruit.

Which suggests that future use profiles may need tag hooks to hang their  
features on, and so if there is some underused existing tag (such as i=)  
already in the spec, then it is better left there to facilitate such  
future profiles.

-- 
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: "Charles Lindsey" <[email-masked]>
Date: Wed, 06 Apr 2011 12:14:03 +0100

On Mon, 04 Apr 2011 21:24:29 +0100, Murray S. Kucherawy  
<[email-masked]> wrote:

Not quite. For example if an st= tag is in the header and the signature  
verifies, then you know that tag was put there (or at least was present)  
when the signature was made, and was not inserted by some  
scammer-in-the-middle.

That is an essential feature upon which future versions/whatever can then  
rely.

---

From: Hector Santos <[email-masked]>
Date: Wed, 06 Apr 2011 11:19:17 -0400

> already in the spec, then it is better left there to facilitate such  

Good point.

The thing is, for a standard protocol, there should at least be the 
basis for hooks defined, generalized or outlined for the tags already 
provided.

That was done for the "Independent Trust Assessment Service" d= hook.

     trust = HOOK(signer-domain)

The problem as I see it as that we have mixed specific implementation 
service needs and limited the generalization of the protocol.  As I 
recall, when this was all debated regarding what "bits" should be 
passed, the understanding was that d= would be the MINIMAL REQUIRED 
parameter for any augmented DKIM "HOOK" technology for signature 
evaluation.  At least, that is how I understood it from an SOFTWARE 
API implementation standpoint.

What does that mean?

What it means is how well the DKIM Interface Points are defined will 
help how well the integration can be done.

Currently, that "interface point" is the Authentication-Results 
header, which AFAIK, isn't a standard at this point.  Nonetheless, A-R 
also comes with TRUST issues and I believe it is understood the only 
consumers who can trust these A-R headers would be the local or 
internal system only. One part verifies and produces A-R and another 
part interprets it for whatever usage, scoring, filtering and/or display.

-- 
HLS

---

From: Steve Atkins <[email-masked]>
Date: Wed, 6 Apr 2011 08:48:34 -0700

> already in the spec, then it is better left there to facilitate such  

That sounds like a fragile way to extend things - leave a little used feature
around and hope someone who wants something new hijacks that
field in a non-conflicting way instead. (Which may not be what you're
suggesting, but it's an implication I've seen in some comments about i=).

Outside of the information that is needed to validate the DKIM signature
(v, a, b, bh, c, d, h, l, q, s, t, x) there doesn't seem to be any real need for
information to be recorded in the DKIM-Signature field at all. Rather, it can
use the 5322 extensibility to add a header containing the information
that needs to be included (with an understanding that the receiver should
require that header be covered by the DKIM signature).

Cheers,
  Steve

---

From: Michael Thomas <[email-masked]>
Date: Wed, 06 Apr 2011 09:07:36 -0700

> require that header be covered by the DKIM signature).

There is something to be said about using tags in the signature
rather than signed headers. Signers don't have to have any
reason -- and none should be inferred -- for signing any given
header. There are no semantics associated with that. Putting
something in the signature on the other hand carries
the exact semantics of what the value means _in the context of
the DKIM signature_.

So unless we want to start making new headers have a presence
of a DKIM semantics requirement -- which would probably be
hopeless -- it's probably better to keep extensibility within
the narrow confines of the DKIM header itself.

Mike

---

From: Steve Atkins <[email-masked]>
Date: Wed, 6 Apr 2011 09:29:49 -0700

> the narrow confines of the DKIM header itself.

Not all new headers. (And the DKIM header doesn't really have
any proper extensibility, and the use of single or two letter names
for fields makes ad-hoc addition of new fields to that header - without
a registry or version bump - quite a bit riskier than the "Full-English-Word:"
approach 5322 headers use.)

Rather, if anyone wants to release a specification that "requires"
some sort of data be associated with a dkim signature then they
can equally well release a spec that defines a new 5322 header
that holds the same data.

As a concrete example, if I wanted to include the authenticated
age of each email sender (something the gambling industry might
be interested in) then I can do that within the DKIM signature:

DKIM-Signature: v=1; d=corp.example.com; <blah>; db=19700224

Or I can specify that that should be done with a dedicated 5322
header that both references and is signed by a DKIM signature.

DKIM-Signature: v=1; d=corp.example.com; <blah>; h=To:Authenticated-Birthdate:<blah>
Authenticated-Birthdate: version=0.1; dkim=corp.example.com; birthdate=1970-02-24

As long as the Authenticated-Birthdate header is included in the
DKIM signature it references, that's pretty much equivalent as
far as senders and receivers who are both using the same
authenticated birthdate spec are concerned, just more flexible
and less likely to clash with or break other DKIM usage.

Cheers,
  Steve

---

From: Michael Thomas <[email-masked]>
Date: Wed, 06 Apr 2011 09:42:58 -0700

> DKIM-Signature: v=1; d=corp.example.com;<blah>; db=19700224
>
> DKIM-Signature: v=1; d=corp.example.com;<blah>; h=To:Authenticated-Birthdate:<blah>

As I said, that would be a completely new requirement for
headers -- something that we don't do today. Also: you could
get into awkward situations where you'd be required to not
sign something that was present in the message if you couldn't
vouch for its correctness, even if you wanted to vouch for its
transport integrity.  If it's in the signature header itself, there's
no such ambiguity.

Mike

---

From: Hector Santos <[email-masked]>
Date: Wed, 06 Apr 2011 13:23:28 -0400

Michael Thomas wrote:
>> That sounds like a fragile way to extend things - leave a 
>> little used feature around and hope someone who wants something 
>> new hijacks that field in a non-conflicting way instead. (Which 
>> may not be what you're suggesting, but it's an implication I've 
>> seen in some comments about i=).
>>
>> Outside of the information that is needed to validate the DKIM 
>> signature (v, a, b, bh, c, d, h, l, q, s, t, x) there doesn't 
>> seem to be any real need for information to be recorded in 
>> the DKIM-Signature field at all. Rather, it can

> the narrow confines of the DKIM header itself.

Since DKIM provides mechanism for signers to achieve that authenticity 
outcomes independent for their reasons for standard features or 
extensions,
I think both points are valid but with a difference of one having a 
higher or lower threshold for authenticity verification.  So from this 
aspect, I would tend to agree with you that it would be probably 
better when extensions use the DKIM header.

Authenticity related to confining extensions to the DKIM header would 
be easier to reach and "harder" to reach when using extra headers 
because it presumes the extra headers will be persistent (passthru) 
along the path, hence why we have a recommended set of commonly known 
RFC 5322 headers to bind and expected to survive.

I hate to be anal about it, but all that made sense when Policy was a 
principle focus and not Reputation because Policy allowed us to grasps 
and deal with DKIM authenticity failures.

But now with reputation coming out of the closet as the WG accepted 
primary focus and everything related to DKIM; the proposed standard 
and helper RFC documents, its now only about assessing a positive 
authenticity with a trusted signer domain identity source. The mindset 
is now there is a lesser need to consider anything else.

In short, since reputation does not deal with authenticity failures, 
domains should be wiser regarding raising authenticity complexity and 
verification thresholds because reputation can't help you when things 
go wrong.

The lack of concern for dealing with faults or authenticity failures, 
makes it easier to consider removing or reducing the failure points 
which appear to have no value.

-- 
HLS

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 6 Apr 2011 10:25:55 -0700

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Michael Thomas
> Sent: Wednesday, April 06, 2011 9:43 AM
> To: Steve Atkins
> Cc: DKIM WG

Either method can ensure the data make it to the verifier intact, to be sure.  But this smells a bit like a layering violation to me.  Using a new DKIM tag to relay meta-data about the signer, rather than the actual signer's identity (or equivalent), strikes me as something that doesn't belong in DKIM.

---

From: Michael Thomas <[email-masked]>
Date: Wed, 06 Apr 2011 10:46:07 -0700

> Either method can ensure the data make it to the verifier intact, to be sure.  But this smells a bit like a layering violation to me.  Using a new DKIM tag to relay meta-data about the signer, rath…

Huh? What is a= or d= or s= if not "meta-data about the signer"?
Having cross semantic correlation of what headers mean with the
presence of dkim signatures from various different signers seems
like a lot more of layer violation to me. In any case, we haven't
gone down the route of giving semantics to *why* a signer
signs a given header which is really at the heart of this discussion.
The closest we have is From: that we require to be signed but
the "why" part is still something of a hand wave -- essentially
being "because we said so".

Mike

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 6 Apr 2011 10:53:28 -0700

> From: Michael Thomas [mailto:[email-masked]]
> Sent: Wednesday, April 06, 2011 10:46 AM
> To: Murray S. Kucherawy
> Cc: DKIM WG
> Subject: Re: [ietf-dkim] Extensions (was RE: Proposal: Removal of AUID (i= tag/value))
> 

They're the parameters you need to complete verification, so they are data about the signature, not the specific signer.

I'm sure you're not saying "a=" can be used to identify someone or something.

> like a lot more of layer violation to me.

That a DKIM hash covers a header field doesn't assign any new meaning to the field.  It only guarantees its integrity.

---

From: Michael Thomas <[email-masked]>
Date: Wed, 06 Apr 2011 11:05:32 -0700

> That a DKIM hash covers a header field doesn't assign any new meaning to the field.  It only guarantees its integrity.

But that's the basic problem with the approach that Steve
laid out: we don't enforce any semantics about why a signer
signs something. Doing so would open a large can of worms.
Limiting new additions to the dkim header itself at least
would limit the problem of adding new semantics of a
signature header to exactly the entity doing the signing.
The alternative would be very squirrelly when you think
of the general case of multiple signers in the path.

Mike

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 6 Apr 2011 11:15:38 -0700

> Sent: Wednesday, April 06, 2011 11:06 AM
> To: Murray S. Kucherawy
> Cc: DKIM WG

That's a good perspective.  I hadn't considered the idea of multiple independent signers.

---

From: Hector Santos <[email-masked]>
Date: Wed, 06 Apr 2011 14:49:45 -0400

> of multiple independent signers.

And equally as important are multiple independent verifiers where 
there are no realistic expectation for persistent verification 
extensions to be supported.  The only persistent expectation among all 
compliant verifiers is what's spelled out in the DKIM-BASE standard.

So if anything Murray, if you wish to write something about 
extensions, IMO, would be a note regarding increasing authenticity 
computational thresholds when using "extra header" bound versus using 
DKIM-Signature tags. The former has a higher threshold for integrity 
due to the presumption the extra headers will be persistent and 
survive unaltered along the transport and/or gateway path.

As a side note Murray, currently from an API standpoint, we provide 
operators the option to add extra headers to bind, but not add extra 
DKIM header tags outside the specification.  I believe you indicated 
OpenDKIM is currently prepared to same way?

Therefore, if we wish to provide guidance to current and future DKIM 
software developers, I think maybe you should consider to also add 
some generalized text, if its not already there in explicit form, 
indicating the DKIM standard allows for signer-defined non-standard 
tags to exist and be bound to the DKIM-Signature.  Of course, the only 
technical requirement would be for it to follow the tag=value ABNF syntax.

---

From: Franck Martin <[email-masked]>
Date: Thu, 7 Apr 2011 07:03:51 +1200 (FJT)

----- Original Message -----
> From: "Steve Atkins" <[email-masked]>
> To: "DKIM WG" <[email-masked]>
> Sent: Thursday, 7 April, 2011 4:29:49 AM
> >> signature

Yes, so far I have been trying to assert:

1) How hard is it to add a new dkim header like st= considering the current software implementation of DKIM
2) Can we use i= for a purpose of reputation as a) it's meaning is loosely defined, b) it is there already (cf (1) ) c) it has been used by some to differentiate different emails in the same domain.
3) Should we better get DKIM to sign a 5322 header because a) any DKIM implementation can do it b) for senders it is easy to add a header when the email is created and then sign it on the way out, than to figure what type of email it is on the way out during signing. c) for receivers a signed header is easy to process likewise.
4) Would senders and more important receivers likely to adopt such mechanism to mimic IP reputation with dkim, rather than using subdomains.

All of that is not related to the DKIM spec moving a step higher in the IETF unless if i= is dropped or not, but it is good to think potential implementations now, I think. 
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Steve Atkins <[email-masked]>
Date: Wed, 6 Apr 2011 12:34:12 -0700

On Apr 6, 2011, at 11:05 AM, Michael Thomas wrote:

> signs something.

Nope, we don't. And shouldn't.

> Doing so would open a large can of worms.

It certainly might. Which is why we should avoid that
sort of thing in DKIM itself, and let potential users specify
what semantics they mean on a case by case basis (in,
say, the specification for the particular metadata they're
adding as a header).

> signature header to exactly the entity doing the signing.

Ah, no. If it's added to the DKIM header itself it will affect
the entity doing the signing, and every entity they send
email to. The affect on those who aren't cooperating with
the sender may be small, but it's certainly there.

Encouraging people to add semantics into the DKIM-Signature
beyond the basics of "These headers and this body were
sent by this d= defined entity" seems somewhat dangerous,
whether it be by adding non-standard fields to the header
or by overloading the semantics of existing fields.

The fewer moving parts, the less likely it is to break. And
I'd be much less bothered by some proprietary bit of
metadata being broken than I would by the entire
DKIM authentication being broken. Not putting those
extensions within the DKIM data itself reduces the
chance of them breaking the DKIM authentication.

> of the general case of multiple signers in the path.

The approach I suggest has no problems with multiple
signers even if they, for some reason, all want to add
conflicting metadata.

(And I don't actually see much of a use case for it, it's
just a demonstration that there is no need to shove
unrelated data into the DKIM signature, rather it can
be added cleanly at a different layer.)

Cheers,
  Steve

---

From: "John R. Levine" <[email-masked]>
Date: 6 Apr 2011 15:47:42 -0400

>> of the general case of multiple signers in the path.

That's not an unreasonable point, but it depends how important you think 
it is to support inconsistent assertions on the same message.  If you have 
assertions that this is the author's real age, or that is the author's 
real e-mail address, who cares if different signatures can't make 
different assertions?

I like the idea of limiting additions to DKIM to things that are related 
to the signature itself rather than to other aspects of the message. 
Presumably we can have an argument whether "this is the real e-mail 
address of the signer" (not the author) is sufficiently related.

Regards,

---

From: Michael Thomas <[email-masked]>
Date: Wed, 06 Apr 2011 12:52:14 -0700

On 04/06/2011 12:34 PM, Steve Atkins wrote:
> \

Yes it does. In your example, a second signer who isn't
privy to whether it knows the birth date could either sign
it because it wants to keep transport integrity, or not
sign it because it doesn't actually know the veracity of
the X-Birthdate: header. The receiver is then left trying
to figure out who is asserting what, most likely by putting
new rules/requirements on the DKIM signer.

Messy and error prone. At least if you put it into the signature
header you know for certain what the signer's intention is.

Mike

---

From: Steve Atkins <[email-masked]>
Date: Wed, 6 Apr 2011 13:18:11 -0700

> new rules/requirements on the DKIM signer.

If you look at the example I gave, it mentions
which DKIM identity is making the assertion.

It's easy for the signer to tell what's going on - if there's
a dkim sig for d=corp.example.com that covers that header,
then it's safe to assume that corp.example.com is the one
making that assertion.

If foo.bar.com has also signed that header that means...
nothing, semantically. foo.bar.com would need to prepend
it's own Authenticated-Birthdate header, with "dkim=foo.bar.com"
in it, and sign the whole thing.

It's not particularly pretty, but it's fairly obvious to the recipient
what's going on, and unlikely to break anything.

(There's an obvious hole if you have access to a signer that
just signs every header, rather than a fixed list of headers,
but that's fairly far in to "don't do that" territory).

> header you know for certain what the signer's intention is.

I don't think you do. If you put it in the signature header in an existing
field (e.g. i= or s=) then there's no common understanding of the
semantics beyond what 4871 has to say about them.

If you put it in the signature field in an ad-hoc way, you risk
clashing with someone else's use of it.

The only safe way to add proprietary gunk into the dkim-signature
header is to add it to the IANA DKIM-Signature tag registry
(how does that happen? Presumably it requires an RFC?)

That's certainly a reasonable approach, but the overhead
of doing that (vs adding an ad-hoc field or using a 5322
header) makes me think it unlikely people will do that.

Cheers,
  Steve

---

From: Michael Thomas <[email-masked]>
Date: Wed, 06 Apr 2011 13:41:10 -0700

> what's going on, and unlikely to break anything.

   Bletch. At least this is all theoretical now. Thankfully.

> but that's fairly far in to "don't do that" territory).

I think it's a little worse than that. It sort of also expects
corp.example.com's mail infrastructure to be consistent,
and that you don't get multiple trips through the signer
infrastructure tickling those inconsistencies. Weird
stuff does happen, especially when you get companies
bolted together.

> clashing with someone else's use of it.

I'm only talking about a standards based approach here.
Non-standard use would make a messy situation even messier.

> header) makes me think it unlikely people will do that.

The net-net is that either way, the DKIM signer code would
need to change. So do you want the DKIM signer to need to
parse/understand the semantics of another RFC, or understand
an extension to DKIM itself. I'd worry that the DKIM considerations
in the rush to have the all important X-Brithdate rfc would be
lost on the DKIM signer maintainers. By putting it into the
DKIM header itself, you have to *force* them to pay attention
to the problem if you want the feature.

Mike

---

From: Tony Hansen <[email-masked]>
Date: Wed, 06 Apr 2011 16:53:41 -0400

> but that's fairly far in to "don't do that" territory).

This is an interesting approach, but I find this last bit to be the 
rather big hole.

If this approach were chosen, this argues for any such header, to be 
within a namespace such as Policy-Semantics or DKIM-Semantics.

> semantics beyond what 4871 has to say about them.

Other RFCs would need to be written that went beyond the two 4871 
requirements of "opaque" and "unique" for i=, that give a mechanism (a 
semantic signpost) to the signer for how to specify what those semantics 
were.

> (how does that happen? Presumably it requires an RFC?)

Any new tag added to either the dkim signature or the dns key record 
MUST (yes, a normative MUST) be written up in an RFC and reach IETF 
consensus to be added to either one of the tag registries. See section 7 
of RFC 4871 and the definition of IETF Consensus found in RFC 2434.

> header) makes me think it unlikely people will do that.

For there to be reasonable semantic meaning, it must be understandable.

Whether it were done by adding semantic signposts for i=, additional tag 
values, or additional 5322 headers, it should *not* be done in an ad-hoc 
fashion.

     Tony Hansen
     [email-masked]

---

From: "John Levine" <[email-masked]>
Date: 6 Apr 2011 22:06:25 -0000

>values, or additional 5322 headers, it should *not* be done in an ad-hoc 

Quite right.  We need drafts, implementations, all the usual stuff.
At this point, i= is clearly nothing other than an opaque token with
a funky syntax, which seems not to be very useful semantics.

I get the impression that some people (not you) are under the
misconception that if they can sneak their pet feature into the spec,
that will force everyone to implement it.

R's,
John

---

From: "Rolf E. Sonneveld" <[email-masked]>
Date: Wed, 06 Apr 2011 23:33:37 +0200

> values, or additional 5322 headers, it should *not* be done in an ad-hoc

+1

/rolf

---

From: Hector Santos <[email-masked]>
Date: Wed, 06 Apr 2011 20:41:17 -0400

> values, or additional 5322 headers, it should *not* be done in an ad-hoc 

+1.

 From my perspective, we are beyond the idea of whether i= or a new 
st= tag is needed or not, but rather whether the proposed standard 
provides sufficient guidelines for the modelers to implement and allow 
extensions to exist.

Case in point:

Any installed base of DKIM system designed using popular open source 
DKIM APIs, would not ready to support DKIM-Signature tags extensions 
without change.

However, due to the DKIM standard fundamentally requires 
implementation flexibility to sign user-defined RFC5322 headers with 
only one minimum requirement to sign 5322.From, implementators must 
follow this technical design requirement to allow systems to add 
additional headers to be signed, whether it is well-known or not.

Then is its reasonable to suggest to add some text to the proposed 
standard (now, not later) that provides some extensions guidelines 
starting with two off the top my head:

   - DKIM implementators SHOULD allows adding non-standard tags to
     the DKIM-Signature

   - DKIM Extension namespace naming convention for adding
     Extra Headers or tags.

If we think extensions will be an important part of DKIM future then 
we need to make sure we provide the semantics to allow extensions to 
be explored and co-exist with wider DKIM installed base support 
without needing to revisit the RFC 4671 specs.

Even if one suggests that a new RFC for "DKIM Extension Design 
Guideline" would suffice, until that is done, we still need some 
additional text in the proposed standard to that should be a 
implementation consideration.

Maybe a single sentence to advise developers to allow this flexibility 
to exist is all that is needed.

-- 
HLS

---

From: Hector Santos <[email-masked]>
Date: Wed, 06 Apr 2011 22:53:57 -0400

Franck Martin wrote:

> 1) How hard is it to add a new dkim header like st= 
      considering the current software implementation of DKIM

Of the current popular open source APIs I am aware of and I use of one 
them, this will require a software change.

The better idea is to propose that implementators add the ability for 
operators to add extra tags to the DKIM-Signature.  That will probably 
get better traction with DKIM API developers.

> 2) Can we use i= for a purpose of reputation as a) it's meaning is loosely defined, b) it is there already (cf (1) ) c) it has been used by some to differentiate different emails in the same domain.

This sound more like a POLICY need.

> 3) Should we better get DKIM to sign a 5322 header because a) any DKIM implementation can do it b) for senders it is easy to add a header when the email is created and then sign it on the way out,…

DKIM technical design requirements calls for flexibility to allow 
additional headers to be hash bound to the signature.  So it is safer 
to have an expectation that DKIM implementations for signing mail 
offer a way for DKIM administrators to pick and set what headers will 
be signed.  How they offer it is a different matter.

> 4) Would senders and more important receivers likely to 
> adopt such mechanism to mimic IP reputation with dkim, 
> rather than using subdomains.

When you say IP Reputation, do your bad IP filtering as done with DNS 
RBL methods or IP white-listing?  Are you talking about SPF?

If your reason is the concern IPv6 will kill IPv4. Just consider SMTP. 
Its needs to support IP4 to keep the public mail infrastructure 
running. To presume IPv6 will kill IPv4 is to presume that all SMTP 
software will STOP allowing IP4 connections. I don't think that would 
be desirable. I wouldn't worry about this happening anytime soon, nor 
would it be a reason for what you want.

So for your idea, because it is already possible to create 
multi-signer streams, the only incentive I can see is a signer 
incentive to reduce multi-signer stream management and cost related 
issues.

It sounds your question about handling results a certain way.

---

From: Douglas Otis <[email-masked]>
Date: Wed, 06 Apr 2011 20:16:33 -0700

On 4/6/11 3:06 PM, John Levine wrote:
> > Whether it were done by adding semantic signposts for i=,
> > additional tag values, or additional 5322 headers, it should *not*
> > be done in an ad-hoc fashion.
>

John,

i= is currently defined as "The Agent or User Identifier (AUID) on 
behalf of which the SDID
is taking responsibility".

Other than remaining within the signing domain, the token need not be 
recognizable to receivers, but according to current definitions, the 
signing domain asserts their recognition of this field as a token for 
the AUID.  In that sense, the token could be considered opaque for 
receivers, but not without meaning or value from the aspect of tracking 
or dealing with abuse.  When used as defined, it provides a means for 
the signing domain to differentiate their mail streams using a common 
signature.  There are no similar semantics with From, Sender or any 
other header that can be found within a message.

>  misconception that if they can sneak their pet feature into the
>  spec, that will force everyone to implement it.

Too Big to Block domains may have trouble dealing with compromised 
accounts where the i= field could prove useful.  This is not about 
sneaking in some odd or until now undefined field.   While all large 
domains include a way of identifying the AUID in some odd fashion, the 
i= field is where this token obtains a standardized location.   As such, 
it can greatly aid in tracking and reporting abuse.  We have yet to rely 
upon domain reputation, but the prospect of dealing with IPv6 is sure to 
have domain reputations playing a greater role.

It does not appear anyone at this time has a good handle on controlling 
compromised accounts.  I like having an ability to use different 
identities from the same account.  If my mom's system were to become 
compromised, by having a way for abuse reporting to accurately source a 
problem, this improves the chance that affected user will be made aware 
of the problem, as they should.

Adding a new header that replicates the signing domain would still not 
offer any assurance the signing domain was the agent that added this new 
header.  The only place do do this properly would be within the DKIM 
header itself.

-Doug

---

From: "Charles Lindsey" <[email-masked]>
Date: Thu, 07 Apr 2011 13:05:03 +0100

> (how does that happen? Presumably it requires an RFC?)

Do we currently have such an IANA DKIM-Signature tag registry? We  
certainly OUGHT to have one. It it permissable to add one now without  
recycling at Proposed? I would have thought it was, in which case matters  
such as whether an RFC was needed for new tags could be specified.

---

From: "Charles Lindsey" <[email-masked]>
Date: Thu, 07 Apr 2011 13:13:40 +0100

> DKIM-Signature: v=1; d=corp.example.com; <blah>; db=19700224

Actually, what you want is a gerenal purpose txt or comment header, in  
which the signer can place any remark that he considers worthy of his  
signature (including the capacity in which he is adding his signature -  
another feature that people argue about).

E.g. DKIM-Signature: v=1; d=corp.example.com; <blah>;
                      tx="birthdate=1970-02-24"

or   DKIM-Signature: v=1; d=corp.example.com; <blah>;
                      tx="signed by List Expander"

I suppose such a tag would have to be an extension to avoid recycling at  
Proposed.

---

From: Steve Atkins <[email-masked]>
Date: Thu, 7 Apr 2011 08:34:00 -0700

> such as whether an RFC was needed for new tags could be specified.

We do have one already.

http://www.iana.org/assignments/dkim-parameters/dkim-parameters.xml

Cheers,
  Steve

---

From: Steve Atkins <[email-masked]>
Date: Thu, 7 Apr 2011 08:44:56 -0700

> I suppose such a tag would have to be an extension to avoid recycling at  

It's not machine readable and has no semantics - so a sender who just
wants to stash human readable trace or advertising content (a-la User-Agent)
could use a 5322 field just as well, possibly the "Comments".

If the thought is (as your first example seems to imply) that it's
a plain text field in which any implementor can make up a syntax
for adding additional fields then I think that's probably a bad idea
and would end up just being used to end-run around the tag
registry, and likely lead to all sorts of grungy heuristic hacks (much
as we see in TXT records in DNS, but worse as there's no namespace).

Cheers,
  Steve

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 7 Apr 2011 09:43:04 -0700

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Charles Lindsey
> Sent: Thursday, April 07, 2011 5:05 AM
> To: DKIM

Yes, RFC4871 created such a registry, so it's been around since the beginning.  See Section 7.  RFC4871bis updates it.

And yes, changing that registry outside of RFC4871bis doesn't derail the progress toward Draft Standard.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 7 Apr 2011 10:08:09 -0700

> Sent: Wednesday, April 06, 2011 12:04 PM
> To: Steve Atkins
> Cc: DKIM WG

Fairly simple.  I've opened a feature request for libopendkim to add it, and I expect it in the next release.  I'll see if I can extend our stats stuff to cover use of unknown tags so we can track uptake.

> 2) Can we use i= for a purpose of reputation as a) it's meaning is
> loosely defined, b) it is there already (cf (1) ) c) it has been used
> by some to differentiate different emails in the same domain.

You could, if you know that the use of "i=" by a given SDID is consistent, and it's useful for you to track per-AUID reputation.  Those are two big "if"s to me.

> 3) Should we better get DKIM to sign a 5322 header because a) any DKIM
> implementation can do it b) for senders it is easy to add a header when
> the email is created and then sign it on the way out, than to figure
> what type of email it is on the way out during signing. c) for
> receivers a signed header is easy to process likewise.

To summarize my current feelings on that question: Data about a message belongs in a header field; data about a signer belongs in the signature.

> 4) Would senders and more important receivers likely to adopt such
> mechanism to mimic IP reputation with dkim, rather than using
> subdomains.

Probably, if it can be shown to be effective.  We need data to support widespread adoption.

There are lots of people on this list that are spending a lot of energy speculating about what we need and what will work.  How many of us are actually willing or able to conduct some experiments and report back data, and put energy into writing drafts, versus simply being visibly sad or upset about what's "missing"?

-MSK

---

From: Hector Santos <[email-masked]>
Date: Thu, 07 Apr 2011 19:06:13 -0400

> To summarize my current feelings on that question: 
> Data about a message belongs in a header field; data about 
> a signer belongs in the signature.

Yet a message header hash bound to a signer signature is a natural 
DKIM design concept for message::signer associations binding the two 
"layers" I believe your feelings attempts to delegate or imply exist 
as separate needs.

The main point is that the current spec functional design requirements 
breeds implementation models expected to allow for extra headers 
signature bindings regardless of its content and context.   AFAIK, the 
specs do not have any similar semantics about extra signature tags 
which may explain why at least two APIs did not implement this 
functionality.

Developer to Developer, looking at how to extend the ALT-N LibDKIM API 
to support adding tags to the DKIM-Signature, off hand, its not as 
easy as it may sound.   There would be three models for this:

   1) A simple optional flat list of predefined tags=values that would
      easily added to the DKIM-Signature prior to the hash computation.

   2) A flat list with tag=value items where value is extracted from
      other part using perhaps a macro expansion concept:

      st={54322.FROM}

   3) DKIM Signer Extension Plug-in Model which calls some vendor
      specific embedded code concept, ACL, MILTER, WCX or some other
      scripted method called from the DKIM SIGNER component.

The easier implementation is #1 and maybe with limited #2 would work.

So to answer to this question, yes, it is better to use headers if 
only because it would be the only way to currently maximize the 
probability of support without a need for software change.

---

From: Douglas Otis <[email-masked]>
Date: Thu, 07 Apr 2011 17:00:11 -0700

> You could, if you know that the use of "i=" by a given SDID is consistent, and it's useful for you to track per-AUID reputation.  Those are two big "if"s to me.
Murray,

Anyone processing this type of data will quickly determine whether the 
i= field provides value with respect to correlation.

Anything else within the message is likely to offer less.  Even 
proposing an "ideal" and perfectly defined header is unlikely to find 
the current levels of i= compliance, although some may disdain its 
inelegant domain matching requirement.  Nothing is perfect and it would 
be unfortunate to have it deprecated for that reason.

-Doug

---

From: Hector Santos <[email-masked]>
Date: Fri, 08 Apr 2011 07:17:31 -0400

>> You could, if you know that the use of "i=" by a given 
>> SDID is consistent, and it's useful for you to track per-AUID 
>> reputation.  Those are two big "if"s to me.

+1

> Nothing is perfect and it would be unfortunate to have it 
> deprecated for that reason.

+1.

I think I will change my support to keep as is or keeping it with 
better semantics that do not cause compatibility issues with legacy 
verifiers.
That mean not changing the d=/i= relationship definition as this will 
break software.

DKIM "perfections" will continue to be difficult challenge as long as 
the various deployment motivations are in conflict, more specifically 
when the motivations for the trust come at the expense to ignore or 
outweigh the motivations for securing protected bits.

IOW, a motivation for i= or adding any other signed bit (header or 
tag) may simply be a domain desire to increase the authenticity 
challenge.  After all, when authenticity fails, any motivation for 
trust based policy semantics "I expect you to trust the signer domain" 
can not be applied.

-- 
HLS

---

From: "Charles Lindsey" <[email-masked]>
Date: Fri, 08 Apr 2011 12:38:56 +0100

> could use a 5322 field just as well, possibly the "Comments".

Yes, I thought of that. But my intent was that at least this tag would be  
reported in any Authentication-Results header, and that header is normally  
the first place people will look to resolve suspicions concerning  
signatures. Essentially, it is for human interpretation, but good luck to  
anyone who finds some way to use it automatically.

The 'i=' tag is in a similar state. For sure it is useful to have some  
signed indication of who the actual author was (in situations where the  
signer can be sure of that). That was what 'i=' was supposed to achieve,  
but its semantics are a bit too weak for that. Nevertheless if (as seems  
to be the case) it is shown in the Authentication-Results it would have  
some value for humans (and even for automata when used with care).

In practice, there are three usages which seem to be common; are there  
others?

1. FROM = Alice@whatever  i=sales.example.com d=example.com

2. FROM = [email-masked]  i=[email-masked] d=example.com

3. From = [email-masked]  i=[email-masked] d=example.com.

1. Gives some clue, and avoids a different key for the sales subdomain

2. Is fine, but don't expect [email-masked] to be a working email  
address.

3. Is a cause for suspicion, but it takes a human to realise the  
distinction between "bob" and "sales".

So my inclination is to leave 'i=' there. It is currently used, and will  
continue to be used even if we remove it. It is not actually broke - just  
not quite fit for purpose.

---

From: Franck Martin <[email-masked]>
Date: Fri, 8 Apr 2011 18:55:09 +0000

>not quite fit for purpose.

This is outside the current DKIM spec, but from your example, we could
define 3 level of reputations for the domain d=example.com (I'll exclude
case 1. As I don't know yet what to do with it)

Level 1) Alice
Level 2) sales or bob
Level 3) the whole domain example.com

It is then possible to decide if we should block (or whitelist) all emails
from alice, or all emails coming from sales (or bob) stream, or all emails
signed by d=example.com

---

From: "Charles Lindsey" <[email-masked]>
Date: Mon, 11 Apr 2011 10:06:51 +0100

>> 3. From = [email-masked]  i=[email-masked] d=example.com.

.....

>> So my inclination is to leave 'i=' there. ...
>

I think you may have missed the point of my 'bob' example. It would have  
been clearer if I had said:

3. From = [email-masked]  i=[email-masked] d=example.com.

Where mallet is some disgruntled example.com employee posing as Alice. A  
human seeing that evidence (E.g. in an A-R header) might well conclude the  
message was bogus. But it would be hard for an automaton to spot it.

---

From: "John R. Levine" <[email-masked]>
Date: 11 Apr 2011 11:53:34 -0400

> 3a. From = [email-masked] i=[email-masked] d=example.com

How in the world in an automaton supposed to guess that 3. is bogus and 
3a. is not?

A point that could use more emphasis is that effective use of DKIM 
is essentially a collaboration between senders and receivers who don't 
know each other except by the mail they exchange.  The best strategy for a 
sender is to figure out what its mail streams are, and put consistent 
signatures on each stream, so receivers can most easily sort them.  Rather 
than trying to invent ever more complex ways for receivers to read 
senders' minds, it would be more productive to provide advice to senders 
so that it's not necessary.

Regards,

---

From: Douglas Otis <[email-masked]>
Date: Mon, 11 Apr 2011 10:45:22 -0700

> message was bogus. But it would be hard for an automaton to spot it.
Charles,

DKIM does not make assertions beyond the domain verified within the 
signature that can be generally related with whatever message portions 
included within the signature's hash.

DKIM makes no requirements on Display or Friendly Names, the only thing 
many see.  What is contained in the i= field represents an optional 
opaque token based on recognitions by signing domains of the source, 
perhaps it contains the Radius or Diameter identifier for example.  When 
there is a problem discovered, this information allows selective 
feedback that can assist in maintenance of their trustworthiness.

One would hope example.com restricts use of originating email addresses 
to those confirmed using some type of ping-back.  Even this measure 
would not allow reuse of email-addresses by different entities, nor a 
way to tell when access had been subsequently revoked.  Selective 
feedback would help contain the possible spoofing allowed by 
non-federated methods of authentication, as might be used by a mailing-list.

Review the charter exclusions.  There can be no deeper meaning defined 
for the i= field.
,---

* Signatures that attempt to make strong assertions about the
identity of the message author, and details of user-level
signing of messages (as distinguished from domain-level keys
that are restricted to specific users).

* Duplication of prior work in signed email, including S/MIME and
OpenPGP.

'---

-Doug

---

From: "Charles Lindsey" <[email-masked]>
Date: Wed, 13 Apr 2011 12:19:14 +0100

> Review the charter exclusions.  There can be no deeper meaning defined

But undoubtedly individuals are going to use the field in ways that they  
find useful to their purpose (with knowledge of their own situations). All  
I am trying to say is that the 'i=' tag is not so totally broken that it  
is useless for any pourpose whatever. Hence it should be kept, since it is  
already there and will get used.

---

From: "Charles Lindsey" <[email-masked]>
Date: Wed, 13 Apr 2011 12:14:45 +0100

> How in the world in an automaton supposed to guess that 3. is bogus and

It isn't supposed to (unless some future son-of-DKIM tells us how). But  
humans can usually spot the difference between a personal address and a  
role address and act accordingly, of even code their private  
implementations to do so.

---

From: Barry Leiba <[email-masked]>
Date: Wed, 13 Apr 2011 09:31:19 -0400

> already there and will get used.

As I've noted in the last call message, we are keeping "i=" in.  So we
don't need to discuss it further.  This topic is closed now.

Barry, as chair

---

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

> Right.  For people who still want to use ADSP, you're welcome to use two

I don't think we should encourage that. :)

--
Jeff Macdonald
Ayer, MA