Subject: [ietf-dkim] Splitting the DKIM base doc

From: Barry Leiba <[email-masked]>
Date: Fri, 24 Mar 2006 19:34:43 -0500

Dave brought up, at the Monday DKIM IETF session, the idea of splitting
out the key-discovery parts from the base document.  I've recently come
up with a need to have the canonicalization be separately referenced.
I'm throwing this out to the mailing list for discussion:

Should we split the DKIM base doc into independent modules?  I believe
Dave has a specific idea that he might share with us... Dave?

Barry

--
Barry Leiba, Pervasive Computing Technology  ([email-masked])
http://www.research.ibm.com/people/l/leiba
http://www.research.ibm.com/spam

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

---

From: Dave Crocker <[email-masked]>
Date: Sat, 25 Mar 2006 08:28:13 -0800

> Dave has a specific idea that he might share with us... Dave?

I'm working on a proposal.  Couple of items ahead, in my queue.  Soon.

d/

-- 

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

---

From: Stephen Farrell <[email-masked]>
Date: Sat, 25 Mar 2006 16:34:34 +0000

> I'm throwing this out to the mailing list for discussion:

Good idea to resolve this now.

The only thing I'd add is to ask folks to also bear in mind
our charter [1] deadlines when suggesting new document
structures. The next milestone should be WG last call on
base in May, so if your suggestion is likely to cause that
date to slip, I guess it'd be good to include a justification
for that.

Cheers,
Stephen.

[1] http://www.ietf.org/html.charters/dkim-charter.html

---

From: Barry Leiba <[email-masked]>
Date: Sat, 25 Mar 2006 12:09:16 -0500

> The next milestone should be WG last call on

Good point, of course.  Dave and I babbled briefly at each other about 
this recently, and I think a split makes sense -- the benefit is keeping 
the independent elements isolated, allowing
1. components that can be referenced separately (and can reference each 
other, and
2. components that can be added or replaced as necessary; this is 
particularly useful for things like "how do I canonicalize the message", 
"how to I get the signing key", and "how do I encrypt/decrypt" (that 
last is already split out, by reference to RSA and SHA-x).

I think the work of splitting it will be small, and won't affect the 
schedule, but I'll let Eric, et al, make that ultimate judgement.  My 
inclination is to give the document editor a veto option on it, to avoid 
schedule problems.  On the other hand, I think getting the document 
structure right is important.

Barry

---

From: Dave Crocker <[email-masked]>
Date: Sat, 25 Mar 2006 11:02:19 -0800

Barry Leiba wrote:
> schedule,

Given what Eric said he planned to do, with respect to the base document's 
discussion and reference to the key service, I agree.

If I understood correctly the change he is planning will a) contain only and 
exactly what is essential to specify the base document's functional requirement, 
and therefore b) de-couple a key service specification from the critical path of 
the base document.

Here is a revision to the architecture diagram that went into the threats 
document. It attempts to identify the standardized components and their inputs 
and output.  I think it is sufficient for the current discussion, to decide 
which parts need to be in separate documents.

For reducing dependencies in the critical path, a specification of interface 
parameters, rather than for a specific document, ought to suffice.

The diagram is still quite rough and I suspect it contains errors.  So, please 
send me corrections and enhancement.

                                            |
                                            | - RFC2822 Message
                                            V
                          +=======================================+
                          |      ORIGINATING OR RELAYING ADMD     |
                          |                                       |
    ......................+  Canonicalize  (Header, Body, c-alg)  |
    .         ............+  Hash (c-Header, c-Body, h-alg)       |
    .         .        ...+  Sign (h-Header, h-body,              |
    .         .        .  |       Domain, Selector, Priv-Key)     |
    .         .        .  |                                       |
    .         .        .  +=================+=====================+
    .         .        V                    | - Message
    .         .   +------------------+      |   (Domain, Selector, Key)
    .         .   | Canonicalization |      |
    .         .   |    Algorithm     |      |
    .         .   +----+-------------+      |
    .         V        .                    |
    .  +-----------+   .                    |
    .  |   Hash    |   .                    |
    .  | Algorithm |   .                [Internet]
    .  +------+----+   .                    |
    V         .        .                    |
+---------+  .        .                    |
|   Key   |  .        .                    |
| Service |  .        .                    |
+--+------+  .        .                    |
    .         .        .                    V
    .         .        .  +=======================================+
    .         .        .  |      RELAYING OR DELIVERING ADMD      |
    .         .        .  |                                       |
    .         .        ..>|  Canonicalize (Header, Body, c-alg)   |
    .         ...........>|  Hash (c-Header, c-Body, h-alg)       |
    .....................>|  Verify (h-Header, h-body,            |
                          |          Domain, Selector, Pub-Key)   |
                          |                                       |
                          +=======================================+
                                            |  - Verified Domain
                                            V  - [Report]
+-----------+            +=======================================+
|  Signer   |            |                                       |
| Practises +...........>|         Signer Evaluation             |
|  Query    |            |                                       |
+-----------+            +=======================================+

-- 

Dave Crocker

---

From: Michael Thomas <[email-masked]>
Date: Sat, 25 Mar 2006 11:17:22 -0800

> date to slip, I guess it'd be good to include a justification

A split is guaranteed to cause that date to slip, fullstop.

As I've said, from a developer's standpoint, multiple documents
suck.  But here's what I don't understand: if we split the documents,
we will have to submit all of the former parts of -base as a bundle
since they will necessarily have cross normative references.  And
even if we could, a -base document that doesn't define, say, the
query mechanism and/or the contents of the RR would be completely
pointless -- and an invitation for people just winging it.

Please let's not go here.

       Mike

---

From: Eliot Lear <[email-masked]>
Date: Sun, 26 Mar 2006 02:28:12 -0600

> pointless -- and an invitation for people just winging it. 

I heartily agree with Mike on this one.  I think a split of the base
document along the lines discussed in the WG is a HUGE mistake.  The
purported reasoning for the split at the meeting was to carve out the
DNS RR.  Without this information defined the spec is useless, which
means that the base spec would have to gate on the RR definition
*anyway*.  Hence, if we are going to define an RR (and we should) we
have two choices:

    * define it now, include it in the base spec and be done with it; or
    * define it later and expect that the next RFC will be classed an
      update to the standard.

Eliot

---

From: Dave Crocker <[email-masked]>
Date: Sun, 26 Mar 2006 10:45:39 -0800

Folks,

>> structures. ...

Although we certainly need to pay attention to impact on the schedule, the 
amount of impact is significant.

Given how many months it took to get this working group chartered, and how much 
time we have had to spend on the threats document, the idea that we would be 
concerned about a very minor slippage would be rather strange, if that slippage 
buys some strategic advantage.  Yes, that is a big "if".

Partitioning of documents is considerably more than a bookkeeping exercise in 
abstract aesthetics.  It has a fundamental impact on clarity and schedule, and 
often produces components of specification that are far more crisp.

It also permits being much more clear about critical dependencies and often can 
permit reducing them, for any initial deliverables of basic utility.  It permits 
deferring complex or secondary topics, taking them out of the critical path for 
initial utility.

Too few documents is at least as bad as too many.  I actually suspect that it is 
worse, given how bogged-down larger, more complex documents tend to get.  As we 
have already seen, a particular challenge for a diverse group trying to specify 
an "interesting" system, is focus.  Larger, more complex documents tend to 
encourage distraction and lack of discussion focus.

d/
-- 

Dave Crocker

---

From: Michael Thomas <[email-masked]>
Date: Sun, 26 Mar 2006 17:00:06 -0800

Dave Crocker wrote:

> Although we certainly need to pay attention to impact on the schedule, 
> the amount of impact is significant.

Uh, boy do I agree...

> Partitioning of documents is considerably more than a bookkeeping 
> exercise in abstract aesthetics.  It has a fundamental impact on 
> clarity and schedule, and often produces components of specification 
> that are far more crisp.

Crisp for _whom_? Developers? No. The casual dilitante? No -- short
attention span. Who is this crisp for?

I'm really having a hard time understanding why we're so intent on snatching
defeat from the jaws of victory.

          Mike

---

From: Arvel Hathcock <[email-masked]>
Date: Mon, 27 Mar 2006 08:57:41 -0600

> I'm really having a hard time understanding why we're so intent on
 > snatching defeat from the jaws of victory.

Mike's comment above got me thinking on this.  Aren't we very close as a 
WG to resolving all known issues with -base now without this split?  If 
so, why introduce such a change if there's no large faction amongst us 
calling for it?

As an implementor, I agree with Mike that when and where possible, the 
fewer documents, the better.  I'm also a little worried that the DKIM 
specification might become a library of cross-referencing documents all 
of which depend upon the others which begs the question of why they 
aren't/weren't in the same specification to begin with.

My own view is that if DNS is a mandatory mechanism, if 'simple' and 
'relaxed' are manditory mechanisms, they ought to be included in the 
-base spec so that an implementor has everything necessary in a single 
source.  Other mechanisms currently optional or to be determined in the 
future should be specified elsewhere.

Naturally, I will go with the flow on this topic but I just wanted to 
get my own view out in the open.

-- 
Arvel

---

From: Arvel Hathcock <[email-masked]>
Date: Mon, 27 Mar 2006 15:53:46 -0600

The following point is against splitting the document:

(a) Less convenient for implementors and those who need to reference the 
documents

The following points are in favor of splitting the document:

(a) It can help speed up the "process" by deferring controversial topics 
for later
(b) It has the benefit of allowing easier revision in the future

I lack the experience with which to judge whether these benefits should 
trump the "single document makes life easy" implementor preference. 
This is my first time through the process.  My guess is that if 
sufficient Elders think this is the way to go I should defer and am 
prepared to do so.

I would just like an understanding of one thing first:  We've argued in 
the past that base can and should describe and provide a basic unit of 
utility.  Does a split to more documents rob base of that and do we care?

-- 
Arvel

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 27 Mar 2006 14:32:57 -0800

At 3:53 PM -0600 3/27/06, Arvel Hathcock wrote:
>(a) Less convenient for implementors and those who need to reference 
>the documents
>
>(a) It can help speed up the "process" by deferring controversial 
>topics for later

There are costs and benefits for both sides, of course.

The WG should *not* want to speed up getting the normative base spec 
out by deferring controversial topics to the non-normative overview. 
This is a recipe for disaster, one that has been seen in many other 
IETF WGs. We will end up arguing about what we "meant", and what we 
"should have meant", and thereby greatly delay the document that will 
be of most use to users of the protocol (as compared to the 
implementers).

As I said at the mic last week, I think we should have a single 
document that contains the protocol and the discussion around it. 
That document does *not* have to contain deployment ideas (such as 
Appendix B) or suggestions for signer and verifier policies, but 
should be good enough for a developer and an early deployer to create 
an interoperable implementation by reading the document.
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Dave Crocker <[email-masked]>
Date: Mon, 27 Mar 2006 14:50:36 -0800

Paul,

> The WG should *not* want to speed up getting the normative base spec out 
> by deferring controversial topics to the non-normative overview.

Who suggested this course of action?

> As I said at the mic last week, I think we should have a single document 
> that contains the protocol and the discussion around it. That document 
> does *not* have to contain deployment ideas (such as Appendix B) or 
> suggestions for signer and verifier policies, but should be good enough 
> for a developer and an early deployer to create an interoperable 
> implementation by reading the document.

Paul, could you cite some examples of such fully-integrated IETF specifications 
for systems that have gained widespread adoption and use?

Please indicate how long it took to gain standardization and deployment, and 
what the effort was to produce later revisions.

d/
-- 

Dave Crocker