Folks,
Summary of the reactions posted so far...[1]
Some of the postings asked questions or expressed confusion about some
procedural or technical or wg scope "fact" issues that have already been
answered; so they are not covered here. Also, there might be some relatively
minor points that I've skipped, for simplicity in this summary. That doesn't
mean they should be ignored, merely that my own reading classes them as outside
of the critical path for the current question of whether to do a documentation
split.
For background, here's a baseline summary of the vector the working group is
/already/ on:
1. DKIM will have a new RFC number.
2. DKIM currently covers more than one RFC:
The original one and the update.
3. Documentation changes are already being made.
None of these threaten the progression of DKIM to Draft. Quite the opposite.
As for issues raised on the list...
[[ Might disrupt DKIM or its status ]]
getting closure on DKIM is tantalizingly close.
after all these years, now redefining what DKIM is, will certainly not help
acceptance
A reorganization of 4871bis into two documents is inconsistent with the
"first priority" requirement of the charter.
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.
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?
1. There is a presumption that DKIM is somehow suffering by being at Proposed
rather than Draft or that Draft represents "closure". Let's remember that there
is a standards step above Draft. Draft is nice, but not the end of the line (as
of now.) If there is adoption that is being delayed because the specification
is not at Draft, folks should document that. If folks believe that achieving
Draft status is going to make a significant difference in DKIM use, what is it,
and what is the basis for believing it will happen?
2. The premise and requirement in proposing to do the document split is that it
will not change the syntax or semantics of DKIM at all. To the extent that
folks fear this might not be achieved, that ought to hinge on a review of the
changes.
3. The relevant wg charter item is "1. Advance the base DKIM protocol (RFC 4871)
to Draft Standard." We have preliminary feedback from the ADs that doing the
documentation split will not be threatened.
4. Documentation changes are permissible when moving from Proposed to Draft. The
limitation is that features must not be /added/. So, the sensitivity is with
technical changes and none are being proposed.
[[ Might disrupt DKIM adoption ]]
(Per the above discussion disrupting DKIM, itself, certainly would hurt DKIM
adoption, so the segment here implicitly includes everything from the segment
above.)
(In response to: “marketing” of DKIM can be managed") this may be true for
the US, I'm not sure about other regions of the world.
A number of folk are concerned that this proposed change will make DKIM /look/
unstable. Instability is always an important concern.
However the proposal does not change the technical specification and therefore
introduces no instability. For one thing, as noted:
I think the “marketing” of DKIM can be managed and maintained as it has its
own momentum now
But the deeper point was noted:
We'd still have DKIM, it'd still be called DKIM, and (I assume) it'd still
be in a document called DomainKeys Identified Mail (DKIM) Signatures.
Take a look at the "background" bulleted list at the beginning of this message.
We are already making changes. The proposal stays within the scope of that
list.
In particular:
There will be a DKIM spec with the same name but a different RFC number.
It will have the same (corrected) syntax and semantics.
Market resistance to changed specifications comes from changing the /technical/
details, not changes to documentation -- particularly when the changes to
documentation /improve/ clarity, and an exercise like the one being proposed
usually does make things clearer.
Because it happens some time after the initial specification, there is better
understanding of the details in the specification. There also is an opportunity
to audit the text and move things into a better sequence, as well as removing
redundancies (such as defining the same ABNF rule more than once...)
[[ Bad Timing / Too late ]]
it's too late to make this split
the train has left the station.
I consider it unfortunate that the WG had to spend time to go through WGLC
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.
This is a working group that has a pattern of resisting most change and of
having a very difficult time in even talking about change. From one
perspective, that's good because it tends towards stability. On the other hand,
it also means that it's difficult to pursue improvements.
So while I too wish this proposal had come up sooner, the group's track record
makes it unlikely that that would have made much difference. More importantly,
I don't think we had enough understanding of DKIM as a technology nor of other,
possible uses for the core technology.
There are arguments against change that are based on a cost/benefit analysis.
These are considered elsewhere in the note. The objections in the set here are
less anchored and offer their conclusion without providing a basis. To the
extent that anyone really wants the decision to rely on "it's too late" or the
like, they should provide a pragmatic basis that incorporates the various points
already offered which explain why it is /not/ too late.
As for this happening after working group last call, I'll repeat that any new
draft must and will incorporate the changes mandated by comments from the last
call. The Last Call was most definitely not wasted.
[[ How will things be related? ]]
If the split goes as planned, then the signature for the FOOBAR protocol
will be "FOOBAR-Signature", although its internal structure and many/most of
its tags will be the same.
That is, what exactly will be shared and what will be different? For the
direction the current split has taken, there appear to be multiple answers:
1. A set of algorithms and conventions will be shared.
2. The DNS key record can be shared and probably should be.
3. For authentication uses, it's unlikely that the DKIM-Signature header field
should be shared, because it is an explicit flag for specific DKIM semantics,
including the "meaning" of a signature. Any other signature scheme is going to
have different semantics and will need a different flag for indicating it.
That said, one could imagine an authentication a scheme that is layered on
top of DKIM, not just on top of DOSETA, and ADDS a header field, rather than
replacing DKIM-Signature.
A basic "architecture" would be:
+--------+ +-----------------+
| DKIM | | Message Privacy |
+---+----+ +--------+--------+
| |
+-----V---------------------------+ |
| Header/Content Signing Template | |
+----------------+----------------+ |
| |
...................V.................................V.............
. D O S E T A L I B R A R Y .
.+------------------+ +------------+ +-------------+ +-----------+.
.| | | Key | | Common | | Signature |.
.| Canonicalization | | Management | | Parameters | | Header |.
.| | | (DNS) | | (tab=value) | | |.
.+------------------+ +------------+ +-------------+ +-----------+.
...................................................................
[[ Competing with SSL ]]
is a goal here to provide an alternative to SSL-based web page security?
certifying HTTP messages is not the same as SSL signing web pages
There is a long history with different lines of work on channel- vs. object-
based security. DKIM, OpenPGP and S/MIME are object-based. SSL is
channel-based. The current proposal was not based on any thinking concerning
channel mechanisms.
(Also, note that SSL technology has nothing to do with the web or web pages, per
say. The web is merely one of the 'customers' of SSL. SSL provides a variety
of possible protections on a channel and is independent of the content on that
channel. It certainly has nothing to do with "pages".)
[[ Documentation, Reference, Authority or Goal Confusion ]]
does the split make the individual docs potentially beholden to multiple
masters...
won't the split encourage DOSETA participation (and possibly others) who
necessarily have different perspectives and goals?
First note that this working group is already pretty darn diverse in goals and
styles, which is one of the reasons it has so much trouble making progress.
I suppose that it's possible that adding others will make things more
contentious but mostly I don't know what this means in practise.
Actually, this seems a bit like saying that MIME was intended for email and that
any effort to apply it to the Web should be pursued separately.
Oh, wait. That's what happened, and it's been problematic.
Since we have that reality to compare against, I'll strongly suggest its main
lesson is that we should not want to replicate it.
[[ Parallel specifications are acceptable ]]
finish and publish rfc4871bis as a standalone document, and after that do
the DOSETA document that, as I understand it, pulls out components of DKIM
and defines interfaces to them as a toolkit.
There will be some overlap, but I don't see that as a huge problem.
Some folks are quite casual about redundant specification. I find that it
almost always causes problems in the long run. The details diverge and code
stops being shared. Discussion gets confused ("which version are you talking
about?") When a single specification can be shared among services, it should
be. The benefits tend to be fundamental.
finish our current work, sans document split. DK and DKIM were two parallel
specifications for a bit. I don't think there was any harm in that.
I think a good response to this was:
it'd be far more annoying in the long run to create DOSETA as something
entirely parallel to DKIM, and have DKIM not reference it -- in other words,
two nearly-identical parallel specifications.
the idea of creating a new technology (say, something that protects HTTP
transactions) that looks 95% like DKIM but is
called something else seems to me to be a path that would introduce even
more confusion to the industry.
There will be a DOSETA specification. If it gets used by other services and
DKIM does not share it, there will be divergent details about the core
technology. That almost always causes problems.
[[ Security ]]
Other uses of DKIM need to be examined carefully to make sure that we do not
depend on an insufficiently secure key infrastructure.
Of course. In fact, it's a tautology for new security work.
However it does not seem to have anything to do with the efficacy of the
proposed split. It is merely an added, inherent requirement for any work that
chooses to use the result.
[[ Benefits ]]
As I see it, if we look at the DKIM key components, they consist of the
following:
** Detaching the transport from the packaging.
** Retaining of signatures in the DNS, as opposed to a CA.
** Separation of meta-data (we call them headers) and content (we call that
body).
That strikes me as a pretty good summary. It's possible to add a bit more, but
this is a good start.
We'd also have a new thing, DOSETA, which we could (quite accurately) point
to as another example of the rightness of the original DKIM approach. And
when DOSETA is used to add an authentication layer to other technologies,
the proponents can approach the political layer by calling it "DKIM for
foo," immediately gaining a positive comparison.
But the main reason I like the approach Barry and Dave have been describing
is that it gives us a way to take all this effort -- both technical and
political -- and apply it to other forms of messaging.
The concept of building a toolkit as a basis, to which you add a few plugins
to get DKIM or a few different ones to get something similar for a different
medium, is quite appealing.
But how much leverage is this likely to really provide?
how many messaging/transaction type protocols will be real candidates to do
something with DKIM/DOSETA?
An inventory of candidate protocols that really may profit from something
like DOSETA
There have already been a number of potential 'consumers' cited for DOSETA,
including IM, SIP, Web pages, and netnews.
A related effort that is getting underway also demonstrates interest in things
of this type:
<https://www.ietf.org/mailman/listinfo/keyassure>
There is a view that broad adoption of Internet security services has been
seriously hampered by requirements for formal Certificate Authorities and
certificates.
The DKIM core mechanism obviates that requirement by using the presence of the
DNS record to achieve "self certification". There is an emerging view that
quite a few services would find that sufficient.
d/
[1] On the average, even when I am especially diligent, my efforts at auditing
the details of something is highly error-prone. That's never intentional. So
if I've missed or mis-classified a point, just say so and we can correct it.
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html