Subject: [ietf-dkim] Status and direction

From: DKIM Chair <[email-masked]>
Date: Fri, 13 Feb 2009 14:03:09 -0500

Stephen, Pasi, and I have been considering the status and direction of the DKIM 
working group, and we think some clarification and procedural steering is 
important right now.  Here are some thoughts of the chairs, Stephen and me, on 
where we are and what we need to do next.

Recent discussion has brought up the point that, while we had consensus in 4871 
about i=, people do not have the same understanding about exactly what the text 
means.  That's a valid problem that needs to be worked on immediately, and that 
should go into errata.  But here's the thing: the *only* thing that belongs in 
errata in this regard is a clarification of what the *current* 4871 text means -- 
that is, what the consensus really was when 4871 was approved.

It may also be that the working group has decided, or will decide, that i= in 
4871 is *wrong* and should be changed.  If so, that's fine.  But that is *not* 
errata.  We need to separate these two points, that which is errata and that 
which goes beyond that.

ADSP makes use of i=, as specified in 4871.  There see to be two thoughts going 
around related to this that I think are wrong from a procedural point of view (my 
own phrasing, here):

Thought 1: 4871 does not put special meaning onto i=, and ADSP does.  If 4871 is 
clarified to say that i= is an "opaque" string, or some other wording for those 
who don't like "opaque", then ADSP, as written, is in violation of 4871.

This is wrong because ADSP is an extension of 4871 (maybe it should be labelled 
as "updates 4871", actually), and it's perfectly acceptable for it to layer new 
semantics onto what's there, as long as everyone can tell which semantics are in 
effect.  In this case, it's simple: absent advertised ADSP support by the signer, 
the verifier has to take i= without specific meaning; *with* advertised ADSP 
support, i= can be taken to relate to the "from" address.  There's no conflict 
here.

Thought 2: If we're going to change the meaning of i=, that *will* cause problems 
with ADSP, as written, and so ADSP should wait until we've decided what to do 
with i=.

This is wrong because all variants of what's being proposed for i= can be done 
with a new tag.  In fact, it can be done in an extension, without having to 
update 4871 at all.  Given that, ADSP is not in conflict with the new functions 
that are being discussed.

So here's what Stephen and I think we need to do:

1. We need to close on the errata by making updates and clarifications that are 
limited to what's needed to fix the errata.  Any re-thinking about what i= 
*should* be is out of scope for *this* effort.

2. Proceed with ADSP as written, which has rough consensus.

3. Consider any re-thinking of i= as part of a 4871bis effort.  As we do that, 
consider moving significant changes to the concept (such as Suresh's "good@", 
"bad@" idea, and other suggestions) to extensions, as a possible alternative to 
putting them into 4871bis.

4. Aim 4871bis at incorporating what we've learned since 4871.  If that results 
in a document that can and should move to Draft Standard, we'll do that.  If it 
does not, then 4871bis will go to Proposed Standard, and it will take another 
round of work to move up the standards track.

>From a procedural point of view, that is the direction the chairs think we need 
to take.

Therefore, the first thing we have to do, right now, is take care of the errata, 
with clarification, but not change, on the i= issue.

Barry

--
Barry Leiba, DKIM working group chair  ([email-masked])
http://internetmessagingtechnology.org/

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

---

From: Dave CROCKER <[email-masked]>
Date: Fri, 13 Feb 2009 13:56:17 -0800

Barry,

Sorry for being so confused, but I'm hoping you can clear up some questions:

DKIM Chair wrote:
> about i=,

Recent discussion also brought up the point that this assertion was factually 
incorrect and that there is no documentation to substantiate it.  Yet it appears 
to be the foundation of your analysis.

>     We need to separate these two points, that which is errata and that 
> which goes beyond that.
...
> *should* be is out of scope for *this* effort.

      What, specifically, do you believe "goes beyond that" in the Errata draft? 
And what's your basis for believing that?

      What specific changes are you suggesting?

> with ADSP, as written, and so ADSP should wait until we've decided what to do 
...
> 2. Proceed with ADSP as written, which has rough consensus.

      You left out a key, alternative consideration, for ADSP, that it should be 
changed to use d=, rather than i=.  With a clarification of the roles of d= and 
i=, as DKIM signature output, relying on i= by ADSP can reasonably be subject to 
re-evaluation.  Was your omission intentional?

d/

-- 

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

---

From: Douglas Otis <[email-masked]>
Date: Fri, 13 Feb 2009 14:24:46 -0800

On Feb 13, 2009, at 1:56 PM, Dave CROCKER wrote:

> You left out a key, alternative consideration, for ADSP, that it  
> should be changed to use d=, rather than i=.  With a clarification  
> of the roles of d= and i=, as DKIM signature output, relying on i=  
> by ADSP can reasonably be subject to re-evaluation.  Was your  
> omission intentional?

May I add--

Changing ADSP to use d= rather than i= restores single signature  
compatibility with RFC 4871.  :^)

Asserting by errata or some related document that valid and token  
namespace that overlap within the same message is a violation of RFC  
4871,  would also establish the relationship intended by ADSP without  
also mandating email-address affirmation.

Whether the i= namespace represents a valid address could be deduced  
by discovering that the i= value matches with an email-address within  
a signed header field.  Having an i= relationship with valid email- 
addresses conditioned upon the existence of some DNS record makes  
processing clumsy, and removes non-repudiation.

-Doug

---

From: Jon Callas <[email-masked]>
Date: Fri, 13 Feb 2009 16:03:36 -0800

Barry,

I think that we're dealing with a false dichotomy between a straw man  
and beating a dead horse with a red herring.

4871 is in my opinion as an author clear about i=. You have but to  
read it and the informative notes. One might think it's amorphous, but  
it's at least an explicit amorphousness. It survived a rough  
consensus, at least implicitly. I will summarize 4871 as "signers can  
do whatever makes sense to them, receivers have to live with that." If  
Aleister Crowley were around, he would have said that the law around  
i= is "do what thou wilt."

There's nothing wrong with a bunch of people saying, "Hey, if we all  
define i= to have format FOO, then we get benefit BAR" and then doing  
that. That includes using i= as a signaling mechanism to the receiver.  
However, that agreement is closer to BCP than to a mandate, because  
4871 intentionally says what it says. There's nothing wrong with ASDP  
or anyone else deciding to do what they want, because that's what 4871  
says! Do what you want. But that is a practice, not a mandate.

However, this completely ignores the most important feature of 4871:  
you can sign any header you want. If ADSP or anyone else wants the  
force of mandate, it is better and simpler to create a new header and  
sign that. Let me suggest that you could introduce a "DKIM-I" line,  
put whatever ADSP wants in it, sign that, and Bob's your uncle. You're  
done.

There is utterly no reason to create a 4871bis to redefine i=. It's a  
waste of everyone's time. The correct answer is to expand the protocol  
through the defined expansion mechanism! If people don't like a signed  
header, then make a new DKIM-Signature Header Field (c.f. section 3.5  
of 4871). I suggest picking "y=". My reasons are that "y" is known  
sometimes as a "Greek i" and "y not?" All ADSP needs to do for this  
one is a simple global-search-and-replace of "i=" to "y=" and Alice is  
your auntie. You're done.

This same principle holds for other people who aren't happy with the  
precise semantics of i=, d=, g=, or anything else. Make a header and  
sign it, or stick a new field into the DKIM header. It's *that*  
*simple*!

If we want to clarify the i= semantics in errata, sure. Whatever. But  
all the people who want i= to be something it isn't are much better  
served by making what they want than by trying to pretend that i= is  
the same shape as the peg they are holding in their hand. It isn't.  
Make a new hole to fit that peg, and we will all be much happier.

	Jon

---

From: John Levine <[email-masked]>
Date: 14 Feb 2009 00:35:17 -0000

>Therefore, the first thing we have to do, right now, is take care of the
>errata, with clarification, but not change, on the i= issue.

Dave's draft clarifies the meaning and use of i=.  It's time for a last
call on it.

R's,
John

---

From: DKIM Chair <[email-masked]>
Date: Sat, 14 Feb 2009 00:42:19 -0500

Responding to Dave's, Doug's, and John's replies (I'll get to Jon's later)...

Dave says...
>> Recent discussion has brought up the point that, while we had consensus in
>> 4871  about i=,
>
> incorrect and that there is no documentation to substantiate it.  Yet it
> appears to be the foundation of your analysis.

It's not factually incorrect, but I think you misunderstand it.  The 
documentation to substantiate it is that RFC 4871 went through working-group last 
call, IETF last call, and IESG processing with the text that's there.  What we 
see now, though, is that not everyone had/has the same understanding of what that 
text meant.

Anyway, Dave, I think we're just talking about semantics, here; see below.

Dave says...
>> 1. We need to close on the errata by making updates and clarifications that
>> are  limited to what's needed to fix the errata.  Any re-thinking about what
>> i=  *should* be is out of scope for *this* effort.
>
>       What, specifically, do you believe "goes beyond that" in the Errata
> draft? And what's your basis for believing that?
>

I'm not suggesting that there's anything wrong with the errata draft.

I'm addressing the extended discussion of i=, and what it could be and what it 
might be, and I'm saying that the chairs are setting a boundary here: any change 
to how i= is used is beyond the scope of errata (and into the scope of Jon's 
comment).

I never said that the errata draft crosses that boundary; I think it does not.

Dave says...
>> Thought 2: If we're going to change the meaning of i=, that *will* cause
>> problems  with ADSP, as written, and so ADSP should wait until we've decided
>> what to do  with i=.
> ...
>       You left out a key, alternative consideration, for ADSP, that it should
> be changed to use d=, rather than i=.  With a clarification of the roles of d=
> and i=, as DKIM signature output, relying on i= by ADSP can reasonably be
> subject to re-evaluation.  Was your omission intentional?

Doug says...

> Changing ADSP to use d= rather than i= restores single signature compatibility
> with RFC 4871.  :^)

My omission was not intentional.

Yes, I think that given the recent discussion, it's quite fair to see if the 
working group wants to re-open that issue in ADSP before we go forward with it.

John says...
> Dave's draft clarifies the meaning and use of i=.  It's time for a last

Stephen was planning to do that on Monday.  I wanted to get the "status and 
direction" message out first.

I think we're all actually in agreement here.

Barry

---

From: DKIM Chair <[email-masked]>
Date: Sat, 14 Feb 2009 00:47:28 -0500

Jon says...
> 4871 is in my opinion as an author clear about i=. You have but to read it and
> the informative notes. One might think it's amorphous, but it's at least an
> explicit amorphousness. It survived a rough consensus, at least implicitly. I
> will summarize 4871 as "signers can do whatever makes sense to them, receivers
> have to live with that." If Aleister Crowley were around, he would have said
> that the law around i= is "do what thou wilt."

Do you think that the text in Dave's errata draft keeps that sense, whether or 
not you think it provides useful clarification?

Do you think that the text in Dave's errata draft provides useful clarification?

Do you object to the text in Dave's errata draft?

Jon says, along with the rest of the note...
> This same principle holds for other people who aren't happy with the precise
> semantics of i=, d=, g=, or anything else. Make a header and sign it, or stick
> a new field into the DKIM header. It's *that* *simple*!
>
> If we want to clarify the i= semantics in errata, sure. Whatever. But all the
> people who want i= to be something it isn't are much better served by making
> what they want than by trying to pretend that i= is the same shape as the peg
> they are holding in their hand. It isn't. Make a new hole to fit that peg, and
> we will all be much happier.

I think that's exactly what I said in my points 3 and 4, including the part (in 
point 3) about pushing such changes into extensions, rather than twiddling with 
i=.

Again, it sounds like we're in agreement, here, on how to proceed.

Barry

---

From: Dave CROCKER <[email-masked]>
Date: Fri, 13 Feb 2009 22:40:59 -0800

DKIM Chair wrote:
> Stephen was planning to do that on Monday.  

thanks for clarifying that.

d/
-- 

   Dave Crocker

---

From: Jon Callas <[email-masked]>
Date: Sat, 14 Feb 2009 12:33:26 -0800

On Feb 13, 2009, at 9:47 PM, DKIM Chair wrote:

>> read it and

Let me say first that I am a firm believer that if people are having  
trouble understanding something, then it's not clear. It needs to be  
re-explained.

I'm an author, and I have no trouble understanding it. Any fault I  
must bear is in the communication end, not the understanding end.

Yes, I think the errata makes sense. I *hope* it provides a useful  
clarification, but I'm not the one to ask. I'm partially responsible  
for the existing not-entirely-clear text. You have to ask someone else  
about that. I think it explains it better, but I understood the first  
one. Lastly, no, I don't object to the text. I think we should pass it  
and move on.

> Again, it sounds like we're in agreement, here, on how to proceed.

I hope so. I think that a 4871bis document will do no good. I think  
that if ADSP wants to use i=, it needs to accept the way i= is, or use  
a new tag that is what it is -- or use d=. I don't care which. I think  
it's useful either way, myself.

I hope we agree, but this whole discussion is about things that are  
clear to me.

	Jon

---

From: <[email-masked]>
Date: Sun, 15 Feb 2009 16:03:06 -0500

+1

Bill Oxley
Messaging Engineer
Cox Communications, Inc
404-847-6397

-----Original Message-----
From: [email-masked] on behalf of Jon Callas
Sent: Fri 2/13/2009 7:03 PM
To: DKIM Chair
Cc: DKIM Mailing List
Subject: Re: [ietf-dkim] Status and direction

Barry,

	Jon