Subject: [ietf-dkim] New version - draft-ietf-dkim-rfc4871-errata-01

From: Dave CROCKER <[email-masked]>
Date: Mon, 02 Feb 2009 11:18:49 -0800

Folks,

Howdy.

A new version of the Errata draft has been submitted.

Text and diffs are at:

    <http://dkim.org/ietf-dkim.htm#errata>.

The revision attempts to reflect the online discussion and apparent consensus.

It's likely that I've over-interpreted the consensus. Further discussion in the
group ought to highlight and resolve remaining concerns.

Generally, the changes dealt with:

    1. Definitions

    2. Further clarifying relationships between

       a)  identity and identifier

       b)  d=/i= roles

       c)  interpretation within the DKIM Signing spec, versus outside of it.

Enjoy!

d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

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

---

From: Dave CROCKER <[email-masked]>
Date: Mon, 02 Feb 2009 11:42:44 -0800

> Generally, the changes dealt with:

Sorry, forgot an important item:

    3.  Changed section 6.3 and Appendix D references to be to SDID (d=)

Since the new consensus appears to be that i= has semantics that are entirely 
undefined, it does not seem possible that the wg would advise showing it to an 
end user.

d/

-- 

   Dave Crocker

---

From: "Charles Lindsey" <[email-masked]>
Date: Tue, 03 Feb 2009 10:45:55 -0000

> undefined, it does not seem possible that the wg would advise showing it  

Eh? The tag i= is likely to be completely opaque to any ISP through whom  
the message passes, and hence to the likely Verifiers and Validators.

However, if the Sender has chosen to communicate with the End User, then  
there is an above random probability that their exists some prior  
relationship between them, possibly a quite close relationship. Thus the  
End User is far more likely to be able to make sense of the i= tag, should  
be get to see it, than his ISP who attampted to validate it.

-- 
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: Eliot Lear <[email-masked]>
Date: Tue, 03 Feb 2009 14:07:28 +0100

Dave,

> undefined, it does not seem possible that the wg would advise showing it to an

Further to my earlier message about clarifying the interoperability 
problem, if the above statement is really the case, why not remove i= 
entirely?  We are already rather strongly warned about its use in RFC 
4871.  So, what is its remaining value?

Also, in your new version, you write:

> 8. RFC4871 Section 2.11 Identity Assessor
>
> Original Text:
>     (None. Additional text.)
> Corrected Text:
>     The name of the module that consumes DKIM's primary payload, the 
> responsible Signing Domain Identifier (SDID). It can optionally 
> consume the User Agent Identifier (UAID) value, if provided to the 
> module. The conventions and semantics used by a signer to create and 
> use a specific SDID or UAID are outside the scope of the DKIM Signing 
> specification, as is any use of those conventions and semantics.

I don't understand what the last third sentence has to do with the other 
two.  This looks like a cut and paste error.

Eliot

---

From: Dave CROCKER <[email-masked]>
Date: Tue, 03 Feb 2009 06:50:59 -0800

> two.  This looks like a cut and paste error.

The Identity Assessor consumes the identity information output by DKIM. I added 
the text, here, to remind anyone reading the definition of the IA about a limit 
to its interpretation of that data, within the scope of DKIM.

d/
-- 

   Dave Crocker

---

From: Tony Hansen <[email-masked]>
Date: Tue, 03 Feb 2009 13:29:58 -0500

> 4871.  So, what is its remaining value?

Its utility is outside of DKIM. The DKIM base spec says the value is
opaque. Other specs can expose its structure.

If the signer knows the identity of the user/agent, it can put it in. If
may choose to do so using a variety of schemes, one of which is to use
the user/agent's email address; other mechanisms can also be used. If
there is a way for the signer to communicate to the recipient's system
that it is using a particular mechanism, say through an ADSP record or
other means, the recipient and/or the recipient's system can do further
processing of the message for whitelisting or enhanced display. As an
end user, I'd like to know if the signing system says it's signing the
message on behalf of Aunt Tillie or Uncle George.

> two.  This looks like a cut and paste error.

I agree that SDID should not be listed in that last sentence.

For the UAID, it reinforces the notion that the semantics of the UAID is
opaque per the base spec, and that you need to use knowledge from
outside of the base spec in order to do anything meaningful with the UAID.

	Tony Hansen
	[email-masked]

---

From: Dave CROCKER <[email-masked]>
Date: Tue, 03 Feb 2009 11:47:45 -0800

Folks,

I think this is the second or third suggestion for specific wording changes to 
the Errata draft.

I'm looking for discussion and resolution of each suggestion, so I can fold them 
and and we can put this to bed.

d/

ps. FWIW, my intent in included SDID was that the particular naming scheme is 
outside of DKIM semantics.  So marketing.example.com and hq.example.com, versus 
newsletter.example.org and invoices.example.org are significantly different 
naming schemes, but the semantics behind them is opaque to DKIM semantics and, 
therefore, to the Identity Assessor.

> I agree that SDID should not be listed in that last sentence.
...

-- 

   Dave Crocker

---

From: Douglas Otis <[email-masked]>
Date: Tue, 3 Feb 2009 14:17:56 -0800

On Feb 3, 2009, at 11:47 AM, Dave CROCKER wrote:
>
> ps. FWIW, my intent in included SDID was that the particular naming  
> scheme is outside of DKIM semantics.  So marketing.example.com and  
> hq.example.com, versus newsletter.example.org and  
> invoices.example.org are significantly different naming schemes, but  
> the semantics behind them is opaque to DKIM semantics and,  

I agree with Tony.  The goal of DKIM is to identify domains.

A domain verified as having handled a message is an important  
identifier clearly within DKIM semantics.  The d= value is assured by  
signature verification, whereas the entire i= value is not.  The d=  
value constrains what might be included within the i= parameter.

Even when the i= value is opaque, it may play a critical role in  
limiting the impact of various types of source specific abuse handled  
by the domain.  When done in a consistent fashion, the source may  
remain anonymous, but the identifier itself can be of great value.   
The specifics of handling consistency are unimportant.

When the i= value is not opaque, it may match a From header field  
email-address, but the email-address must be within d= value.  When d=  
big-bank.com, it would be safe to highlight this domain within signed  
headers containing email-addresses within this domain.

As such, the domain identity remains transparent since it relates to  
the introduction of the message into the mail stream.  The i=value,  
even when opaque, might allow the mitigation of source specific abuse  
handled by the domain.  Both values are important, but only the i=  
value could be considered opaque.

-Doug

---

From: John Levine <[email-masked]>
Date: 3 Feb 2009 22:00:44 -0000

>> problem, if the above statement is really the case, why not remove
>> i= entirely?  We are already rather strongly warned about its use
>> in RFC 4871.  So, what is its remaining value?

I wouldn't argue against that, since it seems likely that people will
misimplement i= no matter what we say, but the idea is that it's an
opaque identifier with two uses. One is as an audit key for the
signer; you get back complaints about mail you signed and you can use
it to help figure out what happened.  The other is as a stream key for
the recipient; although the i= is opaque, it should be stable, and you
might want to treat all mail with the same i= in the same way.

> As an end user, I'd like to know if the signing system says it's
> signing the message on behalf of Aunt Tillie or Uncle George.

That's not a bad idea, but it's not DKIM, since DKIM makes no
assertions finer grained than "this domain signed this message".
Something tying the signature to an e-mail address would be a
reasonable extension for a future version.  (I don't think ADSP does
this, since it, among other things, doesn't provide any way to say
that i= is an address without also requiring that it's the From: line
address.)

R's,
John

---

From: Jim Fenton <[email-masked]>
Date: Tue, 03 Feb 2009 15:12:31 -0800

Eliot Lear wrote:

Dave CROCKER wrote:

While i= is currently optional, when it is present its value must meet
certain requirements, that the "domain part" MUST be the same as or
(normally) a subdomain of the d= value.  Removing mention of i= in the
spec would imply that an i= with an arbitrary value could be added,
which would create interoperability problems with current
implementations that enforce the present wording.  I believe that
enforcement was even a part of the interoperability tests some time
back.

Just remember that i= is optional, and leave it at that.

-Jim

---

From: SM <[email-masked]>
Date: Tue, 03 Feb 2009 16:22:53 -0800

>opaque. Other specs can expose its structure.

According to informative note in RFC 4871, the Local-part of the "i=" 
tag is optional
because in some cases a signer may not be able to establish a 
verified individual identity.  That means that it's the Local-part 
which is opaque and not the
domain part of the address.

>therefore, to the Identity Assessor.

That makes the domain part opaque too.  The corrected text in the 
Errata changes the introduction to "permitting a person, role or 
organization that owns the signing domain to claim 
responsibility".  I don't see how anyone can claim responsibility 
when we cannot identify the signing domain.

Regards,
-sm

---

From: Dave CROCKER <[email-masked]>
Date: Wed, 04 Feb 2009 10:58:45 -0800

> domain part of the address.

Not really.

Opaque does not mean that the signer had no intent behind the choices they made 
in doing the encoding.  And in the case of domain name strings, it doesn't mean 
that the recipient side can't know it's a domain name.  It means that they 
cannot know the scheme the signer used for choosing sub-domain names.

> when we cannot identify the signing domain.

There is a difference between being able to use the d= signing domain versus 
having deep knowledge about the underlying intent behind encoding choices for it.

You know my name is David.  You do not know why my parents chose that name, and 
it doesn't matter for your use of it as an identifier.

d/
-- 

   Dave Crocker

---

From: Sean Shen <[email-masked]>
Date: Thu, 05 Feb 2009 11:37:17 +0800

Hi, Dave,
I have a question when reading the 01 version.

In section 14
  " Corrected Text:   Once the signature has been verified, that
      information MUST be conveyed to the Identity Assessor (such as an
      explicit allow/whitelist and reputation system) and/or to the end
      user. "
I don't understand why use "and/or" here. Will eventually be an "and" or an
"or"? Using both  is confusing expecially when there is a "MUST" in this
sentense.
I notice "and/or" is also in 00 version, maybe there were discussions on
this point before in the list but I missed, it so, please  point me to it.

BR

Sean

---

From: Hector Santos <[email-masked]>
Date: Thu, 05 Feb 2009 04:19:43 -0500

> this point before in the list but I missed, it so, please  point me to it.

Good point.  Thank you for highlighting this.

More critical is why is there an enforcement at all, a MUST, to convey 
anything to anyone?

My pet peeve with how DKIM has been introduced, even though 
"reputation" was suppose to be out of scope (wink wink), the key cogs 
ignored that fact and still continued with a subjective "Batteries 
Required" idea, an under and undefined non-standard layer regardless 
of the fact there was a significant group who were against this.

I don't plan to display a "Gold Seal" to users, changing our 
presentations for a # of reason.  I have no control over how the final 
storage will be done.  Once email is transported, the final deposition 
can be a converted, gateway or transformed storage for the end user, 
all depending the installed operation.  We have many operations who 
use the conversion as a security measure to protect used from email 
exploits.

Our initial #1 goal with DKIM is to use it as a filtering process - 
dissemination of the bad vs the good during the transport process. 
Once a signature is verified, nothing else is going to be assumed 
about the trust value of the message.  It just passed another "test."

Now, if some solid standard reputation system (and I mean standard), 
then something can be explored and argumented in the future. It was my 
sincere hope that the policy considerations for the past three years 
with SSP and post-modem SSP (aka ADSP) would assist in this matter as 
another layer to help filter the bad vs the good.

I am not suggesting that other implementations should not do what is 
written to "MUST convey" this information. Thats their judgment. But I 
don't like the idea that it it been enforced when in fact, Reputation 
was suppose to be out of scope.  If it was a solid concept, no sweat. 
But it is far from it, and the last thing I want to do is to display 
erroneous information or false illusions of trust or errors with From: 
vs I= discrepancies issues during presentations, in additional I will 
really hate to be telling customers "DKIM requires extra Batteries" in 
order to work.  Until this is rock solid and completely worked out, 
this simply increases product liability issues.

My opinion of course.

-- 
Sincerely

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

---

From: Dave CROCKER <[email-masked]>
Date: Thu, 05 Feb 2009 07:01:34 -0800

> "or"? Using both  is confusing expecially when there is a "MUST" in this

It's from the RFC, Section 6.3:

      "Once the signature has been verified, that information MUST be conveyed 
to higher-level systems (such as explicit allow/whitelists and reputation 
systems) and/or to the end user."

The goal of the Errata has been only to fix the d=/i= issue and not attack other 
issues with the RFC.

d/
-- 

   Dave Crocker

---

From: Jon Callas <[email-masked]>
Date: Thu, 5 Feb 2009 08:02:42 -0800

> it doesn't matter for your use of it as an identifier.

Let me riff on this for second.

We *don't* know your name is David. We commonly use the identifier  
"Dave" for you, and while it's reasonable to suppose that Dave comes  
from David, we don't know that. If a metaphorical i= has Dave there,  
we can't back-translate to David, error-free.

I mention this because my father's given name is a common nickname. I  
won't bore you with the tale of his immigrant father and  
transliteration of names into the Roman character set, but you get the  
picture.

Like i=, "Dave" is an opaque identifier. One can often peer into the  
opacity and discover that it is translucent, but the process is not  
error-free, and this is why we say in DKIM that it is opaque.

	Jon

---

From: Hector Santos <[email-masked]>
Date: Thu, 05 Feb 2009 13:02:28 -0500

> The goal of the Errata has been only to fix the d=/i= issue and not attack other 

I believe these concern are right on target.  You indicated people are 
confused, even knowledgeable ones.  Well, this is part of the 
confusion with i=.

Before you can enforce a MUST, the d=/i= relationships and usage MUST 
be well defined and understood by everyone - hopefully equally.

What do you mean by MUST?  That a DKIM implementation MUST also 
implement a white list, reputation system, and if you don't, at the 
very least MUST be presented to the user?  How is the MUST employed?

What do you mean by convey - processed by, filtered by a WhiteList , 
Reputation system, but displayed to the USER?

-- 
Sincerely

Hector Santos, CTO

---

From: Jim Fenton <[email-masked]>
Date: Thu, 05 Feb 2009 16:39:38 -0800

> A new version of the Errata draft has been submitted.

I see this as a small improvement over the original, but still have
significant problems with aspects of it that I detailed in my comments
about -00.

The big issue is whether this meets the requirements for an IETF
erratum.  It is very large; I don't know whether an erratum has ever
been processed of this size before.  But my bigger concern is this
sentence from the IESG statement on RFC errata (
http://www.ietf.org/IESG/STATEMENTS/iesg-statement-07-30-2008.txt ):

> Changes that modify the working of a protocol to something that
> might be different from the intended consensus when the document
> was approved should be either Hold for Document Update or
> Rejected.

Your message of February 2 says,
> undefined,

"New consensus" indicates that this might be different from the intended
consensus when the document was approved.

We really need to get this sorted out: whether this qualifies as an
erratum, or whether this discussion should be taking place in the
context of a wider discussion about 4871bis.

-Jim

---

From: Dave CROCKER <[email-masked]>
Date: Thu, 05 Feb 2009 18:36:31 -0800

Jim Fenton wrote:
> erratum.  It is very large;

Jim,

Glad to hear the big issue is procedural.

As for size, I did not find any constraints on size.

>> was approved should be either Hold for Document Update or

Thought we'd established that this isn't doing that.

First, it's resolving ambiguities.  Ambiguities mean there wasn't consensus.

Second, we've had citations to working group Issues that supposedly indicated 
discussion and consensus on this topic, but they turned out to have nothing to 
do with the current concern.  So if you believe there was a clear consensus on 
the matter this Errata draft is attempting to resolve, by all means please do 
cite it specifically.  My own recollection is that this was a matter that did 
not receive discussion or resolution.

> consensus when the document was approved.

I think your logic is a bit faulty, since you left off the other possibility, 
namely that there was no consensus at the time.

> context of a wider discussion about 4871bis.

Jim, you might consider a larger issue:  This effort was started in response to 
a perceived problem.  A problem that was felt to need resolution sooner, rather 
than later.  How are these concerns helpful towards fielding resolution, the 
community can use?

d/
-- 

   Dave Crocker