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

From: Barry Leiba <[email-masked]>
Date: Fri, 7 Jan 2011 15:37:12 -0500

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.

Note that progression along the standards track is for
*specifications*, not for documents, as such, so there's no reason
this split has to send us back to another cycle at Proposed Standard.
What's required is that we make no changes to the actual protocol (or,
at least, only changes that permit advancing to Draft).  I've
discussed this with the Security ADs and the Applications ADs, and
they all agree that (1) such a split could be a good idea and (2) a
split that affects organization but does not change the specification
could still go directly to Draft Standard.

The editors have done some work on this to determine whether they can
split it safely, and they believe they have something suitable.  The
chairs have asked them to post a detailed outline of their proposal so
that we can discuss whether the working group thinks a document split
is a good idea.  We would like the discussion to focus just on that
point now, without getting to far into the details of the split,
beyond what's necessary to develop consensus for or against splitting.

We want to make this clear from the start: the chairs, the editors,
and (to the extent that they've thought about it, which is fairly
little at this point) the ADs think that splitting the document is
appropriate and useful... but it's the working group that will decide
whether to do it.  Nothing has been decided yet, and it's up to the
working group.  We'll need rough consensus FOR making the change.
Lacking that, 4871bis will stay as it is, as one document.

Please try to keep the discussion focused.  Expect a message from the
document editors very soon, with the details of their proposed split.

Barry (and Stephen), as chairs

--
P.S.
I apologize for not making sure this got posted here for discussion a
month ago.  The delay is my fault.  [Barry]
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Dave CROCKER <[email-masked]>
Date: Fri, 07 Jan 2011 12:58:02 -0800

Folks,

Here's the proposal that Barry just announced, for splitting the DKIM 
specification into a DKIM-specific portion and an underlying, more generic 
portion that could be re-purposed for other services.  It's current working 
acronym is DOSETA.

Note that when combined the two documents would produce a DKIM protocol that is 
over-the-wire identical with the current DKIM[1].  In other words, this exercise 
does not change the DKIM protocol at all.  It merely re-apportions the 
documentation for expanded use...

d/

[1] I should acknowledge that things are moved around massively, and that this 
effort uncovered some hiccups in the existing DKIM document which are now fixed. 
  But again, no protocol changes.

Proposal for reapportion rfc4871bis (that is, DKIM)
---------------------------------------------------

Abstract

      DomainKeys Identified Mail (DKIM) permits a person, role, or organization
that owns the signing domain to claim some responsibility for a message by
associating the domain with the message. This can be an author's organization,
an operational relay or one of their agents. DKIM separates the question of the
identity of the signer of the message from the purported author of the message.
Assertion of responsibility is validated through a cryptographic signature and
querying the signer's domain directly to retrieve the appropriate public key.
Message transit from author to recipient is through relays that typically make
no substantive change to a message or its content and thus preserve the DKIM
signature.

Table of Contents

1.  Introduction

     1.1   Signing Identity
     1.2   Terminology and Definitions

2.  Signing and Verification Protocol

3.  Extensions to DOSETA Template

     3.1   Signature Data Structure
     3.2   Relationship between SDID and AUID
     3.3   Stored Key Data

4.  Considerations

     4.1   Security Considerations
     4.2   IANA Considerations

5.  References

     5.1   Normative References
     5.2   Informative References

A.  MUA Considerations

B.  End-to-End Scenario Example

     B.1   The User Composes an Email
     B.2   The Email is Signed
     B.3   The Email Signature is Verified

C.  Types of Use

     C.1   Alternate Submission Scenarios
     C.2   Alternate Delivery Scenarios

Proposal for specification of re-usable components
--------------------------------------------------

    (The working acronym is DOSETA, for DOmain SEcurity TAgging.)

Abstract

      DomainKeys Security Tagging (DOSETA) is a component mechanism that enables
development of a security-related service, such as authentication or encryption,
with keys based on domain names; the name owner can be any actor involved in the
handling of the data, such as the author's organization, a server operator or
one of their agents. The DOSETA Library provides a collection of common
capabilities, including canonicalization, parameter tagging, and retrieval of
self-certified keys. The DOSETA Signing Template affixes a signature to data
that is in a "header/content" form. Defining the meaning of the signature is the
responsibility of the service that incorporates DOSETA. The signature is
validated through a cryptographic signature and querying the signer's domain
directly, to retrieve the appropriate public key.

Table of Contents

1.  Introduction

     1.1   DOSETA Features
     1.2   DOSETA Architecture

2.  Terminology and Definitions

     2.1   Identity
     2.2   Actors
     2.3   Syntax

3.  DOSETA Library

     3.1   Canonicalization
     3.2   Tag=Value Parameters
     3.3   Key Management
     3.4   Selectors for Keys
     3.5   DNS Binding for Key Retrieval
     3.6   Stored Key Data

4.  DOSETA Header/Content Signing Template

     4.1   Cryptographic Algorithms
     4.2   Signature Data Structure
     4.3   Signature Calculation
     4.4   Signer Actions
     4.5   Verifier Actions
     4.6   Requirements for Tailoring the Signing Service
     4.7   Signing by Parent Domains

5.  Semantics of Multiple Signatures

     5.1   Example Scenarios
     5.2   Interpretation

6.  Considerations

     6.1   IANA Considerations
     6.2   Security Considerations

7.  References

     7.1   Normative References
     7.2   Informative References

A.  Creating a Public Key

-- 

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

---

From: Dave CROCKER <[email-masked]>
Date: Fri, 07 Jan 2011 14:28:23 -0800

On 1/7/2011 2:24 PM, John Levine wrote:
> As it stands, 4871 suffers from too much history, and as a result
> contains a great deal of stuff that has nothing to do with
> implementing the protocol.  I would, for example, get rid of
> everything about MUAs beyond mentioning the bare facts that MUAs can
> do DKIM signing and verification.  We should be able to produce docs
> that are both clearer and shorter.

Thanks for providing me an opportunity to distinguish between making 
"substantive" changes to the specification versus merely re-organizing things.

The current reorganization made NO substantive changes except bug fixes.

And so, for example, controversial items such as MUA discussion were preserved. 
  Although they might be worthy of further discussion, that discussion has 
NOTHING to do with the current round of effort.

The closest the current effort came to "substantive" change is the choice for 
what tags, etc. to include in one document versus the other.

d/

-- 

   Dave Crocker

---

From: "John R. Levine" <[email-masked]>
Date: 7 Jan 2011 17:35:06 -0500

> And so, for example, controversial items such as MUA discussion were 
> preserved.  Although they might be worthy of further discussion, that 
> discussion has NOTHING to do with the current round of effort.

In the list of nits I sent along some months ago, I noted that there was a 
fair amount of text that implied that a DKIM verifier produces an edited 
version of the message it's verifying.  I gather we agree that it doesn't, 
so, uh, what's the new draft going to say?

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: John Levine <[email-masked]>
Date: 7 Jan 2011 22:24:23 -0000

>portion that could be re-purposed for other services.  It's current working 

Seems reasonable to me, both the split, and the plan to reorganize.

R's,
John

---

From: Dave CROCKER <[email-masked]>
Date: Fri, 07 Jan 2011 16:17:11 -0800

On 1/7/2011 12:37 PM, Barry Leiba wrote:
>   I've

I commend a re-reading of this portion of Barry's specification for folks who 
are worried that the proposed documentation change would cause DKIM to be viewed 
as "unstable".

d/
-- 

   Dave Crocker

---

From: "Rolf E. Sonneveld" <[email-masked]>
Date: Sat, 08 Jan 2011 00:48:26 +0100

Dave,

>    But again, no protocol changes.

First of all I would like to express my serious concerns about two things:

   1. it has taken some four years to make DKIM what it is now. And with
      that, I don't mean the protocol specification itself, but I mean
      adoption, deployment, acceptance of DKIM, the level of knowledge
      about DKIM within organizations, reputation of the spec. etc.
      Although the adoption rate may seam slow, over time we see real
      progress in the percentage of DKIM signed messages. Today someone
      forwarded me the following announcement of Google:
      http://googleappsupdates.blogspot.com/2011/01/email-authentication-using-dkim-now.html
      . My concern is that, after all these years, now redefining what
      DKIM is, will certainly not help acceptance and deployment growth.
      It may work counterproductive and it may make organizations afraid
      of investing in such a changing technology, even if the changes
      are much smaller then they seem to be. Technology is one thing,
      Public Relations is something completely different.
   2. although I understand the reason why you would like to redefine
      DKIM and make a distinction between the core elements (DOSETA) and
      the mail-specific implementation of these elements (DKIM), in my
      view it's too late to make this split. Splitting up these things
      will cause a lot of confusion with the public (CEO's that need to
      decide whether to invest in something like DKIM). Let us be
      realistic: today many people don't exactly understand what DKIM
      does; the discussions about DKIM on this ietf-dkim list illustrate
      this very well (see threads like 'What DKIM provides, again' and
      'The usual misunderstanding about what DKIM promises' etc. etc.).
      Even on this list there is no consensus about what DKIM really is.
      Splitting up DKIM now will mean even less people understand what
      we're doing here and what DKIM really is.

So to summarize: from a technology point of view it may be a good idea 
to make this split, from a DKIM acceptance point of view this will turn 
into a deception.

> Proposal for reapportion rfc4871bis (that is, DKIM)

Regarding the draft ToC's you sent I have one question: the current 
chapters 5 (Signer Actions) and 6 (Verifier Actions) of RFC4871 seem to 
show up in the ToC of the "DOSETA" document. The current chapter 5 of 
4871bis however describes how e-mail messages are to be signed and as 
such 'Signer Actions' for DKIM should show up in the ToC of RFC4871bis 
and the same is true for Verifier Actions. But maybe you take chapters 5 
and 6 of 4871bis and put them in chapter 2 of the new DKIM?

For the discussion it would help if you would describe for each 
paragraph of the current RFC4871bis draft, where that paragraph would 
fit in the new documents, either in DKIM or DOSETA or (some parts) in both.

Regards,
/rolf

---

From: "J.D. Falk" <[email-masked]>
Date: Fri, 7 Jan 2011 17:06:20 -0800

On Jan 7, 2011, at 3:48 PM, Rolf E. Sonneveld wrote:

> 	• it has taken some four years to make DKIM what it is now. And with that, I don't mean the protocol specification itself, but I mean adoption, deployment, acceptance of DKIM, the level of knowledge about DKIM within organizations, reputation of the spec. etc. Although the adoption rate may seam slow, over time we see real progress in the percentage of DKIM signed messages. Today someone forwarded me the following announcement of Google: http://googleappsupdates.blogspot.com/2011/01/email-authentication-using-dkim-now.html . My concern is that, after all these years, now redefining what DKIM is, will certainly not help acceptance and deployment growth. It may work counterproductive and it may make organizations afraid of investing in such a changing technology, even if the changes are much smaller then they seem to be. Technology is one thing, Public Relations is something completely different.
> 	• although I understand the reason why you would like to redefine DKIM and make a distinction between the core elements         (DOSETA) and the mail-specific implementation of these elements (DKIM), in my view it's too late to make this split. Splitting up these things will cause a lot of confusion with the public (CEO's that need to decide whether to invest in something like DKIM). Let us be realistic: today many people don't exactly understand what DKIM does; the discussions about DKIM on this ietf-dkim list illustrate this very well (see threads like 'What DKIM provides, again' and 'The usual misunderstanding about what DKIM promises' etc. etc.). Even on this list there is no consensus about what DKIM really is. Splitting up DKIM now will mean even less people understand what we're doing here and what DKIM really is. 
> 
> So to summarize: from a technology point of view it may be a good idea to make this split, from a DKIM acceptance point of view this will turn into a deception.

I absolutely understand where your concerns come from -- I've been working on the political layer of DKIM for years too -- but I'm not sure I agree that this split would cause us to return to the bad old days of companies refusing to implement because it's "just a draft."

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.  (Though I wonder: would it remain RFC 4871 after the split?)

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.  Examples I've seen so far include SIP calls, RSS articles, XMPP messages...and those are just the open, standard protocols.

Even if there is some political risk -- and I admit there's some, though I believe it'll be minor -- I'd say the potential benefits outweigh the risk.

---

From: Barry Leiba <[email-masked]>
Date: Fri, 7 Jan 2011 20:46:44 -0500

> draft-desruisseaux-ischedule-01 is dated March 8, 2010.  It intends to
> update RFC 4871, if approved.  That draft has never been mentioned in the
> DKIM WG until today.  Is that draft being targeted as a work item for this
> working group?

No.  It will be an individual submission, related to iCalendar work.
In the end, I'm not sure it should "update 4871".

> The latest working group charter is dated June 1010 and the first priority
> listed is to "Advance the base DKIM protocol to Draft Standard".  There has
> been long discussions to get there.  Will the WG have to recharter now?

No.

Barry

---

From: SM <[email-masked]>
Date: Fri, 07 Jan 2011 17:43:55 -0800

Hi Barry,
>describes the email-specific bits.

draft-desruisseaux-ischedule-01 is dated March 8, 2010.  It intends 
to update RFC 4871, if approved.  That draft has never been mentioned 
in the DKIM WG until today.  Is that draft being targeted as a work 
item for this working group?

The latest working group charter is dated June 1010 and the first 
priority listed is to "Advance the base DKIM protocol to Draft 
Standard".  There has been long discussions to get there.  Will the 
WG have to recharter now?

Regards,
-sm

---

From: Dave CROCKER <[email-masked]>
Date: Fri, 07 Jan 2011 21:29:31 -0800

On 1/7/2011 2:35 PM, John R. Levine wrote:
> In the list of nits I sent along some months ago, I noted that there was a fair
> amount of text that implied that a DKIM verifier produces an edited version of
> the message it's verifying. I gather we agree that it doesn't, so, uh, what's
> the new draft going to say?

The new documents need to resolve all errata and working group consensus about 
equivalent language and detail changes.

The current round of discussion is intended to be separate from such other, 
continuing work.  Separate in terms of discussion, but not to the exclusion of 
satisfying those existing requirements.

d/
-- 

   Dave Crocker

---

From: "Charles Lindsey" <[email-masked]>
Date: Mon, 10 Jan 2011 11:07:20 -0000

> portion that could be re-purposed for other services.  It's current  

By and large I would be happy to see such a split, especially as it would  
leave the top-level DKIM protocol unchanged (modulo such further nits as  
we might need to fix even with DKIM as it stands).

The precise detail of the split would need discussion, and that is mostly  
for later. So I will just mention a couple of items as markers for things  
I might want to raise then.

> with keys based on domain names; ....

I think keys should be able to be based on things other than domain names.  
Names of netnews newgroups in one obvious exception, but there may be many  
situations where the entity claiming authority to certify some document  
may have no obvious relation to a domain.

>      3.5   DNS Binding for Key Retrieval

Again, keys in some protocols may need to be long lived, and DNS may not  
be the appropriate way to retrieve them. That could well be one option  
provided under DOSETA, but provisions shold be made for other  
possibilities such as registries, etc.

-- 
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: Jim Fenton <[email-masked]>
Date: Mon, 10 Jan 2011 17:28:52 -0800

> 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

---

From: Michael Thomas <[email-masked]>
Date: Mon, 10 Jan 2011 18:20:19 -0800

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

---

From: Barry Leiba <[email-masked]>
Date: Mon, 10 Jan 2011 23:21:07 -0500

> 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.

Yes.

> (Though I wonder: would it remain RFC 4871 after the split?)

It will not, in any case, regardless of the decision to split or not.
The update to move DKIM to Draft Standard will necessarily have a new
RFC number.

Barry

---

From: Eliot Lear <[email-masked]>
Date: Tue, 11 Jan 2011 13:12:53 +0100

Barry, Dave, and others,

Thanks for proposing this interesting split.  As I'll discuss below, at
this point I think I have more questions than opinions.  But I have at
least one opinion.

1.  I recognize that sometimes good ideas have their own schedules, but
I consider it unfortunate that the WG had to spend time to go through
WGLC, resolve open issues, and then for the authors and chairs to
reorganize the work.  I do think we're well beyond our charter, and that
we should consider this only in the context of rechartering.  Such
consideration is always fair game.

2.  The mechanisms in DOSETA were designed for DKIM.  If we are
generalizing along the lines that Dave has mentioned, I would prefer
that DOSETA in particular not advance to draft status, as it ought to be
tested in at least two separate applications for a time.  Otherwise we
run the risk of ossifying something prematurely.

3.  It's at least worth a conversation to determine whether the split is
correct, and just how generally useful this will be.  I have to believe
that Dave is motivated by more than just Bernard's draft.  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).

The innovation of DKIM is not any one of these things, but rather the
combination.  The test question for me here, for instance, is whether we
can standardize the processing of the signature in DNS as separate from
how the signature is made.  That is- can there be different types of
meta-information covered that does not take the form of headers/body?

4.  Rather than keep it in the back of my head, I'll state it outright:
is a goal here to provide an alternative to SSL-based web page
security?  Conveniently, web content does take the form of header/body. 
If so, one reasonable question to ask would be whether there exist
characteristics and semantics of X.509 that would be necessary in this
context.  For instance, is there sufficient surety given for, oh,
banks?  And what would the UI implications be?  Also, presumably it
would have implications to TLS relating to keying material. 

5.  As Mike Thomas and Jim Fenton alluded, the implications for such
frameworks extend well beyond this working group, and as such I would
recommend broad consultation with the security community.

Ok, I'll stop there for now.  Seems like enough food for thought.

Eliot

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 11 Jan 2011 12:56:20 +0000

On 11/01/11 12:12, Eliot Lear wrote:
> reorganize the work.  

Just one quick clarification. The editors brought this suggestion to
us and the chairs are bringing that to the WG to see if there's
consensus for a change or not, i.e., the chairs aren't advocating
one way or the other, (though we may have opinions), we're trying
to find out what the WG wants.

And as Barry said in his original posting: We'll need rough
consensus FOR making the change. Lacking that, 4871bis will stay
as it is, as one document.

Cheers,
S.

---

From: Alessandro Vesely <[email-masked]>
Date: Tue, 11 Jan 2011 19:09:53 +0100

> portion that could be re-purposed for other services.  It's current working 

I'm embarrassed to raise such a trivial issue, but couldn't it be done
the other way around?  That is, keep the name DKIM for the core spec
and invent some other name for its application to RFC 5322.  This way

* the "DKIM-Signature" name remains fully justified,

* it will be more meaningful for iSchedule to say they use DKIM than
to mention DOSETA, and

* DOSETA would not have to define a "_domainkey" keyword that is not
part of its title.

> associating the domain with the message.

I'd also s/Mail/Message/ (Messages, Messaging, or similar) in the
acronym expansion.  Such change may be used to convey the extent of
the split.

JM2C

---

From: Dave CROCKER <[email-masked]>
Date: Tue, 11 Jan 2011 10:59:31 -0800

On 1/10/2011 5:28 PM, Jim Fenton wrote:
> peoples' time, and not just mine.

Separate from the larger concerns you raise, I should clarify the specific one 
about use of feedback from the Last Call:

    The new docs willuse the CORRECTED rfc4871bis text.

In other words, any changes produced from reviews will be in the split documents.

d/

ps. FWIW, iSchedule was offered as an exemplar, not a motivator not a necessary 
consumer.  iSchedule really had nothing to do with the basis or timing of the 
proposed split.  Serendipity of input and thinking were responsible...

--

   Dave Crocker

---

From: "Mark Delany" <[email-masked]>
Date: 11 Jan 2011 10:28:09 -0800

> how the signature is made.

Extending Eliot's point, does the split make the individual docs
potentially beholden to multiple masters?  The Chairs suggest "no",
but won't the split encourage DOSETA participation (and possibly
others) who necessarily have different perspectives and goals?

I also agree with the comment that DKIM probably had an easier time
getting to this stage because it focuses solely on email. Our
assurances that this was *just* for a particular security application
with fairly modest goals rings a little hollow if we are now saying
that DKIM is to become a general framework. Do folk think we have
enough deployment experience to say that those assurances are
obsolete?

>From a personal perspective, getting closure on DKIM is tantalizingly
close. Those with WG-fatigue probably feel that this proposal risks
moving that achievement further into the future with no appreciable
gain to DKIM. Perhaps that's a selfish POV, but the doc split does
have a whiff of second-system syndrome which worries me when we're
still applying the finishing touches to the first system.

Mark.

---

From: "John R. Levine" <[email-masked]>
Date: 11 Jan 2011 14:15:46 -0500

>    The new docs willuse the CORRECTED rfc4871bis text.

Considering how far along we are with rfc4871bis, and keeping mind mind 
the objections from Jim and others, my inclination would be to 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.  For 
the parts that say the same thing, our text editor cut and paste keys are 
ready and able to help.

Regards,

---

From: Wietse Venema <[email-masked]>
Date: Tue, 11 Jan 2011 16:16:20 -0500 (EST)

> the parts that say the same thing, our text editor cut and paste keys are 

+1.  I have no problems with the split, but if some people do,
then let this not stand in the way of progress.

	Wietse

---

From: "J.D. Falk" <[email-masked]>
Date: Tue, 11 Jan 2011 16:05:05 -0800

On Jan 11, 2011, at 4:12 AM, Eliot Lear wrote:

> 2.  The mechanisms in DOSETA were designed for DKIM.  If we are generalizing along the lines that Dave has mentioned, I would prefer that DOSETA in particular not advance to draft status, as it ought to be tested in at least two separate applications for a time.  Otherwise we run the risk of ossifying something prematurely.

This is a good point.

But also, speaking of ossification, seems like 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.

It's not an easy or obvious decision, and I appreciate that we're having a frank and friendly discussion about it.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 11 Jan 2011 16:53:19 -0800

Hi Rolf,

I think your concerns are reasonable.  But I think the "marketing" of DKIM can be managed and maintained as it has its own momentum now; meanwhile, 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.

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.

Thinking at strictly a marketing level, which is the thrust of your remarks, would the answer to "What is DKIM?"  and "What does DKIM do?" really change all that much?

-MSK

From: [email-masked] [mailto:[email-masked]] On Behalf Of Rolf E. Sonneveld
Sent: Friday, January 07, 2011 3:48 PM
To: [email-masked]
Cc: DKIM Mailing List
Subject: Re: [ietf-dkim] Proposed documentation split between DKIM and "DOSETA"

Dave,

Folks,

acronym is DOSETA.

d/

 1.  it has taken some four years to make DKIM what it is now. And with that, I don't mean the protocol specification itself, but I mean adoption, deployment, acceptance of DKIM, the level of knowledge about DKIM within organizations, reputation of the spec. etc. Although the adoption rate may seam slow, over time we see real progress in the percentage of DKIM signed messages. Today someone forwarded me the following announcement of Google: http://googleappsupdates.blogspot.com/2011/01/email-authentication-using-dkim-now.html . My concern is that, after all these years, now redefining what DKIM is, will certainly not help acceptance and deployment growth. It may work counterproductive and it may make organizations afraid of investing in such a changing technology, even if the changes are much smaller then they seem to be. Technology is one thing, Public Relations is something completely different.
 2.  although I understand the reason why you would like to redefine DKIM and make a distinction between the core elements (DOSETA) and the mail-specific implementation of these elements (DKIM), in my view it's too late to make this split. Splitting up these things will cause a lot of confusion with the public (CEO's that need to decide whether to invest in something like DKIM). Let us be realistic: today many people don't exactly understand what DKIM does; the discussions about DKIM on this ietf-dkim list illustrate this very well (see threads like 'What DKIM provides, again' and 'The usual misunderstanding about what DKIM promises' etc. etc.). Even on this list there is no consensus about what DKIM really is. Splitting up DKIM now will mean even less people understand what we're doing here and what DKIM really is.

Abstract

signature.

Table of Contents

1.  Introduction

     1.1   Signing Identity

     3.3   Stored Key Data

4.  Considerations

     4.2   IANA Considerations

5.  References

     5.1   Normative References

A.  MUA Considerations

     B.2   The Email is Signed

C.  Types of Use

Abstract

Table of Contents

1.  Introduction

     1.1   DOSETA Features

     1.2   DOSETA Architecture

     2.1   Identity

     2.2   Actors

     2.3   Syntax

3.  DOSETA Library

     3.1   Canonicalization

     3.2   Tag=Value Parameters

     3.3   Key Management

     3.4   Selectors for Keys

     3.6   Stored Key Data

     4.4   Signer Actions

     4.5   Verifier Actions

     5.1   Example Scenarios

     5.2   Interpretation

6.  Considerations

     6.1   IANA Considerations

7.  References

     7.1   Normative References

A.  Creating a Public Key

Regarding the draft ToC's you sent I have one question: the current chapters 5 (Signer Actions) and 6 (Verifier Actions) of RFC4871 seem to show up in the ToC of the "DOSETA" document. The current chapter 5 of 4871bis however describes how e-mail messages are to be signed and as such 'Signer Actions' for DKIM should show up in the ToC of RFC4871bis and the same is true for Verifier Actions. But maybe you take chapters 5 and 6 of 4871bis and put them in chapter 2 of the new DKIM?

For the discussion it would help if you would describe for each paragraph of the current RFC4871bis draft, where that paragraph would fit in the new documents, either in DKIM or DOSETA or (some parts) in both.

Regards,
/rolf

---

From: Alessandro Vesely <[email-masked]>
Date: Wed, 12 Jan 2011 10:13:45 +0100

> defines  interfaces to them as a toolkit.

+1, considering that the current rfc4871bis is the result of a merge,
publishing the intermediate step before a further split will ease
future comparisons (as they won't have to go down to draft records.)
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: "Rolf E. Sonneveld" <[email-masked]>
Date: Wed, 12 Jan 2011 11:23:13 +0100

Hi, Murray,

On 1/12/11 1:53 AM, Murray S. Kucherawy wrote:
>
> Hi Rolf,
>
> I think your concerns are reasonable.  But I think the "marketing" of 
> DKIM can be managed and maintained as it has its own momentum now;
>

this may be true for the US, I'm not sure about other regions of the 
world. The figures of https://fit.nokia.com/lars/meter/dkim.html show a 
big gap between DKIM use in the US and regions like Europe and Asia. 
Furthermore, a few big companies like Google, PayPal, Yahoo etc., 
contribute significantly to these figures, without them the adoption 
still seems to be marginal. To reach a critical mass an awful lot of 
(smaller) companies still need to join us.

But let's not overemphasize the 'marketing' aspect; it's just one of the 
aspects that need to be taken into account when deciding about the 
document split, among other aspects mentioned by you, by Jim and by others.

> meanwhile, 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.
>

Probably yes. But I wonder how many messaging/transaction type protocols 
will be real candidates to do something with DKIM/DOSETA? If there are 
many of them, a document split is important. If there's only one other, 
I'm not sure it is worth the hassle. A number of candidates has been 
mentioned, but at the same time questions have been raised, how 
realistic the need to use DKIM/DOSETA for some of them is (as SSL/TLS 
connections might be sufficient).

An inventory of candidate protocols that really may profit from 
something like DOSETA, may help to understand the need (or absence 
thereof) to split the documents.

> 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.
>

 From a technical point of view: yes, it is!

> Thinking at strictly a marketing level, which is the thrust of your 
> remarks, would the answer to "What is DKIM?"  and "What does DKIM do?" 
> really change all that much?
>

Probably not, although it depends on who you ask. Yet, I agree with a 
few recent postings suggesting to first advance/publish RFC4871bis and 
after that start thinking about this split.

/rolf

---

From: "Charles Lindsey" <[email-masked]>
Date: Wed, 12 Jan 2011 12:49:28 -0000

> * the "DKIM-Signature" name remains fully justified,

Interesting possibility. 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. I can see advantages  
in either method.

---

From: "Charles Lindsey" <[email-masked]>
Date: Wed, 12 Jan 2011 12:55:19 -0000

> would have implications to TLS relating to keying material.

It's the HTTP protocol that is header/body based, and that protcol is used  
for other things that transporting web content, so certifying HTTP  
messages is not the same as SSL signing web pages (and is somewhat simpler  
since it involves no encryption).

In web applications, the HTTP/XML/whatever page is the payload of the HTTP  
transmission. The HTTP headers are concerned more with the transmission  
mechanics (date, MIME structure, etc).

---

From: Michael Thomas <[email-masked]>
Date: Wed, 12 Jan 2011 07:59:10 -0800

> It's not an easy or obvious decision, and I appreciate that we're having a frank and friendly discussion about it.

There comes a time when it's best for all to just admit that the train has left the station.
I may well have supported this 3 or 4 years ago even with my disinclination for stacks of specs.

Mike

---

From: Jeff Macdonald <[email-masked]>
Date: Wed, 12 Jan 2011 11:05:40 -0500

>> 2.  The mechanisms in DOSETA were designed for DKIM.  If we are generalizing along the lines that Dave has mentioned, I would prefer that DOSETA in particular not advance to draft status, as it ou…

I agree.

> But also, speaking of ossification, seems like 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, t…

I'd 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.

-- 
Jeff Macdonald
Ayer, MA

---

From: Dave CROCKER <[email-masked]>
Date: Wed, 12 Jan 2011 09:10:52 -0800

This raise a specific and interesting technical point.  I haven't seen a 
response so far, so...

> may have no obvious relation to a domain.

The core of this technology has keys that are named and accessed in terms of 
domain names.  It really is fundamental to this technical approach.

It might be possible to define something using another naming and accessing 
scheme but it was be a significantly different technical base, IMO.

d/
-- 

   Dave Crocker

---

From: Dave CROCKER <[email-masked]>
Date: Wed, 12 Jan 2011 10:57:22 -0800

Folks,

I'm trying to do an audit of the issues folks have raised, and aggregate them.

Along the way, I'm finding a few items that are quite specific, so I'm trying to 
deal with them separately.

 From Jim's note, a couple of items don't fit well into the aggregation 
exercise, so...

> this, I'm concerned about whether it will really be used everywhere needed.

There are two lines of answer to this:

1.  Each new use of the core will need to decide whether the facilities that are 
provided by the core are sufficient to that use's needs, including any implied 
or actual security model.

2.  In deciding how to do the documentation split, there is, in fact, some 
challenge in deciding how "general" to make the core specification.  The 
circulated table of contents for DOSETA cites an authentication template.  I had 
originally hoped to make it fully general, to essentially any sort of 
(structured) object.  That proved unwieldy, so it is limited to objects with a 
basic header/content form.  Happily, that happens to cover quite a lot of 
ground.  Still, it's a limitation.  The point I'm making is that the proposed 
split is not intended as an exercise in "interesting" security design but merely 
one of extracting the core of DKIM and making it more easily accessible to other 
services that find it a good match.

> are two very different mechanisms in use?

The proposal is not based on the needs of iSchedule.  (In fact, I hadn't know 
about that effort; I also note how old and apparently inactive that effort is.) 
iSchedule merely happens to provide an interest example of a candidate RE-user 
of DKIM's core.

As for any other details involving iSchedule, they have nothing to do with this 
effort or the DKIM working group.

> timeliness; this fails on both accounts.

This effort began as a personal bit of research. I've been hearing increasing 
rumblings about extended uses for the technology.  In fact it was clear from the 
start that the core had more general utility; it was also clear that we needed 
to focus on one application, so as to not lose focus.

The first file I created on the topic seems to have been November 10th.  The 
first time I showed it to anyone else was around December 8th.

However, none of this really matters.  What matters is that IETF culture and 
rules require that decisions be made by the working group, and that's what is 
happening right here, right now.  And the flow of the postings make it pretty 
clear that if there were a conspiracy-like effort underway, it wasn't managed 
very well...

In fact, the IETF is actually structured with the assumption that everyone is 
biased, that they have an agenda.  This is an advocacy and adversarial 
environment.  So, everyone must surface the details of the work. That is, what 
matters is that technical issues must be made public and must be resolved 
publicly.  What happens prior to that does not matter much.

Rough consensus means that enough people like an idea or a specification, no 
matter its source.

d/

-- 

   Dave Crocker

---

From: "Charles Lindsey" <[email-masked]>
Date: Thu, 13 Jan 2011 10:41:19 -0000

> domain names.  It really is fundamental to this technical approach.

I don't see how that can be so.

The fundamental core of this technology is a mechanism for contructing a  
hash covering a named selection of headers and a body, coupled with some  
canonicalization rules, and incorporating that into a signature header  
using some well-known algorithm such as rsa (but allowing for others).

The question of making the public key available is entirely orthogonal to  
that core protocol. The DSN mechanism is fine for some applications,  
especially where the lifetime of the signature is at most a few weeks. But  
other means of publicising (and especially of authenticating) public keys  
are also in widespread current use and there is nothing in the core  
protocol that would prevent their use in other applications where they  
were more suitable.

So DOSETA should provide for multiple plug-in key storage mechanisms in  
just the same was as it provides for multiple plug-in canonicalizations.  
By all means include the current DNS method as plug-in-key-management #1.

---

From: Eliot Lear <[email-masked]>
Date: Thu, 13 Jan 2011 13:50:45 +0100

Charles,

> By all means include the current DNS method as plug-in-key-management #1.

While perhaps this is an entertaining idea (I was particularly
entertained since it seems to take my notion of generalization far
beyond where I might have taken it), absent an application I have a
difficult time supporting it.  And even if you had an application, I
would be initially disinclined to go this far, simply because
generalization comes with the cost a loss of specific optimization and
often some amount of (sometimes substantial) overhead.  Further, we
don't really get a good view of what to generalize without substantial
operational experience with disparate use cases.

Eliot

---

From: Steve Atkins <[email-masked]>
Date: Thu, 13 Jan 2011 09:00:03 -0800

> protocol that would prevent their use in other applications where they  

But if other ways of getting the public key are more suitable, what's
left? The only thing DKIM does is allow a domain to assert responsibility
for a message in a relatively cheap (if unreliable) way.

If you take away the fundamental "You use this selector and this d=
value in order to find the public key" then you're not left with much other than
a quick-and-dirty canonicalization method that's tuned to the ways messages
get corrupted in email transit.

If someone wants to assert that the content of a message hasn't
changed, and they're not dealing with the weird, very email-specific, constraints
that DKIM is under (transparency to non-DKIM aware recipients, random
body alterations en-route) then DKIM seems a fairly poor way of doing
that, and there are several "real" public-key signing approaches that might
better suited.

> By all means include the current DNS method as plug-in-key-management #1.

What would be a good use case for DKIM-without-DNS?

Cheers,
  Steve

---

From: "Charles Lindsey" <[email-masked]>
Date: Fri, 14 Jan 2011 17:11:05 -0000

> for a message in a relatively cheap (if unreliable) way.

That is most certainly NOT the only thing DKIM does, nor even the most  
important.

What it does is to provide a mechanism for parceling up any document in  
headers+body format in a manner that changes to the document en route (or  
changes to the parts of the document that the originator particularly  
wanted to protect) can be detected cheaply, and even reliably if the key  
management is adequate. And it provides a syntax and semantics for a  
Signature header, with an extensible format based on tags, to do all that.
> get corrupted in email transit.

There are several canonicalizations of varying quick-and-dirty degrees,  
plus provision for plugging in new ones.

The "d=" tag asserts that the signature was on behalf of a domain, and  
provides a mechanism to retrieve the public key (but not reliably, as you  
say, since the DNS record might not exist for ever).

But some other tag could easily be invented to assert that the signature  
was on behalf of some other kind of entity, and that the key would be  
available via some other mechanism (as defined for that tag). No rocket  
science there.

> What would be a good use case for DKIM-without-DNS?

Nobody is suggesting DKIM-without-DNS. The DKIM RFC would state that the  
allowed set of tags would be such and such (either as defined in DOSETA,  
or some additional ones defined for use in DKIM only). Use of "d=" as  
currently defined would, of course, be mandatory in DKIM. What tags the  
FOOBAR protocol allows would be defined in the FOOBAR standard.

---

From: "Charles Lindsey" <[email-masked]>
Date: Fri, 14 Jan 2011 17:19:49 -0000

> operational experience with disparate use cases.

I am glad you find it entertaining. But it was not intended to be so.

You seem to imagine that DKIM is some brand new technology, unlike  
anything that has ever gone before.

It is not. Similar header signing mechanism have been in use within  
Netnews for the past 15 years or more, both for authenticating control  
messages, and for authenticating articles posted by moderators.

So we already have three header-signing protocols in current use - hence  
this proposal to discourage even more ways of doing the same thing.

The problem with the two existing Netnews protocols is that they are (a)  
different and (b) inflexible. Whether they would be changed to be DOSETA  
based at this late stage is doubtful, but certainly possible. But for sure  
they would need different key management protocols, because the signatures  
would NOT be on behalf of a domain.

---

From: Eliot Lear <[email-masked]>
Date: Fri, 14 Jan 2011 20:09:19 +0100

Hi Charles,

> would NOT be on behalf of a domain.

I've played in that pool as well (see Usenet Death Penalty in Wikipedia–
I don't know if it's accurate or not).  But you're mixing identification
& key management with authorization.  Here are two simple approaches to
tackle netnews:

Have a single domain administered by an organization where they delegate
out keys into subdomains such as the following:

news.admin.example.com.
comp.lang.c.example.com.

OR

Have someone at example.com maintain a list trusted domains for a
particular newsgroup.  This has the added benefit of not requiring
additional canonicalization (e.g. what do you do with comp.lang.c++)?

Of course, I must admit that I hadn't realized anyone used netnews
anymore.  Is it not completely swamped with spam?  I really have been
out of that scene for over a decade (or more).

Eliot