ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] Re-thinking the organization of the DKIM spec

2011-01-10 21:12:30
Oh, good. I'm not the only party pooper. To what Jim wrote, I'll
add:

1) As a developer, multiple documents generally suck. IKE,
     ISAKMP, and their friends. Need I say more?
2) Frameworks almost invariably fail, and that's what I sense
     here. We gave some passing thought to making this usable
     in other contexts, and heck I even wrote a SIP/DKIM signer
     to tweak Fluffy's nose about sip-identity, but the reality
     is that actually getting refactoring done in a way that
     wouldn't ultimately require a new spin of one or more
     documents is, IMO, close to hopeless.
3) Differing document maturity levels. You have one that's
     advancing to draft, and one that one day may be PS. It just
     doesn't seem reasonable to have those two be linked even
     weakly.

I really don't see what the problem would be to take what
we did and just insert it as a whole and then start editing.
If this second use had come a couple three years ago, it
might have been worth considering to rationalize things, but
given how far along we are this is just setting up to be a
big fail.

Mike

On 01/10/2011 05:28 PM, Jim Fenton wrote:
On 1/7/11 12:37 PM, Barry Leiba wrote:
   
As the 4871bis editors worked on resolving the last sets of comments
in the 4871bis document, the chairs and the editors had some
discussion about other efforts that are interested in re-using
portions of the DKIM signing/verifying/key-distribution mechanism
outside the email context.  See, for example,
http://tools.ietf.org/html/draft-desruisseaux-ischedule.  This would
mean using a DKIM-like mechanism to secure the distribution of
scheduling events.  That effort is currently referencing (and
updating) RFC 4871, but that includes what for them are many
irrelevant and inappropriate details that have to do with email.

One way we can handle this and other use cases, as we move the DKIM
specification along, is to split the specification into two documents,
one that describes the underlying components, and a second that
describes the email-specific bits.
     
I'm quite unhappy with the proposal to split RFC4871, for a number of
reasons (in no particular order):

1. Review Abuse:  We held a Last Call on rfc4871bis that closed on 22
October 2010.  Many of us put considerable focus into a detailed edit of
the document at that time, and to hear that other than surgical changes
to the document in response to Last Call comments is an abuse of many
peoples' time, and not just mine.  The cited other usage of DKIM
signatures, iSchedule, was published in March 2010 so it should have not
been the gating factor.

2. Charter: The DKIM WG charter states "1. Advance the base DKIM
protocol (RFC 4871) to Draft Standard.
This is the first priority for the working group."  A reorganization of
4871bis into two documents is inconsistent with the "first priority"
requirement of the charter.

3. Risk:  The amount of violence that will need to be done to the text
of RFC4871 introduces significant risk that the specifications will be
unclear or inconsistent with 4871.  While the rules for advancing to
Draft do refer to specifications and not documents, I would be
uncomfortable with doing anything other than recycling at Proposed to
see if errata, etc. result from the changes.  But recycling at Proposed
is inconsistent with the charter.

4. Usage:  DKIM has quite a bit that is tailored specifically for mail:
the syntax of the header field, canonicalization, etc.  The proposed
split includes canonicalization as part of DOSETA, and wonder if that
really makes sense.  While the syntax of a DKIM signature may be close
to what's required for iSchedule, will we next need to consider yet
another split to permit signatures to be expressed in JSON, XML, or
other formats?  Are there other uses considered besides iSchedule at
this time?

5. Security properties:  DKIM was designed to provide a modest level of
security limited by the security properties of DNS.  This was considered
acceptable because it's comparable to the level of security afforded
message routing (since MX records could be spoofed).  Other uses of DKIM
need to be examined carefully to make sure that we do not depend on an
insufficiently secure key infrastructure.  While use of DNSSEC mitigates
this, I'm concerned about whether it will really be used everywhere needed.

6. Redundancy: Section 10.1 of the iSchedule draft requires the use of
TLS for all transactions.  Why is DKIM then also needed (if the
certificate verification happens in both directions, of course)?  Why
are two very different mechanisms in use?

7. Openness and Timeliness: Barry has apologized for not announcing this
a month ago, but I sense that this has been going on in a private design
team longer than that.  BCP 9 section 1.2 talks to openness and
timeliness; this fails on both accounts.

-Jim

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

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

<Prev in Thread] Current Thread [Next in Thread>