Re: [ietf-dkim] Re-thinking the organization of the DKIM spec
> 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. 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 ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Re-thinking the organization of the DKIM spec
On Sat, 15 Jan 2011 17:17:01 -, Scott Kitterman wrote: > On Thursday, January 13, 2011 02:48:14 pm Barry Leiba wrote: >> ... And at some point between now and then, please make it clear >> where you stand on the question, so we can fairly judge consensus. > > > -1 on splitting now. 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 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. 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: c...@clerew.man.ac.uk 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
Re: [ietf-dkim] Re-thinking the organization of the DKIM spec
On 13/Jan/11 18:10, Dave CROCKER wrote: > 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. 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 ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Re-thinking the organization of the DKIM spec
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, jo...@iecc.com, 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
Re: [ietf-dkim] Re-thinking the organization of the DKIM spec
On Thursday, January 13, 2011 02:48:14 pm Barry Leiba wrote: > ... And at some point between now and then, please make it clear > where you stand on the question, so we can fairly judge consensus. -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 ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Re-thinking the organization of the DKIM spec
Snatching defeat from the jaws of victory: -1 Mike Barry Leiba wrote: > 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 > ___ > NOTE WELL: This list operates according to > http://mipassoc.org/dkim/ietf-list-rules.html ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Re-thinking the organization of the DKIM spec
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 ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Re-thinking the organization of the DKIM spec
On 1/13/11 9:10 AM, Dave CROCKER wrote: > 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. 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 ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Re-thinking the organization of the DKIM spec
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
Re: [ietf-dkim] Re-thinking the organization of the DKIM spec
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... > 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. 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. > 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? 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. > 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. 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 Brandenburg InternetWorking bbiw.net ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Re-thinking the organization of the DKIM spec
On Tue, Jan 11, 2011 at 7:05 PM, J.D. Falk wrote: > 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. 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, two nearly-identical parallel > specifications. 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 ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Re-thinking the organization of the DKIM spec
J.D. Falk wrote: > 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. 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 ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Re-thinking the organization of the DKIM spec
On Tue, 11 Jan 2011 12:12:53 -, Eliot Lear wrote: > 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. 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). -- Charles H. Lindsey -At Home, doing my own thing Tel: +44 161 436 6131 Web: http://www.cs.man.ac.uk/~chl Email: ...@clerew.man.ac.uk 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
Re: [ietf-dkim] Re-thinking the organization of the DKIM spec
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. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Re-thinking the organization of the DKIM spec
On 11Jan11, Eliot Lear allegedly wrote: > Barry, Dave, and others, > 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. 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. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Re-thinking the organization of the DKIM spec
On 1/10/2011 5:28 PM, Jim Fenton wrote: > 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. 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 Brandenburg InternetWorking bbiw.net ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Re-thinking the organization of the DKIM spec
On 11/01/11 12:12, Eliot Lear wrote: > 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. 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. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Re-thinking the organization of the DKIM spec
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 On 1/7/11 9:37 PM, Barry Leiba wrote: > As the 4871bis editors worked on resolving the last sets of comments > in the 4871bis document, the chairs and the editors had some > discussion about other efforts that are interested in re-using > portions of the DKIM signing/verifying/key-distribution mechanism > outside the email context. See, for example, > http://tools.ietf.org/html/draft-desruisseaux-ischedule. This would > mean using a DKIM-like mechanism to secure the distribution of > scheduling events. That effort is currently referencing (and > updating) RFC 4871, but that includes what for them are many > irrelevant and inappropriate details that have to do with email. > > One way we can handle this and other use cases, as we move the DKIM > specification along, is to split the specification into two documents, > one that describes the underlying components, and a second that > describes the email-specific bits. > > 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 c
Re: [ietf-dkim] Re-thinking the organization of the DKIM spec
Oh, good. I'm not the only party pooper. To what Jim wrote, I'll add: 1) As a developer, multiple documents generally suck. IKE, ISAKMP, and their friends. Need I say more? 2) Frameworks almost invariably fail, and that's what I sense here. We gave some passing thought to making this usable in other contexts, and heck I even wrote a SIP/DKIM signer to tweak Fluffy's nose about sip-identity, but the reality is that actually getting refactoring done in a way that wouldn't ultimately require a new spin of one or more documents is, IMO, close to hopeless. 3) Differing document maturity levels. You have one that's advancing to draft, and one that one day may be PS. It just doesn't seem reasonable to have those two be linked even weakly. I really don't see what the problem would be to take what we did and just insert it as a whole and then start editing. If this second use had come a couple three years ago, it might have been worth considering to rationalize things, but given how far along we are this is just setting up to be a big fail. Mike On 01/10/2011 05:28 PM, Jim Fenton wrote: > On 1/7/11 12:37 PM, Barry Leiba wrote: > >> As the 4871bis editors worked on resolving the last sets of comments >> in the 4871bis document, the chairs and the editors had some >> discussion about other efforts that are interested in re-using >> portions of the DKIM signing/verifying/key-distribution mechanism >> outside the email context. See, for example, >> http://tools.ietf.org/html/draft-desruisseaux-ischedule. This would >> mean using a DKIM-like mechanism to secure the distribution of >> scheduling events. That effort is currently referencing (and >> updating) RFC 4871, but that includes what for them are many >> irrelevant and inappropriate details that have to do with email. >> >> One way we can handle this and other use cases, as we move the DKIM >> specification along, is to split the specification into two documents, >> one that describes the underlying components, and a second that >> describes the email-specific bits. >> > I'm quite unhappy with the proposal to split RFC4871, for a number of > reasons (in no particular order): > > 1. Review Abuse: We held a Last Call on rfc4871bis that closed on 22 > October 2010. Many of us put considerable focus into a detailed edit of > the document at that time, and to hear that other than surgical changes > to the document in response to Last Call comments is an abuse of many > peoples' time, and not just mine. The cited other usage of DKIM > signatures, iSchedule, was published in March 2010 so it should have not > been the gating factor. > > 2. Charter: The DKIM WG charter states "1. Advance the base DKIM > protocol (RFC 4871) to Draft Standard. > This is the first priority for the working group." A reorganization of > 4871bis into two documents is inconsistent with the "first priority" > requirement of the charter. > > 3. Risk: The amount of violence that will need to be done to the text > of RFC4871 introduces significant risk that the specifications will be > unclear or inconsistent with 4871. While the rules for advancing to > Draft do refer to specifications and not documents, I would be > uncomfortable with doing anything other than recycling at Proposed to > see if errata, etc. result from the changes. But recycling at Proposed > is inconsistent with the charter. > > 4. Usage: DKIM has quite a bit that is tailored specifically for mail: > the syntax of the header field, canonicalization, etc. The proposed > split includes canonicalization as part of DOSETA, and wonder if that > really makes sense. While the syntax of a DKIM signature may be close > to what's required for iSchedule, will we next need to consider yet > another split to permit signatures to be expressed in JSON, XML, or > other formats? Are there other uses considered besides iSchedule at > this time? > > 5. Security properties: DKIM was designed to provide a modest level of > security limited by the security properties of DNS. This was considered > acceptable because it's comparable to the level of security afforded > message routing (since MX records could be spoofed). Other uses of DKIM > need to be examined carefully to make sure that we do not depend on an > insufficiently secure key infrastructure. While use of DNSSEC mitigates > this, I'm concerned about whether it will really be used everywhere needed. > > 6. Redundancy: Section 10.1 of the iSchedule draft requires the use of > TLS for all transactions. Why is DKIM then also needed (if the > certificate verification happens in both directions, of course)? Why > are two very different mechanisms in use? > > 7. Openness and Timeliness: Barry has apologized for not announcing this > a month ago, but I sense that this has been going on in a private design > team longer than that. BCP 9 section 1.2 talks to openness and > timeliness; this fails on both accounts. > > -Ji
Re: [ietf-dkim] Re-thinking the organization of the DKIM spec
On 1/7/11 12:37 PM, Barry Leiba wrote: > As the 4871bis editors worked on resolving the last sets of comments > in the 4871bis document, the chairs and the editors had some > discussion about other efforts that are interested in re-using > portions of the DKIM signing/verifying/key-distribution mechanism > outside the email context. See, for example, > http://tools.ietf.org/html/draft-desruisseaux-ischedule. This would > mean using a DKIM-like mechanism to secure the distribution of > scheduling events. That effort is currently referencing (and > updating) RFC 4871, but that includes what for them are many > irrelevant and inappropriate details that have to do with email. > > One way we can handle this and other use cases, as we move the DKIM > specification along, is to split the specification into two documents, > one that describes the underlying components, and a second that > describes the email-specific bits. I'm quite unhappy with the proposal to split RFC4871, for a number of reasons (in no particular order): 1. Review Abuse: We held a Last Call on rfc4871bis that closed on 22 October 2010. Many of us put considerable focus into a detailed edit of the document at that time, and to hear that other than surgical changes to the document in response to Last Call comments is an abuse of many peoples' time, and not just mine. The cited other usage of DKIM signatures, iSchedule, was published in March 2010 so it should have not been the gating factor. 2. Charter: The DKIM WG charter states "1. Advance the base DKIM protocol (RFC 4871) to Draft Standard. This is the first priority for the working group." A reorganization of 4871bis into two documents is inconsistent with the "first priority" requirement of the charter. 3. Risk: The amount of violence that will need to be done to the text of RFC4871 introduces significant risk that the specifications will be unclear or inconsistent with 4871. While the rules for advancing to Draft do refer to specifications and not documents, I would be uncomfortable with doing anything other than recycling at Proposed to see if errata, etc. result from the changes. But recycling at Proposed is inconsistent with the charter. 4. Usage: DKIM has quite a bit that is tailored specifically for mail: the syntax of the header field, canonicalization, etc. The proposed split includes canonicalization as part of DOSETA, and wonder if that really makes sense. While the syntax of a DKIM signature may be close to what's required for iSchedule, will we next need to consider yet another split to permit signatures to be expressed in JSON, XML, or other formats? Are there other uses considered besides iSchedule at this time? 5. Security properties: DKIM was designed to provide a modest level of security limited by the security properties of DNS. This was considered acceptable because it's comparable to the level of security afforded message routing (since MX records could be spoofed). Other uses of DKIM need to be examined carefully to make sure that we do not depend on an insufficiently secure key infrastructure. While use of DNSSEC mitigates this, I'm concerned about whether it will really be used everywhere needed. 6. Redundancy: Section 10.1 of the iSchedule draft requires the use of TLS for all transactions. Why is DKIM then also needed (if the certificate verification happens in both directions, of course)? Why are two very different mechanisms in use? 7. Openness and Timeliness: Barry has apologized for not announcing this a month ago, but I sense that this has been going on in a private design team longer than that. BCP 9 section 1.2 talks to openness and timeliness; this fails on both accounts. -Jim ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] 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 ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] 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 ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] 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 ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
[ietf-dkim] 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 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
