> Keith> previous mistakes are not valid justifications for new > Keith> mistakes. previous accidents are not valid justifications > Keith> for deliberately weakening new products. > So, that's certainly true. but I can see two points. > > 1) There is an existing somewhat broken rc4 cipher in the ssh > standards-track document. This spec proposes to replace that > cipher with one that is much less broken. Why should that be > a lower level of standardization than the existing cipher? It shouldn't. But there's no reason that the existing specification cannot be reclassified as Historic at the same time as the new specification is approved for whatever classification seems reasonable. There's also no reason that an applicability statement cannot be written (preferably as a separate document) that explains the reasons for the status of each dialect of rc4, and the risks vs. benefits of using each dialect of rc4. (other than, perhaps, it's awkward for IESG to originate such statements, and even more difficult to get consensus on such statements than for ordinary specifications) Note that I'm not specifically recommending that the new rc4 document not be standards-track, nor am I specifically recommending that the existing documents should be reclassified as non-standards-track. I am saying that the fact that the "existing arcfour cipher is part of a standard and that many other IETF protocols use rc4 in standards track documents" is not a justification for making the new document a standard if it doesn't meet our technical criteria. Nor is it a justification for keeping the old documents at standards-track if they no longer meet our technical criteria. Keith p.s. Part of the problem, I suspect, is that the standards-track vs. non-standards-track bit is overloaded (in practice) to be both a "recommendation" bit and a "this meets our technical criteria" bit. There are times that we'd like to recommend protocols and practice that don't meet our normal criteria for standards-track. There are also times that we want to make standards for protocols even we don't specifically recommend their use. But we have a difficult time doing that because we know that in practice anything we label as "standard" will be taken as if it is recommended. _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf