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

From: Dave CROCKER <[email-masked]>
Date: Thu, 13 Jan 2011 09:10:01 -0800

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

---

From: Douglas Otis <[email-masked]>
Date: Thu, 13 Jan 2011 10:27:20 -0800

>      3.  Documentation changes are already being made.
Dave,

Sorry for being slow to comment.  Benefits obtained from reuse of DKIM 
components would be through the leveraging of existing code.  However, 
very soon DANE will offer code having better security in generalized 
form.  Consensus about verification results reflecting whether the 
underlying format is invalid and able to produce misleading results 
becomes less likely for DKIM, in conjunction with efforts to further 
generalize verifications.

While DKIM is a good mechanism at preventing false positive detections 
of phishing attempts, an inability to hold a source accountable for 
specific destinations makes it unsuitable for playing a meaningful role 
in establishing spam specific reputations.  This too suggests DANE will 
likely play a greater role over time.

Promoting the third-party authorization scheme was an effort to improve 
DKIM's deliver-ability and did so by then depending upon client 
authentication methods absent from DKIM.  As use of v6 becomes a greater 
consideration, IP addresses will not offer an identifier suitable for 
policy enforcement, where again DANE is more likely able to fill that 
gap.  DANE has not yet closed the door, but it will very soon.

When used as a basis for acceptance, DKIM comes too late in the 
exchange, where again DANE will also likely play a greater role.  
Perhaps when email acceptance is based upon authenticated domain 
sources, the need to "introduce" third-party domains will become more 
apparent.  Nevertheless, TPA, and something like DANE, whether it 
leverages DKIM or not, is where email needs to head.

-Doug

---

From: Barry Leiba <[email-masked]>
Date: Thu, 13 Jan 2011 14:48:14 -0500

The chairs are happy with how this discussion has been going so far,
except that we remind people that discussion of any details of
iSchedule or any other protocol that might cite DKIM is entirely out
of scope -- we need to accept that people want to use parts of the
DKIM mechanism, and not, at this point, criticise their design.

We'll let the discussion go through the end of next week -- let's say,
through the end of the day on Thursday, 20 Jan -- and then we'll make
a consensus call.  Between now and then, please continue to discuss
specifically the idea of whether the right answer for the overall good
of the DKIM specification is to make the proposed split now, or not
to.  And at some point between now and then, please make it clear
where you stand on the question, so we can fairly judge consensus.

We also thought that the outline of the proposed split would be enough
to work with, but there've been a lot of questions of the details.  We
understand that the editors have done a draft of the split that they
will soon be ready to post as (individual) Internet drafts, and we've
asked them to post them.  When they do, please keep in mind that they
are there to answer the questions that are coming up, and NOT to has
out all the split details now.  If the working group approves the
split, we can hammer out the details then.  Use these drafts to see,
specifically, what's being proposed, understand that IF we agree to go
in that direction they will still be up for changes, and don't get
mired in arguing the details now.

On a procedural note: the chairs think that it's within the charter to
decide to satisfy charter work item 1 (DKIM to Draft Standard) by
making this split, and we do not think there's a procedural issue
raised here.  Should we decide NOT to make the split and to proceed to
Draft Standard with a single 4871bis document, the chairs DO think
that revisiting the question is splitting the documents later -- a
fair approach to this -- would require rechartering.

Again, please continue the discussion of the proposed split through 20
January, and let us know where you stand as we evaluate consensus.

Barry, as chair

---

From: Michael Thomas <[email-masked]>
Date: Thu, 13 Jan 2011 16:57:55 -0800

Snatching defeat from the jaws of victory:

-1

Mike

---

From: Scott Kitterman <[email-masked]>
Date: Sat, 15 Jan 2011 12:17:01 -0500

On Thursday, January 13, 2011 02:48:14 pm Barry Leiba wrote:
> ... And at some point between now and then, please make it clear

-1 on splitting now.

For two primary reasons:

1.  While the proposed split doesn't affect the maturity of DKIM, the maturity 
of having got the split correct is a different matter.  Until there are 
multiple users of the split out DOSETA functionality, I think it's premature 
for it to be advancing along the standards track.

2.  While the intent of clearly to maintain DKIM as it is through the split, 
without a stable set of specifications to compare the split documents to (and 
implementation experience based on the split documents) it's difficult to 
really know if any inadvertent incompatibilities have been introduced.

My preferred approach would to be to complete the current charter work item 
based on finishing the unitary specification and then work on the split as a 
new work item (after rechartering).  I don't think that precludes interested 
parties from continuing work on DOSETA in the mean time.

Scott K

---

From: John Levine <[email-masked]>
Date: 15 Jan 2011 19:01:09 -0000

Having looked at the two drafts, although the idea seems reasonable, I
don't think we should do it.  At this point, as I understand it, any
application other than DKIM is hypothetical, which means we can't tell
where the split between generic DOSETA and specific DKIM should be.

As a concrete example, signing netnews messages seems like it should
be about as close to signing mail as you can get.  But relaxed
canonicalization, which is in DOSETA, is not useful for netnews, since
messages are not reformatted after injection, and changes of the sort
it allows are likely to indicate tampering.  Since usenet has a
longstanding forgery problem, I wouldn't want to allow SHA1, so I'd
rather not have that in DOSETA base either.

Yet i=AUID, which is made specific to DKIM, would be useful in the
common case that the author of a posting identified him, her, or
itself to the injection agent.  While we're at it, z= might be useful
for debugging.

You could move those items back and forth easily enough, but then the
next application comes along, say some sort of transaction log that
adds new entries at the bottom, and you want to apply signatures to
note the state of the log at particular times.  Oops, we need l= for
that, better move it from DKIM into DOSETA, too.

Let me repeat that I don't think that the curent split is necessarily
wrong, but I don't have any reason to think it's right, either.

Since we know what DKIM is, I'd rather keep DKIM-bis as one document,
and if it makes sense to do DOSETA, which strikes me as premature
until we have a better idea of what the applications are, make it a
short document that defines a subset of DKIM features by reference to
the DKIM spec.

Regards,
John Levine, [email-masked], Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. http://jl.ly
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Alessandro Vesely <[email-masked]>
Date: Sun, 16 Jan 2011 20:30:55 +0100

> have different semantics and will need a different flag for indicating it.

Perhaps a few more words on the /spirit/ of the split are in order.  I
have serious difficulties at grasping it.

On the one hand, as a glance to the DOSETA draft confirms, the
generalization being sketched seems to be by far more complex than
those that a simple porting to HTTP (or similar header/content
protocol) requires.  The template model introduces an extra degree of
freedom whose justification is not obvious.  For example, the IANA
registry already defines a "DKIM-Signature Query Method" for the
single dns/txt entry.  A client service may define additional entries.
 Yet, the Key Retrieval template offers a different way to achieve a
similar effect.  Why would we need that?

On the other hand, after the endless discussions about the meaning of
DKIM signatures, I had started to appreciate the current 1st paragraph
of rfc4871bis.  Claiming "some responsibility" obviously alludes to
the ability of imposing any policies on the contents originating from
controlled servers.  Thus, DKIM characterizes _messages_ as-if their
contents originated from a direct connection to an ADMD server.  Why
would client services have to redefine that?

I think that if it were possible to design a much much simpler
generalization, opinions about the resulting split might be different.
 To wit, if the only details pertaining to our client service
consisted of bindings to RFC 5322, e.g. mandatory fields, then the
split could be seen as a simplification.  In particular, it would
happen to nicely insulate a controversial compliance issue that we
discussed recently.

jm2c

---

From: "Charles Lindsey" <[email-masked]>
Date: Mon, 17 Jan 2011 12:07:28 -0000

>> where you stand on the question, so we can fairly judge consensus.

Yes, I am inclined to agree. To make DOSETA a useful basis for expansion  
into kther areas is going to need much detailed discussion, which will  
surely delay advancing DKIM to Draft status.
> for it to be advancing along the standards track.

Indeed. DOSETA, as it finally turns out might be a Good Thing, but it  
would have to be a Proposed Standard, so you couldn't base a Draft for  
DKIM on it.

It might all happen later on but, in the meantime, I think the only way to  
reuse the DKIM design for some new Foobar protocol would be to write a  
Proposed Standard for Foobar which referenced the DKIM Draft Standard and  
which stated that specified parts of the DKIM draft were to be  
incorporated, but that others (e.g. the list of headers required to be  
signed, perhaps some of the tags and maybe the key management) were to be  
done differently.

-- 
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: Barry Leiba <[email-masked]>
Date: Thu, 20 Jan 2011 14:35:57 -0500

> a consensus call.

It's not quite the end of the day, but it seems quite clear to the
chairs that we do not have consensus to split the DKIM spec.  If a
groundswell of support comes in in the next few hours and changes
that, we'll reconsider, but that certainly seems unlikely.

So the split is off the table at this point.  It can be proposed again
after 4871bis gets DS status and the mailing list document is done, if
folks still have the enthusiasm to go another step.

The chairs ask the 4871bis editors to post a new 4871bis as soon as
possible, with the changes from the WGLC, and to point out any issues
that remain unresolved.

Barry, as chair