Subject: [ietf-dkim] New Issue: Discussion of assessments in Selector Construct section

From: Jim Fenton <[email-masked]>
Date: Mon, 24 Mar 2008 22:00:05 -0700

Section 4.3, "The Selector Construct", talks quite a bit about 
identities for doing assessments.  Other than the point that it makes in 
the section beginning NOTE:, none of this has anything to do with 
selectors.  Furthermore, I consider it premature to define the 
identity(-ies) that might be used for assessments, not having 
operational experience with this (although I do agree that making 
assessments based on the selector is a Bad Idea).

The last paragraph also suggests the use of different sub-domains for 
d=, but does not point out that the author address must also follow 
suit, otherwise the message may not be seen to be in compliance with 
Signing Policy.

Specifically, I suggest the removal of all but the first sentence of 
paragraph 1, and all of the last paragraph of the section.

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

---

From: Dave Crocker <[email-masked]>
Date: Mon, 24 Mar 2008 23:02:10 -0700

Jim Fenton wrote:
> identities for doing assessments.  

Let's take care of the "quite a bit", just to make sure we are in sync about the 
relevant text.

The first paragraph merely says that d=/i= are used for making assessments.  The 
last  paragraph does go into some detail about providing differential 
identities, in order to support differential assessment.  I can see how that 
discussion might seem odd in this section.

On reflection, I'm suspecting there needs to be a separate sub-section, along 
the lines of "Choosing names to be used for assessment."

The current text was motivated by the considerable community confusion 
surrounding use of i=/d=/s= (as well as their complete independence from From:, 
Sender: and the rest).  Folks out there who are trying to figure out how to make 
DKIM work are typically either very confused about the issue or at just plain 
getting it wrong.  The current text was intended to try to clarify at least some 
of this.

Not adequately, it would seem.

Other than the point that it makes in
> assessments based on the selector is a Bad Idea).

This re-introduces the basic question of what DKIM's output is.  Protocols have 
explicit input and output.  Either DKIM is a complete and precise protocol or it 
is some sort of fuzzy mechanism creating a guessing game between signers and 
verifiers.  This confuses the higher-level task of assessing -- which will 
always be a bit fuzzy, at best -- and the underlying act of asserting a 
responsible domain name.

Since the DKIM specification says that its task is "permitting a signing domain 
to claim responsibility" there had better be a very precise way of determing 
what domain is doing the claiming.  As soon as there is more than one 
possibility, then it is no longer a serious protocol.

> suit, otherwise the message may not be seen to be in compliance with 

I don't understand.  What is there in the DKIM signing protocol that requires 
the author adress to "follow suit"?

> paragraph 1, and all of the last paragraph of the section.

Since I believe that clarification of the role of the selector -- and in 
particular making sure the reader knows that it is NOT part of the assessment 
process -- your suggestion is problematic.

d/
-- 

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

---

From: Jim Fenton <[email-masked]>
Date: Tue, 25 Mar 2008 08:46:17 -0700

Dave Crocker wrote:
> Let's take care of the "quite a bit", just to make sure we are in sync 
> about the relevant text.
>
> The first paragraph merely says that d=/i= are used for making 
> assessments.  The last  paragraph does go into some detail about 
> providing differential identities, in order to support differential 
> assessment.  I can see how that discussion might seem odd in this 
> section.
>
> On reflection, I'm suspecting there needs to be a separate 
> sub-section, along the lines of "Choosing names to be used for 
> assessment."
>
> surrounding use of i=/d=/s= (as well as their complete independence 
> from From:, Sender: and the rest).  Folks out there who are trying to 
> figure out how to make DKIM work are typically either very confused 
> about the issue or at just plain getting it wrong.  The current text 
> was intended to try to clarify at least some of this.
>

A separate section on "choosing names to be used for assessment" would 
definitely be preferable to having this information in the discussion of 
selectors.  However, I'm not convinced that we have enough experience to 
give guidance on this just yet.
> This re-introduces the basic question of what DKIM's output is.  
> Protocols have explicit input and output.  Either DKIM is a complete 
> and precise protocol or it is some sort of fuzzy mechanism creating a 
> guessing game between signers and verifiers.  This confuses the 
> higher-level task of assessing -- which will always be a bit fuzzy, at 
> best -- and the underlying act of asserting a responsible domain name.
>
> Since the DKIM specification says that its task is "permitting a 
> signing domain to claim responsibility" there had better be a very 
> precise way of determing what domain is doing the claiming.  As soon 
> as there is more than one possibility, then it is no longer a serious 
> protocol.
>
>
> I don't understand.  What is there in the DKIM signing protocol that 
> requires the author adress to "follow suit"?
>
Not in the signing protocol, but in ADSP.  If an email with a From 
address of, say, [email-masked] is signed with 
d=transaction.example.com then the signature cannot be an Author Signature.
> Since I believe that clarification of the role of the selector -- and 
> in particular making sure the reader knows that it is NOT part of the 
> assessment process -- your suggestion is problematic.

Why?  The second-to-last paragraph, beginning NOTE:, is the one that 
makes sure the reader knows that it is NOT part of the assessment 
process.  And that paragraph remains.

-Jim

---

From: Douglas Otis <[email-masked]>
Date: Tue, 25 Mar 2008 10:53:22 -0700

On Mar 24, 2008, at 10:00 PM, Jim Fenton wrote:

> identities for doing assessments.  Other than the point that it  
> makes in the section beginning NOTE:, none of this has anything to  
> do with selectors.  Furthermore, I consider it premature to define  
> the identity(-ies) that might be used for assessments, not having  
> The last paragraph also suggests the use of different sub-domains  
> for d=, but does not point out that the author address must also  
> follow suit, otherwise the message may not be seen to be in  
> compliance with Signing Policy.

IMHO, signing policy should separate itself from constraints defined  
by RFC4871 regarding the scope of identities that can be associated  
with signatures.  Signing Policy should be limited to whether a  
particular domain signs all of their messages, where which identities  
are associated with the signature is a separate issue.  It is counter  
productive to have verifiers expend efforts policing the scope of  
identities included within a policy hierarchy extending to sub- 
domains.  Is this really a problem that needs to be solved via signing  
policy.  After all a parent domain is free to publish any records they  
wish, where DKIM unable to change that reality.

> paragraph 1, and all of the last paragraph of the section.

Disagree, this is perhaps one sentence that gets the link to a  
responsible entity right?

-Doug

---

From: Dave Crocker <[email-masked]>
Date: Tue, 25 Mar 2008 21:16:41 -0700

> d=transaction.example.com then the signature cannot be an Author Signature.

I thought we had agreed to defer having the Overview document talk abut the 
Signing Practices material until it is standardized?

d/
-- 

   Dave Crocker

---

From: Jim Fenton <[email-masked]>
Date: Tue, 25 Mar 2008 21:58:07 -0700

Dave Crocker wrote:
> I thought we had agreed to defer having the Overview document talk 
> abut the Signing Practices material until it is standardized?

Notwithstanding the fact that the Overview Document does currently talk 
about Signing Practices, we should avoid giving advice that we expect to 
conflict with Signing Practices, even without mentioning them explicitly.

-Jim

---

From: Dave Crocker <[email-masked]>
Date: Tue, 25 Mar 2008 22:07:15 -0700

> conflict with Signing Practices, even without mentioning them explicitly.

Hmm.  Well, yeah, -overview does make reference to signing practices a number of 
times, albeit in generic and conceptual terms.

If there is text already there that you believe is giving advice we expect to 
conflict with Signing Practices, what text is that, precisely and how does it 
conflict with what we expect?

Apologies if you've already indicated these details, but I've lost track.

d/
-- 

   Dave Crocker