Barry Leiba | 7 Jan 21:37 2011
Picon

Re-thinking the organization of the DKIM spec

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
(Continue reading)

Dave CROCKER | 7 Jan 21:58 2011
Picon

Proposed documentation split between DKIM and "DOSETA"

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.
(Continue reading)

Dave CROCKER | 7 Jan 23:28 2011
Picon

Re: Proposed documentation split between DKIM and "DOSETA"


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
   Brandenburg InternetWorking
   bbiw.net
John R. Levine | 7 Jan 23:35 2011

Re: Proposed documentation split between DKIM and "DOSETA"

> 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, johnl <at> iecc.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. http://jl.ly
John Levine | 7 Jan 23:24 2011

Re: Proposed documentation split between DKIM and "DOSETA"

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

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

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.

R's,
John
Dave CROCKER | 8 Jan 01:17 2011
Picon

Re: Re-thinking the organization of the DKIM spec


On 1/7/2011 12:37 PM, Barry Leiba wrote:
>   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.

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
   Brandenburg InternetWorking
   bbiw.net
Rolf E. Sonneveld | 8 Jan 00:48 2011
Picon

Re: Proposed documentation split between DKIM and "DOSETA"

Dave,

On 1/7/11 9:58 PM, Dave CROCKER wrote:
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.

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

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


<div>
    Dave,<br><br>
    On 1/7/11 9:58 PM, Dave CROCKER wrote:
    <blockquote cite="mid:4D277E5A.8020804 <at> dcrocker.net" type="cite">
      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.

    </blockquote>
    <br>
    First of all I would like to express my serious concerns about two
    things:<br><br><ol>
<li>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:
        <span></span><a href="http://googleappsupdates.blogspot.com/2011/01/email-authentication-using-dkim-now.html">http://googleappsupdates.blogspot.com/2011/01/email-authentication-using-dkim-now.html</a>
        . 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.<br>
</li>
      <li>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. <br>
</li>
    </ol>
<br>
    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.<br><br><br><blockquote cite="mid:4D277E5A.8020804 <at> dcrocker.net" type="cite">

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

    </blockquote>
    <br>
    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?<br><br>
    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.<br><br>
    Regards,<br>
    /rolf<br><br><br>
</div>
J.D. Falk | 8 Jan 02:06 2011

Re: Proposed documentation split between DKIM and "DOSETA"

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.

Barry Leiba | 8 Jan 02:46 2011
Picon

Re: Re-thinking the organization of the DKIM spec

> 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

SM | 8 Jan 02:43 2011
Picon

Re: Re-thinking the organization of the DKIM spec

Hi Barry,
At 12:37 07-01-11, 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.

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  


Gmane