Subject: [ietf-dkim] Open issues in RFC4871bis

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

In our conference call with Jim, Dave and I are left with three things that need discussion in the working group before we request a working group last call on it.

The first, and biggest, is the removal of "i=" that Jim has proposed separately, so please comment on that thread.

Two lesser issues are:

1) The document currently talks about authors signing their mail, when authors really don't sign their mail, ADMDs do.  The point of the objection is that it might be wiser to talk about actual uses only and not include possible uses.  The suggestion is thus to remove the idea that an author can do signing, changing it to "authors' organizations" or perhaps "authors' ADMDs".  Is there support for this, or support against making that change, or does it not really matter?

2) The document has text related to "assessment".  Does an "independent assessment service" fit into the DKIM model?  Again, the issue is whether or not we want to include discussion of uses that are possible but uncommon.  Is there support for this change, or support against making the change, or does it not really matter?

The text in question is this:

2.3.  Identity

   A person, role, or organization.  In the context of DKIM, examples
   include the author, the author's organization, an ISP along the
   handling path, an independent trust assessment service, and a mailing
   list operator.

We'd like to hand a revision to the chairs by April 10th to start WGLC, so please weigh in sooner rather than later on all three of these points so we can get some idea of consensus opinion and prepare the drafts accordingly.

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

---

From: Douglas Otis <[email-masked]>
Date: Fri, 01 Apr 2011 16:30:19 -0700

On 4/1/11 2:08 PM, Murray S. Kucherawy wrote:
>
> In our conference call with Jim, Dave and I are left with three things 
> that need discussion in the working group before we request a working 
> group last call on it.
>
>
> The first, and biggest, is the removal of “i=” that Jim has proposed 
> separately, so please comment on that thread.
>
For ADSP the d= and the From domain must match, which removes the need 
for i=. Nevertheless, the i= can introduce different identities that 
might assist when transitioning to different IDN encodings.

There is a growing use of UTF-8 DNS labels. For example use dig to 
resolve バスケ指導.meblog.biz or xn--rckp2e534u8jh.meblog.biz. RFC6055 
should be read with an understanding there will be increased UTF-8 use 
in DNS. While currently RFC5321 requires email domains to use letters 
digits and hyphens, such a requirement will be problematic for other 
name services. It is also not clear whether UTF-8 aliases would be 
prohibited, since the only requirement appears to be resolution of 
necessary resources. It is too soon to know how this might be best 
resolved, so why toss out options that might help resolve what a signing 
domain hopes to permit.
>
> Two lesser issues are:
>
> 1) The document currently talks about authors signing their mail, when 
> authors really don’t sign their mail, ADMDs do. The point of the 
> objection is that it might be wiser to talk about actual uses only and 
> not include possible uses. The suggestion is thus to remove the idea 
> that an author can do signing, changing it to “authors’ organizations” 
> or perhaps “authors’ ADMDs”. Is there support for this, or support 
> against making that change, or does it not really matter?
>
It matters, and it should indicate the domain does the signing, while 
also getting rid of the g= stuff in the key.
>
> 2) The document has text related to “assessment”. Does an “independent 
> assessment service” fit into the DKIM model? Again, the issue is 
> whether or not we want to include discussion of uses that are possible 
> but uncommon. Is there support for this change, or support against 
> making the change, or does it not really matter?
>
It is likely the only sustainable assessment will be matching with known 
good sources, which would benefit by having a means to handle aliases 
and authorized paths. :^)
> *2.3**. Identity*
DKIM should make no claims about identities. DKIM only relates signed 
portions of a message with that of a domain that publishes the public 
key. Would it be right to suggest this domain _is_ an identity?

Take your time. There is no rush is there?

-Doug

---

From: "John Levine" <[email-masked]>
Date: 2 Apr 2011 04:10:05 -0000

>   handling path, an independent trust assessment service, and a mailing

The current language looks fine to me.

R's,
John

---

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

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Douglas Otis
> Sent: Friday, April 01, 2011 4:30 PM
> To: [email-masked]
> Subject: Re: [ietf-dkim] Open issues in RFC4871bis
> 
> might assist when transitioning to different IDN encodings. [...]

Doug, I reiterate: Please comment on *that* thread.  That is, discuss "i=" over there, not here.

> and authorized paths. :^)

I have no idea whether you're expressing an opinion for or against the suggested change here.

> key. Would it be right to suggest this domain _is_ an identity?

Section 2.3 is only a definition, not an expression of signature semantics.  So, again, I don't understand how you're answering the question(s) here.

---

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

> From: John Levine [mailto:[email-masked]]
> Sent: Friday, April 01, 2011 9:10 PM
> Cc: Murray S. Kucherawy

[as participant, not document editor]

+1.

---

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

>    handling path, an independent trust assessment service, and a mailing

Sorry, but for the record I can't help to feel there is something 
wrong, a sense of conflict of interest,  with this inclusion of 
"independent trust assessment service."  We could be also fair and 
independent with foresight for additional future DKIM assessment 
models and future business markets and this in as well:

      "Centralized Repository Domain POLICY Service Bureaus"

which may not be based on d= only. When your definition includes other 
entities such as the author, you need to also thru in POLICY if you 
are going to include this "independent trust assessment service."  To 
be on par with the mail system form of the other identities you have, 
it seems to ne "signer domain" would be enough, we get it.

If you really bent on this, maybe using

     [independent] signer assessment source|agent

would smell better.

-1 to have this wording you proposed.

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

---

From: Alessandro Vesely <[email-masked]>
Date: Mon, 04 Apr 2011 12:50:08 +0200

>    handling path, an independent trust assessment service, and a mailing

Besides assessment services, there have been several discussions about
operators along the handling path, who sometimes break signatures.  I
propose to clarify the text that discusses the interpretation, in
Section 4.2, by adding a sentence to the fourth paragraph, something
like so:

   Signers SHOULD NOT remove any DKIM-Signature header fields from
   messages they are signing, even if they know that the signatures
   cannot be verified.  Instead, when a relay alters a message such
   that any valid signature gets broken, it SHOULD re-identify the
   message by synthesizing a new Message-ID for it, according to
   Section 3.6.4 of RFC 5322.

Would that help deterring on-the-fly auto-conversions?

---

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

>Would that help deterring on-the-fly auto-conversions?

No, and it would be a bad idea, anyway.  I often get two copies of a
message, one sent directly to me, one relayed through a mailing list
that changed it enough to break the signature.  By any normal
standard, they're the same message, and it's useful to be able to tell
that from the common Message-ID.

Breaking long-established mail semantics to punish people who don't
run mail the way you like is not a good idea.  And in any event, if
people were sufficiently aware of DKIM to do what you suggest, they're
aware enough to add a new signature which is the right thing to do.

R's,
John

---

From: Alessandro Vesely <[email-masked]>
Date: Mon, 04 Apr 2011 19:34:30 +0200

> that from the common Message-ID.

You often said you don't sort list messages by author...

I heard the opposite complaint, about gmail automatically keeping a
single copy of list messages based on Message-ID.  That poster said:

  So, the user doesn't know whether moderator disapproved or edited
  the message. Some moderators put replies to members' questions in
  edits, so Gmail users don't see such replies to their questions.

Apparently, not all lists were made equal.

> [I]f people were sufficiently aware of DKIM to do what you suggest,
> they're aware enough to add a new signature which is the right
> thing to do.

Agreed, and I also agree that mailing lists are a minor concern in the
current landscape.  The MLM document could explicitly dispense mailing
lists from obeying the "SHOULD" quoted above, under suitable
conditions --they already remove signatures.

It is hard to accept that signatures may break even when the message
is not actually changed.
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

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

> The current language looks fine to me.

Some people are talking about changing the wording here.  I think it would be helpful to frame that part of the conversation.

The text cited above as 2.3 is not new.  It reached working group consensus already because it was part of RFC5672.  Thus, its presence in RFC4871bis is already effectively approved.  Any changes to it require new consensus.  My citing it isn't introducing anything new; anyone that is proposing changes to it has to garner consensus to make any changes stick.

Similarly, the proposal to drop "i=" and all text that refers to it is a change from everything we've approved so far, and requires working group consensus to make that change.

---

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

> Some people are talking about changing the wording here.  I think 
> it would be helpful to frame that part of the conversation.
> 
> The text cited above as 2.3 is not new.  It reached 
> working group consensus already because it was part of RFC5672.  
> Thus, its presence in RFC4871bis is already effectively approved.  

And the same concerns cited then were also ignored.

> Any changes to it require new consensus.  My citing it isn't 
> introducing anything new; anyone that is proposing changes to it 
> has to garner consensus to make any changes stick.

Murray, consistent modeling of all documents is ideal and from an mail 
system integration standpoint, higher welcomed by implementators, 
specially those with mail products in the place.

But a fine line has been crossed when you talking about an open 
standard with hooks for future adaptations and one that begins to 
cater to a specific commercial business model interest with no hooks 
or lock out for future alternatives such as policy.

The thing is you don't need it, signer domain is enough, we get it and 
all this does is give a black eye to DKIM.  And even though, its not 
as big an issue than how it encourages HANDLING by REPUTATION as the 
expense of not encouraging handling by POLICY, which in the anal world 
of standards correctness, HANDLING be an open-ended concept allow for 
future adaptability.

So if anything that term does not fit with section 2.3 to define what 
are the identities.  Signer domain is the identity, not "Independent 
Trust Assessment Service" because its it different concept and layer 
quite frankly, and worst, it adds to the "Batteries Required" PR 
problem DKIM has.

But if you want to be fair, and want to keep it in, in the spirit of 
Cooperative Competition (CooComp) use common open standards, then it 
only prudent to also add:

     "Domain Signing Practices Policy Assessment Engines"

The problem that the current document is peppered with only trust 
ideas and not policy, which by itself breaks the spirit of isolation 
raw DKIM-BASE processing standard from any specific implementation 
ideas for handling results.

I think we need to stop playing these games and just add a section in 
DKIM to deals with the serious dearth and ultimate need for DKIM - 
HANDLING.

I don't see any issue with generalized suggestions for DKIM assessment 
technologies possible for DKIM handling, that recognizes both TRUST 
and POLICY methods.

--
HLS