Re: draft-harris-ssh-arcfour-fixes-02: informational or proposed?

>     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 mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf