Re: what happened to newtrk?
Steve, The IAB spends -- or spent; I haven't been on the IAB since 2000 -- an amazing percentage of its time on layer 9 issues. Most IAB members dislike that (and some ignore that part), but much of it seemed to be stuff that the IETF had to do. I suppose we could ask the Nomcom to select an IPB or an IPSG as well, but all things considered (and as one of the former stuckees) I think we're better off if our political relations were handled by folks with technical clue -- that is why the IETF's participation is generally sought. I agree, and while I don't really know what can be done around the external layer 9 issues, I don't think we have the balance quite right between the IAB and the IESG. The problem is that I also don't fully understand how the law of unintended consequences would play out if we tinkered. So for instance, suppose we had a rule that said that standards process changes were to be approved ONLY by the IAB? Could such a rule be used to bypass the IESG by an individual who didn't like a decision made by that body? And who gets to arbitrate over what a process change is? What about IANA considerations, for instance? This is NOT to say that using the IAB is the only avenue. Perhaps the right approach is simply NOT to have WGs make these proposals but instead let them flow from individuals sponsored either by an IESG or IAB member. Why am I thinking along these lines? It's simply because I believe we have ossified too much, and when the WG acted as intended, the IESG did not properly respond (IMHO). And again, I really don't know what sort of proposal would be best (if any). Eliot ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: what happened to newtrk?
Jeffrey Hutzelman wrote: On Tuesday, September 12, 2006 06:06:08 PM -0400 John C Klensin [EMAIL PROTECTED] wrote: You are correct. I did not address that issue, partially because, personally, I do not consider it very important. While documenting what we are doing would be nice, I don't believe the community is completely happy with what we are doing and, hence, that energy would be better spent figuring out how to move forward. I think that if people are interested in documenting what we are currently doing, the most effective way to do that is for someone to write one or more informational, descriptive internet-drafts that attempt to document the current state of affairs, and then ask for input on them. The author(s) of such documents should feel free to reject input suggesting that the process should be changed as out of scope. I have written draft-carpenter-rfc2026-critique-02.txt. There's a convenient version at http://www.geocities.com/be1carpenter/draft-carpenter-rfc2026-critique-02.html I hereby ask for input on it. Brian I think that if someone had the desire and energy to do this work, it could be done relatively easily and without much controversy, provided it was understood to be non-normative in nature. I don't consider such an effort useful enough to engage in it myself, or to actively encourage someone else to do so. But I certainly won't _discourage_ someone who's interested in spending time on such an effort. -- Jeffrey T. Hutzelman (N3NHS) [EMAIL PROTECTED] Sr. Research Systems Programmer School of Computer Science - Research Computing Facility Carnegie Mellon University - Pittsburgh, PA ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: what happened to newtrk?
Eliot, The discussion of the question you asked here seems to have been immediately sidetracked. I, at least, believe the original question is worth some community discussion and possibly a conclusion. More below. --On Tuesday, September 05, 2006 4:39 PM +0200 Eliot Lear [EMAIL PROTECTED] wrote: All, As a participant in the newtrk working group and someone who actually ran one of the only reasonably successful experiments in that group, I think the community is owed a better accounting of why WG failed, and that steps should be taken to see that such efforts do not fail in the future. The newtrk working group was chartered to revise the standards track, with an understanding that the current one is demonstrably not working as it should. ... However, the end result was that we had a working group chartered to do a specific task, do the task, and then have the work rejected. Quite frankly we don't have the resources to have that happen. I suspect anyone who had any involvement with that group will be extremely reticent to work on process proposals in the future, because they will assume that any given IESG is likely to reject any output. That is certainly the conclusion to which I, and at least some others who put energy into Newtrk and related work, have come. What I would like to know is what we could have done to prevent this from happening. Was the newtrk charter not sufficiently narrow to accomplish a task for which there was community consensus? Is a working group the appropriate place to make process changes? I am leaning heavily toward no on that last one. Should the IESG simply both propose and dispose? Perhaps the IAB has a role of proposing changes. I do not believe that WG-or-not is the key issue, even though I continue to have doubts as to whether a regular WG is adequately representative of the IETF participants impacted by significant process changes to be the ideal final review mechanism. Within limits, a WG may be a reasonable mechanism for proposing approaches and solutions and/or working through details of them, but we do need to be careful about creating WGs that are dominated by would-be process experts with little actual experience in the technical work of the IETF. Eventually, as I wrote in a previous note, we must circle back and actually fix the standards process to reflect reality. But how that is to be done remains to me an open question. I think the lesson to be drawn is that one that you have implied above: it is unlikely that any serious process changes will succeed as long as the IESG is the body that must approve such changes. This is not a criticism of any particular IESG or IESG member. Instead, it is the result of observation and experience: the IESG is appointed to do a particular job, is under huge pressures to do that job, and tends to train new members about how that job works. Any new model of the job to be done naturally leads to a very conservative reaction: doing things differently will always involve more work, if only in developing new detailed procedures and non-disruptive transition mechanisms, and we tend (properly) to select IESG members whose primary commitment is to the short-term objective of processing as much of the IETF's technical work as possible. The consequence is that it is unreasonable to expect the IESG to evaluate and agree to non-trivial process changes. Even if I had not been convinced of that after the Newtrk meltdown, the recent response to draft-klensin-norm-ref would have been completely persuasive. That response isn't wrong -- both the model in RFC 3933 and the I-D were written to give the IESG the discretion to reach the conclusion they reached -- but it shows a response so conservative as to make the writing of the proposal not worth the effort, at least IMO. That, I think, leaves two questions for the community: (1) How should things be arranged so that the IESG does not make the final decisions about process changes? And, (2) If the community can reach some rough consensus on the answer to that question, how does one get the IESG --which has not been sympathetic to efforts to reduce their perceived authority-- to approve it or how does it get adopted without IESG approval. I am not yet to the point that I would try to get the community to convince the Nomcom that a promise to approve a proposal to transfer approval of process changes away from the IESG should be a precondition for appointment (or reappointment) to the IESG but, if the community is serious about process changes, it could come to that. Just my opinion john ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: what happened to newtrk?
John C Klensin wrote: Eliot, The discussion of the question you asked here seems to have been immediately sidetracked. I, at least, believe the original question is worth some community discussion and possibly a conclusion. More below. Thank you, John. You've caught the jist of my concerns quite well. I am a bit reticent at this point to propose changes. I think we have a problem. Mike Heard had a reasonable point of view as well, which is that perhaps the newtrk charter wasn't quite as constrained as it needed to be for this kind of change. I do think at this point and time we are not making the best use of the IAB, but again, I don't know what changes I would propose to effect change. I do wish we could have a broader discussion. Eliot ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: what happened to newtrk?
John, While I agree that the IESG unlikely to change how it behaves I still don't think you have explained why it should resist changing the process so that it describes how it behaves in actual practice. Phill -Original Message- From: John C Klensin [mailto:[EMAIL PROTECTED] Sent: Tuesday, September 12, 2006 2:51 PM To: Eliot Lear Cc: IETF Discussion Subject: Re: what happened to newtrk? Eliot, The discussion of the question you asked here seems to have been immediately sidetracked. I, at least, believe the original question is worth some community discussion and possibly a conclusion. More below. --On Tuesday, September 05, 2006 4:39 PM +0200 Eliot Lear [EMAIL PROTECTED] wrote: All, As a participant in the newtrk working group and someone who actually ran one of the only reasonably successful experiments in that group, I think the community is owed a better accounting of why WG failed, and that steps should be taken to see that such efforts do not fail in the future. The newtrk working group was chartered to revise the standards track, with an understanding that the current one is demonstrably not working as it should. ... However, the end result was that we had a working group chartered to do a specific task, do the task, and then have the work rejected. Quite frankly we don't have the resources to have that happen. I suspect anyone who had any involvement with that group will be extremely reticent to work on process proposals in the future, because they will assume that any given IESG is likely to reject any output. That is certainly the conclusion to which I, and at least some others who put energy into Newtrk and related work, have come. What I would like to know is what we could have done to prevent this from happening. Was the newtrk charter not sufficiently narrow to accomplish a task for which there was community consensus? Is a working group the appropriate place to make process changes? I am leaning heavily toward no on that last one. Should the IESG simply both propose and dispose? Perhaps the IAB has a role of proposing changes. I do not believe that WG-or-not is the key issue, even though I continue to have doubts as to whether a regular WG is adequately representative of the IETF participants impacted by significant process changes to be the ideal final review mechanism. Within limits, a WG may be a reasonable mechanism for proposing approaches and solutions and/or working through details of them, but we do need to be careful about creating WGs that are dominated by would-be process experts with little actual experience in the technical work of the IETF. Eventually, as I wrote in a previous note, we must circle back and actually fix the standards process to reflect reality. But how that is to be done remains to me an open question. I think the lesson to be drawn is that one that you have implied above: it is unlikely that any serious process changes will succeed as long as the IESG is the body that must approve such changes. This is not a criticism of any particular IESG or IESG member. Instead, it is the result of observation and experience: the IESG is appointed to do a particular job, is under huge pressures to do that job, and tends to train new members about how that job works. Any new model of the job to be done naturally leads to a very conservative reaction: doing things differently will always involve more work, if only in developing new detailed procedures and non-disruptive transition mechanisms, and we tend (properly) to select IESG members whose primary commitment is to the short-term objective of processing as much of the IETF's technical work as possible. The consequence is that it is unreasonable to expect the IESG to evaluate and agree to non-trivial process changes. Even if I had not been convinced of that after the Newtrk meltdown, the recent response to draft-klensin-norm-ref would have been completely persuasive. That response isn't wrong -- both the model in RFC 3933 and the I-D were written to give the IESG the discretion to reach the conclusion they reached -- but it shows a response so conservative as to make the writing of the proposal not worth the effort, at least IMO. That, I think, leaves two questions for the community: (1) How should things be arranged so that the IESG does not make the final decisions about process changes? And, (2) If the community can reach some rough consensus on the answer to that question, how does one get the IESG --which has not been sympathetic to efforts to reduce their perceived authority-- to approve it or how does it get adopted without IESG approval. I am not yet to the point that I would try to get the community to convince the Nomcom that a promise to approve a proposal
Re: what happened to newtrk?
On Tue, 12 Sep 2006 22:24:50 +0200, Eliot Lear [EMAIL PROTECTED] wrote: John C Klensin wrote: Eliot, The discussion of the question you asked here seems to have been immediately sidetracked. I, at least, believe the original question is worth some community discussion and possibly a conclusion. More below. Thank you, John. You've caught the jist of my concerns quite well. I am a bit reticent at this point to propose changes. I think we have a problem. Mike Heard had a reasonable point of view as well, which is that perhaps the newtrk charter wasn't quite as constrained as it needed to be for this kind of change. I do think at this point and time we are not making the best use of the IAB, but again, I don't know what changes I would propose to effect change. I do wish we could have a broader discussion. The IAB spends -- or spent; I haven't been on the IAB since 2000 -- an amazing percentage of its time on layer 9 issues. Most IAB members dislike that (and some ignore that part), but much of it seemed to be stuff that the IETF had to do. I suppose we could ask the Nomcom to select an IPB or an IPSG as well, but all things considered (and as one of the former stuckees) I think we're better off if our political relations were handled by folks with technical clue -- that is why the IETF's participation is generally sought. --Steven M. Bellovin, http://www.cs.columbia.edu/~smb ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: what happened to newtrk?
--On Tuesday, 12 September, 2006 13:26 -0700 Hallam-Baker, Phillip [EMAIL PROTECTED] wrote: John, While I agree that the IESG unlikely to change how it behaves I still don't think you have explained why it should resist changing the process so that it describes how it behaves in actual practice. You are correct. I did not address that issue, partially because, personally, I do not consider it very important. While documenting what we are doing would be nice, I don't believe the community is completely happy with what we are doing and, hence, that energy would be better spent figuring out how to move forward. That said, if I were on the IESG, with many demands on my time, I'd have serious doubts about the value of time spent getting agreement on exactly what the current procedures are, probably contraining behavior to those procedures, etc. In addition, I'd have doubts, based on experience, that any effort to fully document existing procedures would not result in a debate about whether those procedures are appropriate (one which, as you know, is ongoing already), tuning or modifying those procedures, etc. So one might rationally conclude, first, that fully describing the behavior as practiced would be nearly impossible and, second, that it wouldn't be worth the effort. Making improvements is another matter; it is at least possible to justify that effort as worthwhile if the proposed improvements really are improvements. --On Tuesday, 12 September, 2006 16:32 -0400 Steven M. Bellovin [EMAIL PROTECTED] wrote: The IAB spends -- or spent; I haven't been on the IAB since 2000 -- an amazing percentage of its time on layer 9 issues. Most IAB members dislike that (and some ignore that part), but much of it seemed to be stuff that the IETF had to do. I suppose we could ask the Nomcom to select an IPB or an IPSG as well, but all things considered (and as one of the former stuckees) I think we're better off if our political relations were handled by folks with technical clue -- that is why the IETF's participation is generally sought. Steve, I agree about layer 9 issues and the problems associated both with investing the IAB in them and in seeking other alternatives. But I see process change issues --ones that impact how the IETF operates and makes decisions-- as somewhat different from external political and policy issues. The impact of decisions about them is different, as is the kind of expertise needed to evaluate proposals against how the people who do work in the IETF do, or might optimally do, that work. That said, the only suggestion I've made over the last several years about shifting process approval responsibility to the IAB involved having that shift be temporary and part of a process of figuring out some other model. I don't consider the IAB a good long-term solution for process review and approval, partially because I prefer an IAB that has a bit of distance from and a different perspective on, active IETF standards-development and decision-making (that view is probably controversial). But, if we are going to make process changes we need, IMO, to get unstuck from a situation in which the IESG is both naturally resistant to, or at least very conservative about, such changes and is the group that makes decisions about whether they are appropriate for the community. It _might_ be plausible to make the IAB --just because it is there-- the review and consensus-evaluation body for a single new proposal or package of proposals about how we make process decisions going forward. The only alternative I can see (other than bloody revolution) involves the selection of some sort of constitutional convention body. I fear that such a body would not be close enough to the IETF's technical work and how it gets done to produce a satisfactory result that optimizes that work, rather than elegant process models for those who like process models. john ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: what happened to newtrk?
On Tuesday, September 12, 2006 06:06:08 PM -0400 John C Klensin [EMAIL PROTECTED] wrote: You are correct. I did not address that issue, partially because, personally, I do not consider it very important. While documenting what we are doing would be nice, I don't believe the community is completely happy with what we are doing and, hence, that energy would be better spent figuring out how to move forward. I think that if people are interested in documenting what we are currently doing, the most effective way to do that is for someone to write one or more informational, descriptive internet-drafts that attempt to document the current state of affairs, and then ask for input on them. The author(s) of such documents should feel free to reject input suggesting that the process should be changed as out of scope. I think that if someone had the desire and energy to do this work, it could be done relatively easily and without much controversy, provided it was understood to be non-normative in nature. I don't consider such an effort useful enough to engage in it myself, or to actively encourage someone else to do so. But I certainly won't _discourage_ someone who's interested in spending time on such an effort. -- Jeffrey T. Hutzelman (N3NHS) [EMAIL PROTECTED] Sr. Research Systems Programmer School of Computer Science - Research Computing Facility Carnegie Mellon University - Pittsburgh, PA ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: what happened to newtrk?
John C Klensin wrote: [skipping many good points] I am very much in favor of high specification quality. [...] we should aspire to specifications that are absolutely clear about their strengths and weaknesses _especially_ where security and basic network operations (e.g., scalability) are concerned. Yes, e.g. STD 61 (2289, OTP) is ready in some way, and somebody cared to submit an implementation report. For the new SASL I've not heard that anybody intends to SASLprep 2444. Whatever that means, if used instead of CRAM-MD5 it wouldn't be _that_ much better wrt the dictionary attack discussed here before. For a CRAM-MD5 AS it boils down to if all you want is not sending passwords in the clear you could ... BUT One detail I like about OTP and CRAM-MD5 is that they need only 3 parameters where 2831 takes 9 or 10. A future 2026bis could make it clearer that anybody may submit an implementation / interoperability report, not only the original authors / editors. BTW, RFC 4234 to STD, anybody ? And of course RFC 4409 to STD, there I'd prefer to explicitly mention the Resent-* case in its section 8.1, and that would need a minor editorial update (+ a new informative reference). And if anybody insists on it add a caveat about CRAM-MD5 etc. Frank ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: what happened to newtrk?
--On Friday, 08 September, 2006 22:09 -0700 C. M. Heard [EMAIL PROTECTED] wrote: On Fri, 8 Sep 2006, John C Klensin wrote: --On Thursday, 07 September, 2006 20:11 -0400 Sam Hartman wrote: OK. I read RFC 2026 as giving the IESG the latitude to make a judgment of the technical quality of a protocol (and the TS) when advancing along the standards track. I'd always assumed that the IESG should include factors like security in that determination--not just interoperability. Heck, I even assumed it was reasonable to have a higher bar for spec clarity at DS than PS. I think both of those (spec quality and factors like security) are useful and important. But 2026 seems very clear on this subject: 4.1.2 Draft Standard A specification from which at least two independent and interoperable implementations from different code bases have been developed, and for which sufficient successful operational experience has been obtained, may be elevated to the Draft Standard level. For the purposes of this section, interoperable means to be functionally equivalent or interchangeable components of the system or process in which they are used. [...] Elevation to Draft Standard is a major advance in status, indicating a strong belief that the specification is mature and will be useful. [ ... ] If the documents meet the published requirements for Draft, then they should be published at Draft. The recent practice in the IESG appears to have been closer to if we don't like it or would not recommend it, it should not be published at all, especially on the standards track no matter how widely interoperable implementations are deployed. I can find little support for that position in RFC 2026 or elsewhere. I think that Mr Hartman is right and that Mr Klensin is mistaken. I don't think this is even a question of right or wrong (mistaken), but of interpretation and appropriateness. There are also some issues about when the exercise of judgment and discretion turns into either abuse of process or substituting IESG judgment for the judgment or the community or that of the marketplace.I am also trying to suggest that, where these sections of 2026 to be reopened, there might be pressures to narrow IESG authority in addition to those for broadening it, and for reasons exactly connected to those issues about the appropriate range of discretion. I note that, in the middle of the decruft process, at least two proposals were introduced (one less formally than the other) to require giving more weight to marketplace decisions, rather than IESG judgment, in determining which specifications were advanced. Those proposals were not debated and rejected by the community. Instead, they simply disappeared after it became clear that the IESG would not be receptive to any reduction of the authority of their opinions. That may have been the right decision, but the community never had a chance to make it. As I read it, section 6 of RFC 2026 not only gives the IESG the latitude to make a judgment of the technical quality of a specification when advancing it along the standards track, but actually REQUIRES the IESG to do so: |6. THE INTERNET STANDARDS PROCESS | | The mechanics of the Internet Standards Process involve decisions of | the IESG concerning the elevation of a specification onto the | standards track or the movement of a standards-track specification | from one maturity level to another. Although a number of reasonably | objective criteria (described below and in section 4) are available | to guide the IESG in making a decision to move a specification onto, | along, or off the standards track, there is no algorithmic guarantee | of elevation to or progression along the standards track for any | specification. The experienced collective judgment of the IESG | concerning the technical quality of a specification proposed for | elevation to or advancement in the standards track is an essential | component of the decision-making process. ... From my point of view, we have two issues here. The first is that I see the IESG as the interpreter of community consensus rather than as an authority in itself. This text sounds remarkably like self-sufficient authority. I don't believe that was the community's intent when 2026 was written. More important, as time goes on and the composition of the IESG and the community of active IETF participants shifts, I think it has become less appropriate. The second is a meta-issue about what the above means by technical quality. Certainly the clarity of the specification is a key issue (and is is, as you point out, called out in 6.1.2). But our traditional tool for both evaluating and refining document quality is independent interoperable implementations. While documents can always be improved, if such implementations were created without
Re: RFC 2195 (Was: what happened to newtrk?)
Jeffrey Hutzelman wrote: A thinly veiled description of an actual situation is not a hypothetical. Okay, pick a better adjective, I tried to make the point that there is a pattern in these real examples: A technology where only experts know how it works, while users get the choice OK or CANCEL. The spec was already quite clear on this. Yes. Some wrote that the bug was to press the reset button, others proposed to use another order of the list, but actually it was a race condition, a communication problem between some participants. Did you sell a certificate to [insert bank or celebrity] ? - Yes - oops. The change you are referring to in GSS-API v2u1 (RFC2743) is hardly to an obscure default I'm only a lurker on the SASL list, and from my POV it was an obscure issue. The implementor tried to get it right, and used the library as is, updating it when updates where available. I can understand that he's upset about this issue, he took that updated library in good faith, checking the relevant RFCs. Not your (collective) fault, but a part of the pattern, even the implementors are lost if the complete system is too complex. Sometimes it has a funny side, I liked the road to nowhere: http://www.proper.com/lookit/hash-futures-panel-notes.html [other examples] I don't think I can help you with any of these. That's what the CERT folks told me, I should install OpenSSL and figure it out for myself... ;-) Download and install was fair enough, but admittedly I didn't manage to read the online manuals so far. [expired cert] Maybe your browser was broken before? Maybe the cert wasn't expired before? It wasn't (2005). I'd have to check if it is only one the known bugs in this browser (several running instances, only one of them can lock the cert.db, all others get defaults) I don't think this scenario supports your argument that documenting a protocol is better than not documenting it, because I doubt that the problem is the result of an ill-defined or underspecified protocol. My point was something in the direction of don't replace KISS by TLS unless you must. 2195 is fine for its purpose, nobody proposed to use it as the new ideal way to transmit credit card numbers. I'd guess that it is a result of an oversight on the part of the operator of that server, combined with a complete lack of anyone bothering to report the problem Possible. And you guessed correctly that I never tried to nail that last issue. For the ticket system I've given up to report it, the complete issue is too ridiculous, one user ietf password ietf can't get read access anymore, nobody knows why, [EMAIL PROTECTED] If we're talking about what happened to newtrk or what the standards process should be, then we're talking about how to designate and advance protocol specifications that _are_ being published. RFC 2195 was mainly an example, I had to pick something that I had actually implemented. For the draft I can't claim this, I haven't implemented SASLprep (maybe I'll try this later, the part yes, this is NFKC Unicode 5.0, but not 3.2 could be interesting). Frank ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: RFC 2195 (Was: what happened to newtrk?)
Christian Huitema wrote: http://www.huitema.net/talks/ietf63-security.ppt Thanks, with that hint I finally found the HTML version: http://www3.ietf.org/proceedings/05aug/slides/apparea-4/ and http://www3.ietf.org/proceedings/05aug/slides/plenaryt-1.pdf With a somewhat unusual password I wouldn't know how an attack works. You would not, but the gentle folks writing the cracking tool certainly know. Certainly I don't know where to rent the zombie for 10 cents: http://www3.ietf.org/proceedings/05aug/slides/apparea-4/sld5.htm Next slide, yes, CRAM-MD5 is *not* designed for that attack. Adding a prose version of your slides 3..6 and 13 to the security considerations of a 2195bis could improve it. Do I miss a clue, or has DIGEST-MD5 essentially the same issue ? Note that this is not related to potential weaknesses in MD5. Right, add 20% to your costs to get SHA-1, etc. How did you calculate this, how long have the rented bots to crack a given observed C/R ? Frank ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: RFC 2195 (Was: what happened to newtrk?)
From: Jeffrey Hutzelman [mailto:[EMAIL PROTECTED] On Thursday, September 07, 2006 08:12:44 PM -0700 Hallam-Baker, Phillip [EMAIL PROTECTED] wrote: The solution to this particular problem is to use SSL as the transport. IMAP and POP both support this use. It is a trivial matter to discover that IMAPS is supported using an SRV record. Of course, if you depend on this technique to determine whether TLS should be used, you are subject to a downgrade attack which not only exposes your password to a dictionary attack, but also makes it fairly simple for an attacker to gain access to the server as you _without_ carrying out such an attack. How so? The attacker cannot downgrade the server security, particularly if the server does not support unencrypted IMAP or POP. If you deploy DNSSEC the downgrade attack can be eliminated. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: RFC 2195 (Was: what happened to newtrk?)
From: Jeffrey Hutzelman [mailto:[EMAIL PROTECTED] On Thursday, September 07, 2006 08:12:44 PM -0700 Hallam-Baker, Phillip [EMAIL PROTECTED] wrote: The solution to this particular problem is to use SSL as the transport. IMAP and POP both support this use. It is a trivial matter to discover that IMAPS is supported using an SRV record. Of course, if you depend on this technique to determine whether TLS should be used, you are subject to a downgrade attack which not only exposes your password to a dictionary attack, but also makes it fairly simple for an attacker to gain access to the server as you _without_ carrying out such an attack. How so? The attacker cannot downgrade the server security, particularly if the server does not support unencrypted IMAP or POP. I don't think the lack of support for unencrypted IMAP or POP is quite sufficient. What's to stop an attacker acting as a MITM (by publishing a bogus SRV record or whatever) getting an unencypted connection and turning around and connecting to the server using encryption? Either a client key check on the server or the client requiring encyption and checking the server cert will address this, I believe. If you deploy DNSSEC the downgrade attack can be eliminated. That prevents one MITM attack vector, but there may be others. However, just because this and other attacks are real doesn't mean that there's no security gain from a setup that's subject to downgrade attacks. Often as not it is far more difficult to mount a MITM attack than it is to mount to perform passive eavesdropping. Ned ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: RFC 2195 (Was: what happened to newtrk?)
On Fri, 8 Sep 2006, Ned Freed wrote: I don't think the lack of support for unencrypted IMAP or POP is quite sufficient. What's to stop an attacker acting as a MITM (by publishing a bogus SRV record or whatever) getting an unencypted connection and turning around and connecting to the server using encryption? That's exactly the scenario I was thinking of. However, just because this and other attacks are real doesn't mean that there's no security gain from a setup that's subject to downgrade attacks. Often as not it is far more difficult to mount a MITM attack than it is to mount to perform passive eavesdropping. True. However, spoofing a DNS response is often considerably easier than mounting a MITM attack at the network layer. Phill is correct that deploying DNSSEC helps with this. However, I don't see wide deployment of DNSSEC today, and I'm not holding my breath. Please, feel free to prove my pessimism unwarranted. -- Jeff ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: RFC 2195 (Was: what happened to newtrk?)
From: Ned Freed [mailto:[EMAIL PROTECTED] The attacker cannot downgrade the server security, particularly if the server does not support unencrypted IMAP or POP. I don't think the lack of support for unencrypted IMAP or POP is quite sufficient. What's to stop an attacker acting as a MITM (by publishing a bogus SRV record or whatever) getting an unencypted connection and turning around and connecting to the server using encryption? Hopefully one would deploy DNSSEC. Either a client key check on the server or the client requiring encyption and checking the server cert will address this, I believe. If one has DNSSEC one could also use a DNS distributed key to secure the server key. That avoids the need to have that particular cert issued by a Trusted Third Party. If you deploy DNSSEC the downgrade attack can be eliminated. That prevents one MITM attack vector, but there may be others. I have a somewhat larger proposal. I think that it is in fact possible to offer a very robust level of security. The discussion here is missing the point though. Most security schemes fail because they are not used and they are not used because the administrative configuration process is utterly abysmal. The reason that most WiFi access points are not secured has nothing to do with the insecurity of WEP - which is fixable. Fixing security holes is easy. Fixing usability holes is very hard, particularly because none of us are psychologists and few of us are likely to want to learn about it. Therefore the security strategy we should be pushing for is going to be one that requires the minimum number of user interactions while providing the user with the most direct information that allows them to be safe. We currently have an abysmal security infrastructure in the Internet and this is not going to be solved just by everyone deploying IPSEC. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: RFC 2195 (Was: what happened to newtrk?)
Next slide, yes, CRAM-MD5 is *not* designed for that attack. That is my point. We should not, in 2006, standardize security methods that are not robust against a fairly well known attack. Adding a prose version of your slides 3..6 and 13 to the security considerations of a 2195bis could improve it. Do I miss a clue, or has DIGEST-MD5 essentially the same issue ? DIGEST-MD5 is somewhat more robust than CRAM-MD5 because it incorporates protection against chosen plaintext attacks. If an attacker can fake a server and send a chosen challenge, then the dictionary attack can be accelerated with a pre-computed catalog. However, current dictionary attacks do not need to rely on pre-computation, since a modern PC can compute more than a million MD5 hashes per second. So, yes, DIGEST-MD5 has essentially the same issue. -- Christian Huitema ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: what happened to newtrk?
--On Thursday, 07 September, 2006 20:11 -0400 Sam Hartman [EMAIL PROTECTED] wrote: John == John C Klensin [EMAIL PROTECTED] writes: John Actually, that topic opens up one of the fundamental issues John with our standards process ... one where better definition John and clear community consensus is, IMO, needed. Measured by John our documented criteria, 2195 exists in multiple independent John implementations, has been widely deployed, and is considered John useful by many of those who are using it. Current thinking John in the security area is that it isn't much better than the John use of clear-text passwords, but our formal definitions of John the requirements for Draft Standard don't require that we John recommend the use of the protocol involved: Draft and Not John Recommended are perfectly consistent. John, in principle I agree with you, but I'll point out there is a huge lack of clarity around ASes. It's hard for example to find ASes for a given TS, and it would confuse people if something were a draft standard and not recommended at the same time. This is particularly true given factors such as the rfc-index only lists the position along the standards track, not the requirements level of the associated AS. At the risk of singing an old song again: (1) If the IESG (or anyone else) doesn't believe that ASs are the solution to any problem we have, then let's see a proposal to either make them into such a solution or get rid of them. (2) Newtrk tried to address this particular issue, with ISDs as a product. The IESG didn't like it, nor were there any real suggestions about how the issues the IESG saw could be resolved (or what resolutions would meet the IESG's expectations/desires). Perhaps I should not infer from that that the IESG didn't see a problem worth solving, but... (3) If the IESG and IAB don't like the contents of the rfc-index, it is my believe that it has always been within their authority to negotiate different formats and/or contents with the RFC Editor and that the RFC Editor has generally been responsive to such requests. I note that, if there was any attempt to get a new format, or requirements to comply with a prospective new format design effort, into the RFC Editor RFP, it somehow seems to have missed me. I would be all for draft but not recommended if we got to a point where the users of our documents would understand what that meant. Your belief that they do not (I'd suggest that there is little evidence that most users of our documents understand the real difference between Proposed and Draft either) is not, I believe, justification for nullifying the provisions of RFC 2026 and, instead, substituting your (or the IESG's) judgment for them. I'm all for experiments--even ISD-like experiments--in organizing our metadata and descriptions of standards so people could get these points. I don't have time to work on those experiments myself and so until they succeed my preference is to be conservative. Our interpretation of conservative differs a bit in this case. Given the identified problems with reliance on clear-text challenge-response techniques, my version of conservative would involve publishing a document that recognizes the wide deployment and use of protocols of this sort but that carefully explains (perhaps partially by reference, rather than inclusion of everything in-line) the risks and limitations associated with relying on them in unprotected environments. If one does not believe in recommendation levels, then it becomes an interesting question about what maturity level should be assigned to such a document, but I do not believe we have a model for Informational documents superceding (Obsoletes) a standards-track document. John It is not consistent with our published policies as I read John them to refuse to promote it to Draft simply because there John is general feeling that security technology has passed it John by. But that is, I think, exactly what would happen today John if the protocol were proposed for advancement. OK. I read RFC 2026 as giving the IESG the latitude to make a judgment of the technical quality of a protocol (and the TS) when advancing along the standards track. I'd always assumed that the IESG should include factors like security in that determination--not just interoperability. Heck, I even assumed it was reasonable to have a higher bar for spec clarity at DS than PS. I think both of those (spec quality and factors like security) are useful and important. But 2026 seems very clear on this subject: 4.1.2 Draft Standard A specification from which at least two independent and interoperable implementations from different code bases have been developed, and for which sufficient successful operational experience has been obtained, may be elevated to the Draft Standard level. For the purposes of
Re: RFC 2195 (Was: what happened to newtrk?)
Christian Huitema wrote: yes, DIGEST-MD5 has essentially the same issue. If the SASL folks want their very own decruft experiment they'd have to update RFCs 2244, 2645, 3013 (a BCP), check ESMTPA in 3848, do something about 2617, and probably some more RFCs. DIGEST-MD5 and OTP are registered as common, not only limited like CRAM-MD5. Frank ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: RFC 2195 (Was: what happened to newtrk?)
From: Ned Freed [mailto:[EMAIL PROTECTED] The attacker cannot downgrade the server security, particularly if the server does not support unencrypted IMAP or POP. I don't think the lack of support for unencrypted IMAP or POP is quite sufficient. What's to stop an attacker acting as a MITM (by publishing a bogus SRV record or whatever) getting an unencypted connection and turning around and connecting to the server using encryption? Hopefully one would deploy DNSSEC. Indeed, although I have to say that in my experience DNSSEC deployments are rare. I wish it were otherwise but that's been my observation. As you have pointed out elsewhere, the necessary impetus to deploy doesn't seem to exist. Either a client key check on the server or the client requiring encyption and checking the server cert will address this, I believe. If one has DNSSEC one could also use a DNS distributed key to secure the server key. Sure, that would be one way to do it, although AFAIK there aren't specifications for how to do this in an interoperable way in place right now. That avoids the need to have that particular cert issued by a Trusted Third Party. Indeed it does, which would be very nice indeed. If you deploy DNSSEC the downgrade attack can be eliminated. That prevents one MITM attack vector, but there may be others. I have a somewhat larger proposal. I think that it is in fact possible to offer a very robust level of security. The discussion here is missing the point though. Most security schemes fail because they are not used and they are not used because the administrative configuration process is utterly abysmal. The reason that most WiFi access points are not secured has nothing to do with the insecurity of WEP - which is fixable. I've heard this characterized as designed for security without being designed for usability. This is a trap we're caught in that we absolutely must break free of if the security services we design are to have real utility. The trouble is you have to do both at the same time and as part of the initial design. We've shifted from doing neither at that point and trying to add security after the fact (which is rarely very satisfactory) to being fairly good at baking the security in from the start but not the usability. The result is lots of people simply refuse to use the security capabilities we do have. Fixing security holes is easy. Fixing usability holes is very hard, particularly because none of us are psychologists and few of us are likely to want to learn about it. Indeed. Neither the psych crowd nor the human factors engineering crowd (which I guess really amounts to a form of applied industrial psych) appear to be well represented here. I confess I have no idea how to change this. Therefore the security strategy we should be pushing for is going to be one that requires the minimum number of user interactions while providing the user with the most direct information that allows them to be safe. Sounds right to me. We currently have an abysmal security infrastructure in the Internet and this is not going to be solved just by everyone deploying IPSEC. It's abysmal in the sense that the focus has been on getting the best possible security without regard to whether or not the result can actually be used by anyone short of an expert. But yes, I agree that a shift of focus is urgently needed. Ned ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: RFC 2195 (Was: what happened to newtrk?)
From: Ned Freed [mailto:[EMAIL PROTECTED] Indeed, although I have to say that in my experience DNSSEC deployments are rare. I wish it were otherwise but that's been my observation. As you have pointed out elsewhere, the necessary impetus to deploy doesn't seem to exist. I doubt that this will remain the case if I get my way with DNS policy. People outside core DNS infrastructure providers are unlikely to deploy security mechanism for an existing infrastructure until they are convinced that there is a very serious need to do so. Unless the role of the DNS changes that is only likely to occur if there is a very significant event. There are two benefits to deploying a comprehensive DNS based policy infrastructure: 1) It will make the Internet much easier to administer and use 2) It will motivate deployment of security infrastructure for DNS providing a single ended adoption benefit to early adopters before critical mass is reached to drive the network effect. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: what happened to newtrk?
--On Wednesday, 06 September, 2006 13:35 +0200 Frank Ellermann
[EMAIL PROTECTED] wrote:
Brian E Carpenter wrote:
3464 is already DS according to the RFC Index.
Good, the process works, unlike my memory: I meant 3834,
a few days ago I wrote 3864 instead of 3834 on another
list, so that's the third attempt: 3834.
[interoperability report]
if {all mandatory and optional features shown to
interoperate}
then {send a request to reclassify RFC 2195 to the IESG}
So far it sounds simple (for the 2195 example). I test it,
thanks for info.
Actually, that topic opens up one of the fundamental issues with
our standards process ... one where better definition and clear
community consensus is, IMO, needed. Measured by our documented
criteria, 2195 exists in multiple independent implementations,
has been widely deployed, and is considered useful by many of
those who are using it. Current thinking in the security area
is that it isn't much better than the use of clear-text
passwords, but our formal definitions of the requirements for
Draft Standard don't require that we recommend the use of the
protocol involved: Draft and Not Recommended are perfectly
consistent.
It would also be completely consistent with our published
policies to require that a Draft Standard offspring of 2195
contain explicit text in the Security Considerations section
that describes the attack, recommends that the technique of 2195
be used only over an encrypted tunnel or on a protected network,
reflects on whether it offers any real advantage over plain text
passwords in those situations, and recommends something else.
It is not consistent with our published policies as I read them
to refuse to promote it to Draft simply because there is general
feeling that security technology has passed it by. But that is,
I think, exactly what would happen today if the protocol were
proposed for advancement.
john
p.s. While I'm the first-listed author of 2195, I don't hold any
particular affection for it. It was written because it seemed
to be necessary at the time and I could pull a group together to
do the work. The comments above are hence independent of any
personal interest in keeping 2195 alive -- I have none.
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
RFC 2195 (Was: what happened to newtrk?)
At 01:36 PM 9/7/2006, John C Klensin wrote: Actually, that topic opens up one of the fundamental issues with our standards process ... one where better definition and clear community consensus is, IMO, needed. Measured by our documented criteria, 2195 exists in multiple independent implementations, has been widely deployed, and is considered useful by many of those who are using it. In addition to security concerns, it must be stated that implementations of RFC 2195 suffer from interoperability problems due to its failure to specify a character set/encoding and normalization/preparation algorithm for the password string. The WG decided it was better to document current implementations of CRAM-MD5 than to rework CRAM-MD5 to address these and other issues, and to do so on the Informational track. If you have something new to add to the discussion of revision approach taken within the SASL WG, you (and others) are welcomed to comment on the SASL WG list. The document will be in WG Last Call soon. -- Kurt, SASL WG co-chair ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: what happened to newtrk?
John C Klensin wrote: that topic opens up one of the fundamental issues with our standards process ... one where better definition and clear community consensus is, IMO, needed. Fundamental and consensus sounds dangerous, see subject. 2195 exists in multiple independent implementations, has been widely deployed, and is considered useful by many of those who are using it. Yes, easy to implement, better than PLAIN (outside of TLS). Current thinking in the security area is that it isn't much better than the use of clear-text passwords Maybe they'll prove this in an understandable way, or offer it as their opinion. I could also offer an opinion about 6 to 10 parameters of DIGEST-MD5, its RFC 2069 fallback under certain (TBD) conditions, the proposed backslash canonicalization, etc. the requirements for Draft Standard don't require that we recommend the use of the protocol involved: Draft and Not Recommended are perfectly consistent. Good, let's keep say STD 20 as is, all its about 57 lines. :-) Frank http://purl.net/xyzzy/home/test/cram.xml ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: RFC 2195 (Was: what happened to newtrk?)
--On Thursday, 07 September, 2006 14:31 -0700 Kurt D. Zeilenga [EMAIL PROTECTED] wrote: At 01:36 PM 9/7/2006, John C Klensin wrote: Actually, that topic opens up one of the fundamental issues with our standards process ... one where better definition and clear community consensus is, IMO, needed. Measured by our documented criteria, 2195 exists in multiple independent implementations, has been widely deployed, and is considered useful by many of those who are using it. In addition to security concerns, it must be stated that implementations of RFC 2195 suffer from interoperability problems due to its failure to specify a character set/encoding and normalization/preparation algorithm for the password string. The WG decided it was better to document current implementations of CRAM-MD5 than to rework CRAM-MD5 to address these and other issues, and to do so on the Informational track. If you have something new to add to the discussion of revision approach taken within the SASL WG, you (and others) are welcomed to comment on the SASL WG list. The document will be in WG Last Call soon. Kurt, I think we have a small misunderstanding here. Let me say more clearly and briefly what I tried to say in a prior note with regard to the substance of the CRAM-MD5 spec: * I have basically lost interest in CRAM-MD5. They were never important to me except as a no infrastructure, better than plain text demonstration, I'm not using them now, etc. So I wish the SASL WG the very best with whatever you decide to do with it. * There is a more general principle about how we define and process maturity levels for which 2195 may or may not be a good example. That one has to do with whether a specification is good enough for interoperable implementations and whether people care to create those implementations. It also has to do with whether one needs to bring every old document up to ever-rising contemporary standards before approving it. My note was really addressed to that principle and not to 2195 and/or the SASL WG. The second issue is closely related to some issues that Newtrk took a careful look at and, arguably, reached some measure of consensus about. And that is where this thread started. Now, having made that observation, one more comment: It is, as far as I'm concerned, perfectly reasonable for the SASL WG to say CRAM-MD5 is too weak for use today and is badly designed for SASL use because it assumed net-ASCII rather than addressing internationalization and other character sets and then either ignore it completely as a SASL method, document a SASL CRAM-MD5 as informational, or repeat the recent stunt of having a specification published as initially historic. However, 2195 is not, itself, a SASL method and there is nothing in the procedural rules as I understand them that permits the SASL WG to de-standardize it (you could write any of several styles of document that would designate it as not recommended or even historic but such documents had best be in your Charter and Last Called as doing that). Now, suppose someone comes along who _likes_ the non-SASL incarnation of CRAM-MD5 in 2195. Let's call this hypothetical person nobody to avoid casting aspersions on Frank. Nothing in our current procedures prevents him, at any time, from preparing an interoperability report on 2195-specified CRAM-MD5, pointing out that there are many deployed interoperable implementations, and asking that 2195 be reclassified (or a 2195bis be published) as a Draft Standard. If nobody were so inclined, I would expect him to protest any effort on the part of the SASL WG to deprecate 2195 itself and to appeal any decision to block the advancement of 2195[bis] to Draft Standard if that decision involved either the SASL WG's work (at least unless the WG gets a charter item to write an Applicability Statement for 2195 and starts serious work on it) or the assertion that CRAM-MD5 was not up to today's requirements for the public Internet.I wouldn't join nobody in putting significant work into those efforts because I don't care enough... although I might get excited about the principles if it came to an appeal. best, john, sometime procedural troublemaker ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: RFC 2195 (Was: what happened to newtrk?)
On Thursday, September 07, 2006 07:07:51 PM -0400 John C Klensin [EMAIL PROTECTED] wrote: However, 2195 is not, itself, a SASL method and there is nothing in the procedural rules as I understand them that permits the SASL WG to de-standardize it (you could write any of several styles of document that would designate it as not recommended or even historic but such documents had best be in your Charter and Last Called as doing that). To the extent that SASL is the successor to the original extensible authentication framework contained in IMAPv4, yes, CRAM-MD5 is a SASL mechanism. The cross-references don't explicitly point out that RFC obsoletes RFC1731, but it seems clear that was the intent. Now, suppose someone comes along who _likes_ the non-SASL incarnation of CRAM-MD5 in 2195. Let's call this hypothetical person nobody to avoid casting aspersions on Frank. Nothing in our current procedures prevents him, at any time, from preparing an interoperability report on 2195-specified CRAM-MD5, pointing out that there are many deployed interoperable implementations, and asking that 2195 be reclassified (or a 2195bis be published) as a Draft Standard. Well, he could ask that 2195 be advanced as-is, but I would expect such an effort to fail, as that version has turned out to be somewhat underspecified. Multiple interoperable implementations is not the _old_ criteria for advancement; it is necessary but not sufficient(*). Given that the SASL WG has an explicit charter item to produce a revised TS for CRAM-MD5, with RFC 2195 as a starting point, I would expect any effort to do so outside of that WG to meet with very strong resistance. As Kurt has noted, the WG is nearly finished its work on that item, and the resulting draft will be in Last Call soon. The working group decided, due to a variety of considerations, not to pursue publication of the new document on the standards track, and instead to ask that it be published as Informational. However, the decision as to whether to publish that document and what status to assign it belongs to the IESG, not the working group. IMHO, an argument that it should be assigned a status other than that requested by the working group would be an appropriate subject for a Last Call comment. If nobody were so inclined, I would expect him to protest any effort on the part of the SASL WG to deprecate 2195 itself Why? That working group's charter clearly includes an item to produce an updated specification for CRAM-MD5, and it seems obvious that the intent is that such a new specification obsolete RFC 2195 (if it's not obvious, that's a bug in the charter; certainly everyone participating in the work has understood that to be the intent). (*) I think this is perhaps the crux of the matter. I do not believe that every old specification should be advanced along the standards track simply because it has been around a while and has multiple implementations. Advancing a specification to Draft Standard sends the signal that the IETF thinks the specification is a good idea and that people should deploy it. Protocols for which that is not the case have no business advancing toward the status of Internet Standard, *even if we thought they were good ideas when they were written*. -- Jeff ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: what happened to newtrk?
John == John C Klensin [EMAIL PROTECTED] writes: John Actually, that topic opens up one of the fundamental issues John with our standards process ... one where better definition John and clear community consensus is, IMO, needed. Measured by John our documented criteria, 2195 exists in multiple independent John implementations, has been widely deployed, and is considered John useful by many of those who are using it. Current thinking John in the security area is that it isn't much better than the John use of clear-text passwords, but our formal definitions of John the requirements for Draft Standard don't require that we John recommend the use of the protocol involved: Draft and Not John Recommended are perfectly consistent. John, in principle I agree with you, but I'll point out there is a huge lack of clarity around ASes. It's hard for example to find ASes for a given TS, and it would confuse people if something were a draft standard and not recommended at the same time. This is particularly true given factors such as the rfc-index only lists the position along the standards track, not the requirements level of the associated AS. I would be all for draft but not recommended if we got to a point where the users of our documents would understand what that meant. I'm all for experiments--even ISD-like experiments--in organizing our metadata and descriptions of standards so people could get these points. I don't have time to work on those experiments myself and so until they succeed my preference is to be conservative. John It is not consistent with our published policies as I read John them to refuse to promote it to Draft simply because there John is general feeling that security technology has passed it John by. But that is, I think, exactly what would happen today John if the protocol were proposed for advancement. OK. I read RFC 2026 as giving the IESG the latitude to make a judgment of the technical quality of a protocol (and the TS) when advancing along the standards track. I'd always assumed that the IESG should include factors like security in that determination--not just interoperability. Heck, I even assumed it was reasonable to have a higher bar for spec clarity at DS than PS. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: RFC 2195 (Was: what happened to newtrk?)
On Thursday, September 07, 2006 07:48:45 PM -0400 Jeffrey Hutzelman [EMAIL PROTECTED] wrote: Well, he could ask that 2195 be advanced as-is, but I would expect such an effort to fail, as that version has turned out to be somewhat underspecified. Multiple interoperable implementations is not the _old_ criteria for advancement; it is necessary but not sufficient(*). Ugh. s/_old_/_only_/ ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: RFC 2195 (Was: what happened to newtrk?)
At 04:07 PM 9/7/2006, John C Klensin wrote: I think we have a small misunderstanding here. Let me say more clearly and briefly My message was intended to clarify why the SASL WG is pursuing an Informational recommendation for its RFC2195bis work and to redirect any comments specific to this work to the WG's list. As it was not my intent to participate in the general discussion of fundamental issues with our standards process you raise (which is why I changed the subject), and your follow-up is in the same vein, I won't comment further. -- Kurt ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: RFC 2195 (Was: what happened to newtrk?)
From: Kurt D. Zeilenga [mailto:[EMAIL PROTECTED] At 04:07 PM 9/7/2006, John C Klensin wrote: I think we have a small misunderstanding here. Let me say more clearly and briefly My message was intended to clarify why the SASL WG is pursuing an Informational recommendation for its RFC2195bis work and to redirect any comments specific to this work to the WG's list. Well, if I remember correctly, there was ample discussion of this topic during the IETF meeting in Paris -- both Steve Bellovin and I presented the issues with such techniques. Basic challenge response mechanisms like CRAM-MD5 are simply too weak to be used on the Internet. They are subject to dictionary attacks, which can retrieve the password in a very short time. They don't deserve much more than documentation for historical purpose. -- Christian Huitema ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: RFC 2195 (Was: what happened to newtrk?)
Jeffrey Hutzelman wrote: Multiple interoperable implementations is not the [only] criteria for advancement; it is necessary but not sufficient 2026 says mature, useful, well-understood, stable. A downref to SASLprep for a 2195bis DS would be odd, in that case better publish 2195bis as PS. The working group decided, due to a variety of considerations, not to pursue publication of the new document on the standards track, and instead to ask that it be published as Informational. That's the case informational obsoletes PS. How's that supposed to work wrt BCP 46, ACAP, and ODMR ? an argument that it should be assigned a status other than that requested by the working group would be an appropriate subject for a Last Call comment. Yes. That solves also Sam's problem, he can change his vote when that will happen (and if it gets traction). I think this is perhaps the crux of the matter. I do not believe that every old specification should be advanced along the standards track simply because it has been around a while and has multiple implementations. +1 for the second statement. The crux of the matter from my POV is elsewhere, CRAM-MD5 is the best existing ESMTPA mechanism in real MSAs I'm aware of. For a definition of best by sending passwords in the clear isn't state of the art. Advancing a specification to Draft Standard sends the signal that the IETF thinks the specification is a good idea and that people should deploy it. IMHO that's why CRAM-MD5 as DS would be good, maybe some implementors would care to read the second statement in its security considerations. You could add some MUSTard about this in a 2195bis draft. Frank ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: RFC 2195 (Was: what happened to newtrk?)
Christian Huitema wrote: both Steve Bellovin and I presented the issues with such techniques. Is that presentation online available somewhere ? I find the way to http://www3.ietf.org/proceedings/05aug/index.html but then I'm lost. Basic challenge response mechanisms like CRAM-MD5 are simply too weak to be used on the Internet. They are subject to dictionary attacks, which can retrieve the password in a very short time. For a password in the dictionary, and if somebody sees the challenge and the response. With a somewhat unusual password I wouldn't know how an attack works. That's my real problem: If users or worse implementors don't know how stuff works it's bad. What you end up with are some hypothetical situations like this: - a lottery with a cute crypto random algorithm, and everybody thought that it's perfect. Turns out that it's useless if the list of participants is published together with the result of the lottery. - a nice library where implementors use it as documented. A few years later the IETF changes an obscure default in the library, and again years later an IETF WG decides that the implementations using the updated library are non-conforming - an IETF ticket system where apparently nobody (and certainly not me) knows precisely why it used to work with my browser until summer 2005, but doesn't anymore - ditto a famous bookshop where I ordered books securely for years, and now I use their insecure interface, because the former doesn't work anymore for me (only their server for the secure icons, but bad enough to be unusable for orders) - a browser test site by a CERT where nobody knows why their test suite doesn't work with my browser (other test sites find no problem). - an IETF server where my browser tells me again and again that the server certificate expired 1998 (the correct behaviour for this situation as far as I can judge it), but I'm pretty sure that it did work before The good thing with CRAM-MD5 is that I know how it works, and that I have at least some ideas about its limitations. I'm not really interested to negotiate charsets (especially not if it boils down to do you want UTF-8 or give up?), security layers (for a mail submission), or hash algorithms (by picking CRAM-MD5 that point is moot). Frank ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: RFC 2195 (Was: what happened to newtrk?)
From: Christian Huitema [mailto:[EMAIL PROTECTED] From: Kurt D. Zeilenga [mailto:[EMAIL PROTECTED] At 04:07 PM 9/7/2006, John C Klensin wrote: I think we have a small misunderstanding here. Let me say more clearly and briefly My message was intended to clarify why the SASL WG is pursuing an Informational recommendation for its RFC2195bis work and to redirect any comments specific to this work to the WG's list. Well, if I remember correctly, there was ample discussion of this topic during the IETF meeting in Paris -- both Steve Bellovin and I presented the issues with such techniques. Basic challenge response mechanisms like CRAM-MD5 are simply too weak to be used on the Internet. They are subject to dictionary attacks, which can retrieve the password in a very short time. They don't deserve much more than documentation for historical purpose. HTTP-Digest was designed under the constraint that it had to be patent royalty free. At the time every form of public key cryptography including Diffie Hellman was under patent. They are only useful if you have a strong password. Unfortunately the mechanisms for password exchange that are not subject to dictionary attacks are generally considered to be encumbered as well. The solution to this particular problem is to use SSL as the transport. IMAP and POP both support this use. It is a trivial matter to discover that IMAPS is supported using an SRV record. If the will is there this is all fixable. Phill ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: RFC 2195 (Was: what happened to newtrk?)
On Friday, September 08, 2006 04:49:11 AM +0200 Frank Ellermann [EMAIL PROTECTED] wrote: That's my real problem: If users or worse implementors don't know how stuff works it's bad. What you end up with are some hypothetical situations like this: A hypothetical situation is one that could occur, but didn't. A thinly veiled description of an actual situation is not a hypothetical. - a lottery with a cute crypto random algorithm, and everybody thought that it's perfect. Turns out that it's useless if the list of participants is published together with the result of the lottery. The spec was already quite clear on this. - a nice library where implementors use it as documented. A few years later the IETF changes an obscure default in the library, and again years later an IETF WG decides that the implementations using the updated library are non-conforming The change you are referring to in GSS-API v2u1 (RFC2743) is hardly to an obscure default; in fact, it was the addition of a new capability. The API (_not_ the wire protocol) did change in a backward-incompatible way, and the spec documented that. All that was required was to read the new API specification before using a library which implements the new version of the API.(*) The SASL WG, which is not responsible for GSS-API, has not _decided_ that implementations of an old protocol using a newer library without updating to the new API are non-conforming; however, some of its individual members did point out that updating an implementation in this way can result in behavior that does not conform to that required by the original spec. What the SASL WG _did_ decide was that its updated specification, retargeted against the new GSS-API version, needed to express a requirement made necessary by the backward-incompatible change. - an IETF ticket system where apparently nobody (and certainly not me) knows precisely why it used to work with my browser until summer 2005, but doesn't anymore - ditto a famous bookshop where I ordered books securely for years, and now I use their insecure interface, because the former doesn't work anymore for me (only their server for the secure icons, but bad enough to be unusable for orders) - a browser test site by a CERT where nobody knows why their test suite doesn't work with my browser (other test sites find no problem). I don't think I can help you with any of these. - an IETF server where my browser tells me again and again that the server certificate expired 1998 (the correct behaviour for this situation as far as I can judge it), but I'm pretty sure that it did work before Maybe your browser was broken before? Maybe the cert wasn't expired before? In any case, I don't think this scenario supports your argument that documenting a protocol is better than not documenting it, because I doubt that the problem is the result of an ill-defined or underspecified protocol. Instead, I'd guess that it is a result of an oversight on the part of the operator of that server, combined with a complete lack of anyone bothering to report the problem (but that's just a guess, based on my experiences with people not bothering to report problems to me and then complaining that they never got fixed). In addition, while I mostly agree that documenting a protocol is usually better than not documenting it, I fail to see the relevance of that point in this discussion. If we're talking about what happened to newtrk or what the standards process should be, then we're talking about how to designate and advance protocol specifications that _are_ being published. If we're talking specifically about CRAM-MD5, then please bear in mind that the SASL WG decided some time ago that the correct course of action was to produce an informational document describing CRAM-MD5 as deployed, rather than to produce an incompatible updated protocol which we would not ever encourage anyone to actually deploy. For those watching from the sidelines, the updated document is draft-ietf-sasl-crammd5-07.txt. -- Jeff ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: RFC 2195 (Was: what happened to newtrk?)
On Thursday, September 07, 2006 08:12:44 PM -0700 Hallam-Baker, Phillip [EMAIL PROTECTED] wrote: The solution to this particular problem is to use SSL as the transport. IMAP and POP both support this use. It is a trivial matter to discover that IMAPS is supported using an SRV record. Of course, if you depend on this technique to determine whether TLS should be used, you are subject to a downgrade attack which not only exposes your password to a dictionary attack, but also makes it fairly simple for an attacker to gain access to the server as you _without_ carrying out such an attack. If you're going to depend on TLS to protect CRAM-MD5 or HTTP Digest or plaintext passwords, you need to know in advance that you're doing so, and properly validate the server's certificate. -- Jeff ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: RFC 2195 (Was: what happened to newtrk?)
-Original Message- From: Frank Ellermann [mailto:[EMAIL PROTECTED] Sent: Thursday, September 07, 2006 7:49 PM To: ietf@ietf.org Subject: Re: RFC 2195 (Was: what happened to newtrk?) Christian Huitema wrote: both Steve Bellovin and I presented the issues with such techniques. Is that presentation online available somewhere ? I find the way to http://www3.ietf.org/proceedings/05aug/index.html but then I'm lost. http://www.huitema.net/talks/ietf63-security.ppt For a password in the dictionary, and if somebody sees the challenge and the response. With a somewhat unusual password I wouldn't know how an attack works. You would not, but the gentle folks writing the cracking tool certainly know. From the slide deck: - If (the password) is generated by the user, it can certainly be cracked - If (the password) can be remembered by the user, it can probably be cracked Basically, host should only accept password challenges on secure channels after properly identifying the server posing the challenge. CRAM-5 fails both tests. The channel is not encrypted, and the server can be easily spoof, e.g. in a rogue Wi-Fi hot spot. Note that this is not related to potential weaknesses in MD5. The dictionary attack works just fine with other hash functions. -- Christian Huitema ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: what happened to newtrk?
Eliot Lear wrote: few if any specifications get to draft or full standard, and no review of PS had ever been done along the timelines specified in RFC 2026. Okay, let's nail this, I like to see 2195 and 3464 as DS, what exactly can I do ? Numerous proposals were made within the working group. Bert's idea was nice, establish a timeout for PS, and after that time move the PS automatically to historic. Of course we'd need a long transitional period for the PS not covered by decruft. What I would like to know is what we could have done to prevent this from happening. Don't try to replace the three stage process because it's in essence good. The detail where the IESG is supposed to do the whole work apparently needs fixing. Frank ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: what happened to newtrk?
Okay, let's nail this, I like to see 2195 and 3464 as DS,
what exactly can I do ?
3464 is already DS according to the RFC Index.
For 2195, write and publish an interoperability report, and
if {all mandatory and optional features shown to interoperate}
then {send a request to reclassify RFC 2195 to the IESG}
else {publish a draft-ellermann-2195bis with non-interoperable features
removed};
{send a request to approve it as DS to the IESG}
It's better if you find a willing AD first, and work with him or her instead
of the IESG as group.
Brian
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
RE: what happened to newtrk?
Brian,
Your description of the process omitted the most
time-consuming part:
for {each normative reference}
if {at lower maturity level AND downref acceptable}
then {write justification why downref is acceptable}
else {repeat process recursively to bring reference to DS}
A while ago Tero Kivinen wrote a script for automatically finding
the required documents; according to the script, to bring IPsec to
DS you'd need to upgrade somewhere between 70 and 400 (if I recall
correctly) documents. (The number is fuzzy because older documents
didn't separate normative and informative references. And some of
those references could be justified as acceptable downrefs or
re-classified as informative.)
Whatever the correct figure is (it's anyway dozens of documents),
it's also quite obvious that nobody will ever do the process.
For RFC 2195 (an extension to IMAP), you'd probably need to bring
IMAP to DS first.
Best regards,
Pasi
-Original Message-
From: ext Brian E Carpenter [mailto:[EMAIL PROTECTED]
Sent: 06 September, 2006 12:57
To: Frank Ellermann
Cc: ietf@ietf.org
Subject: Re: what happened to newtrk?
Okay, let's nail this, I like to see 2195 and 3464 as DS,
what exactly can I do ?
3464 is already DS according to the RFC Index.
For 2195, write and publish an interoperability report, and
if {all mandatory and optional features shown to interoperate}
then {send a request to reclassify RFC 2195 to the IESG}
else {publish a draft-ellermann-2195bis with
non-interoperable features removed};
{send a request to approve it as DS to the IESG}
It's better if you find a willing AD first, and work with him
or her instead of the IESG as group.
Brian
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
Re: what happened to newtrk?
Pasi,
That's correct. But as you presumably know, RFC 3967
offers a way of dealing with that problem. See
http://www1.tools.ietf.org/group/iesg/trac/wiki/DownrefRegistry
for results so far.
Brian
[EMAIL PROTECTED] wrote:
Brian,
Your description of the process omitted the most
time-consuming part:
for {each normative reference}
if {at lower maturity level AND downref acceptable}
then {write justification why downref is acceptable}
else {repeat process recursively to bring reference to DS}
A while ago Tero Kivinen wrote a script for automatically finding
the required documents; according to the script, to bring IPsec to
DS you'd need to upgrade somewhere between 70 and 400 (if I recall
correctly) documents. (The number is fuzzy because older documents
didn't separate normative and informative references. And some of
those references could be justified as acceptable downrefs or
re-classified as informative.)
Whatever the correct figure is (it's anyway dozens of documents),
it's also quite obvious that nobody will ever do the process.
For RFC 2195 (an extension to IMAP), you'd probably need to bring
IMAP to DS first.
Best regards,
Pasi
-Original Message-
From: ext Brian E Carpenter [mailto:[EMAIL PROTECTED]
Sent: 06 September, 2006 12:57
To: Frank Ellermann
Cc: ietf@ietf.org
Subject: Re: what happened to newtrk?
Okay, let's nail this, I like to see 2195 and 3464 as DS,
what exactly can I do ?
3464 is already DS according to the RFC Index.
For 2195, write and publish an interoperability report, and
if {all mandatory and optional features shown to interoperate}
then {send a request to reclassify RFC 2195 to the IESG}
else {publish a draft-ellermann-2195bis with
non-interoperable features removed};
{send a request to approve it as DS to the IESG}
It's better if you find a willing AD first, and work with him
or her instead of the IESG as group.
Brian
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
Re: what happened to newtrk?
C. M. Heard wrote: Having just re-read the charter, I would have to say so. I think we would have been better served if the WG had been given the much less ambitious task of producing an update of RFC 2026 that describes what we actually do. What we actually do is a one step process. Let us accept for purposes of argument that a three step process is good, as Frank Ellermann suggests. If we want to make it functional something has to change, and that means not describing what we actually do. All of this having been said, I'll repeat that I'm fine with a BCP to update 2026 to allow down references, if that clears the logjam. Well, one possibility might be to charter a design team or WG to do just that -- i.e., to take the term Best Current Practice at face value and produce of a standards process BCP that actually documents current practice. I think the IESG has to take a FAR more active role in any such effort to avoid a repeat of the failure. Eliot ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RFC 2195 (was Re: what happened to newtrk?)
Brian E Carpenter wrote:
Okay, let's nail this, I like to see 2195 and 3464 as DS,
what exactly can I do ?
3464 is already DS according to the RFC Index.
For 2195, write and publish an interoperability report,
SASL WG is revision it (draft-ietf-sasl-crammd5-07.txt).
And no, this document is not going to make it to DS due to security
concerns.
and
if {all mandatory and optional features shown to interoperate}
then {send a request to reclassify RFC 2195 to the IESG}
else {publish a draft-ellermann-2195bis with non-interoperable
features removed};
{send a request to approve it as DS to the IESG}
It's better if you find a willing AD first, and work with him or her
instead
of the IESG as group.
[EMAIL PROTECTED] wrote:
For RFC 2195 (an extension to IMAP), you'd probably need to bring
IMAP to DS first.
RFC 2195 predates formalization of the SASL framework (RFC ,
recently replaced by RFC 4422).
These days one has to bring RFC 4422 to DS instead. However this point
is moot due to the comment above.
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
Re: what happened to newtrk?
Brian E Carpenter wrote:
3464 is already DS according to the RFC Index.
Good, the process works, unlike my memory: I meant 3834,
a few days ago I wrote 3864 instead of 3834 on another
list, so that's the third attempt: 3834.
[interoperability report]
if {all mandatory and optional features shown to
interoperate}
then {send a request to reclassify RFC 2195 to the IESG}
So far it sounds simple (for the 2195 example). I test it,
thanks for info.
Frank
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
what happened to newtrk?
All, As a participant in the newtrk working group and someone who actually ran one of the only reasonably successful experiments in that group, I think the community is owed a better accounting of why WG failed, and that steps should be taken to see that such efforts do not fail in the future. The newtrk working group was chartered to revise the standards track, with an understanding that the current one is demonstrably not working as it should. As I've previously mentioned, few if any specifications get to draft or full standard, and no review of PS had ever been done along the timelines specified in RFC 2026. Numerous proposals were made within the working group. The ISD proposal seemed to be the one that had the most support. However, this proposal ran into stiff opposition within the IESG and was effectively killed. We can argue until the cows come home as to whether or not the ISD proposal was ready for prime time. However, the end result was that we had a working group chartered to do a specific task, do the task, and then have the work rejected. Quite frankly we don't have the resources to have that happen. I suspect anyone who had any involvement with that group will be extremely reticent to work on process proposals in the future, because they will assume that any given IESG is likely to reject any output. What I would like to know is what we could have done to prevent this from happening. Was the newtrk charter not sufficiently narrow to accomplish a task for which there was community consensus? Is a working group the appropriate place to make process changes? I am leaning heavily toward no on that last one. Should the IESG simply both propose and dispose? Perhaps the IAB has a role of proposing changes. Eventually, as I wrote in a previous note, we must circle back and actually fix the standards process to reflect reality. But how that is to be done remains to me an open question. Eliot ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: what happened to newtrk?
Eliot - the problem quite simply is that the IESG needs to be disbanded. It serves no other purpose than to complicate the creation and acceptable vetting models for Internet Standards and as such really needs to be a thing of the past - The standards process is easily updated to remove the IESG from the process and since they are not chartered to protect the Internet their existence at all is unwarranted overhead and control of political issues within the Internet as a whole and as such totally inappropriate anymore. 2 cents. T - Original Message - From: Eliot Lear [EMAIL PROTECTED] To: IETF Discussion ietf@ietf.org Sent: Tuesday, September 05, 2006 7:39 AM Subject: what happened to newtrk? All, As a participant in the newtrk working group and someone who actually ran one of the only reasonably successful experiments in that group, I think the community is owed a better accounting of why WG failed, and that steps should be taken to see that such efforts do not fail in the future. The newtrk working group was chartered to revise the standards track, with an understanding that the current one is demonstrably not working as it should. As I've previously mentioned, few if any specifications get to draft or full standard, and no review of PS had ever been done along the timelines specified in RFC 2026. Numerous proposals were made within the working group. The ISD proposal seemed to be the one that had the most support. However, this proposal ran into stiff opposition within the IESG and was effectively killed. We can argue until the cows come home as to whether or not the ISD proposal was ready for prime time. However, the end result was that we had a working group chartered to do a specific task, do the task, and then have the work rejected. Quite frankly we don't have the resources to have that happen. I suspect anyone who had any involvement with that group will be extremely reticent to work on process proposals in the future, because they will assume that any given IESG is likely to reject any output. What I would like to know is what we could have done to prevent this from happening. Was the newtrk charter not sufficiently narrow to accomplish a task for which there was community consensus? Is a working group the appropriate place to make process changes? I am leaning heavily toward no on that last one. Should the IESG simply both propose and dispose? Perhaps the IAB has a role of proposing changes. Eventually, as I wrote in a previous note, we must circle back and actually fix the standards process to reflect reality. But how that is to be done remains to me an open question. Eliot ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: what happened to newtrk?
Eliot - the problem quite simply is that the IESG needs to be disbanded. It serves no other purpose than to complicate the creation and acceptable vetting models for Internet Standards and as such really needs to be a thing of the past - The standards process is easily updated to remove the IESG from the process and since they are not chartered to protect the Internet their existence at all is unwarranted overhead and control of political issues within the Internet as a whole and as such totally inappropriate anymore. s/the IESG/Todd Glassey/g Keith ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: what happened to newtrk?
Kieth - abusive language for the purpose of being abusive is prohibited on these lists. Take this as a formal complaint to the Chair over this action. Todd Glassey - Original Message - From: Keith Moore moore@cs.utk.edu To: todd glassey [EMAIL PROTECTED] Cc: Eliot Lear [EMAIL PROTECTED]; IETF Discussion ietf@ietf.org Sent: Tuesday, September 05, 2006 9:33 AM Subject: Re: what happened to newtrk? Eliot - the problem quite simply is that the IESG needs to be disbanded. It serves no other purpose than to complicate the creation and acceptable vetting models for Internet Standards and as such really needs to be a thing of the past - The standards process is easily updated to remove the IESG from the process and since they are not chartered to protect the Internet their existence at all is unwarranted overhead and control of political issues within the Internet as a whole and as such totally inappropriate anymore. s/the IESG/Todd Glassey/g Keith ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: what happened to newtrk?
Now Todd, you must admit that this is true. You are no more chartered to protect the Internet than IESG is. So why isn't your existence here, by your own criteria, unwarranted overhead? Keith Original Message Kieth - abusive language for the purpose of being abusive is prohibited on these lists. Take this as a formal complaint to the Chair over this action. Todd Glassey - Original Message - From: Keith Moore moore@cs.utk.edu To: todd glassey [EMAIL PROTECTED] Cc: Eliot Lear [EMAIL PROTECTED]; IETF Discussion ietf@ietf.org Sent: Tuesday, September 05, 2006 9:33 AM Subject: Re: what happened to newtrk? Eliot - the problem quite simply is that the IESG needs to be disbanded. It serves no other purpose than to complicate the creation and acceptable vetting models for Internet Standards and as such really needs to be a thing of the past - The standards process is easily updated to remove the IESG from the process and since they are not chartered to protect the Internet their existence at all is unwarranted overhead and control of political issues within the Internet as a whole and as such totally inappropriate anymore. s/the IESG/Todd Glassey/g Keith ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: what happened to newtrk?
On Tue, 5 Sep 2006, Eliot Lear wrote: Numerous proposals were made within the working group. The ISD proposal seemed to be the one that had the most support. However, this proposal ran into stiff opposition within the IESG and was effectively killed. We can argue until the cows come home as to whether or not the ISD proposal was ready for prime time. However, the end result was that we had a working group chartered to do a specific task, do the task, and then have the work rejected. From my perspective as an outsider, I have to say that I was extremely disappointed that the WG spent the bulk of its time on the creation of a new series of short IESG-approved IETF documents to describe and define IETF technology standards rather than concentrating on redefining the standards track. What I would like to know is what we could have done to prevent this from happening. Was the newtrk charter not sufficiently narrow to accomplish a task for which there was community consensus? Having just re-read the charter, I would have to say so. I think we would have been better served if the WG had been given the much less ambitious task of producing an update of RFC 2026 that describes what we actually do. Eventually, as I wrote in a previous note, we must circle back and actually fix the standards process to reflect reality. But how that is to be done remains to me an open question. Well, one possibility might be to charter a design team or WG to do just that -- i.e., to take the term Best Current Practice at face value and produce of a standards process BCP that actually documents current practice. //cmh ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
