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

In article <tsloeaqgc2s.fsf@cz.mit.edu> you write:
>Hi, folks.  The IESG has received a last call comment recommending
>that the new rc4 cipher for ssh be published as informational rather
>than as a proposed standard because of weaknesses in rc4.  It would be
>inappropriate to make a decision based on one comment so I am
>soliciting comments on this point.

I think it may be worth my explaining a little of the background here, and
what I'm trying to achieve.  I don't know that a Standards Track RFC is the
correct approach, but it seemed the most appropriate to me.

SSH finally got approved for publication as a Proposed Standard earlier this
year.  It supports many symmetric ciphers, one of which is "arcfour".  This
is RC4 with a 128-bit key, using the keystream from the beginning. 
"arcfour" is notable for being, in software implementations, both the
fastest and the simplest of the symmetric ciphers specified for SSH in any
Standards Track document (except for "none", of course).  This makes its use
tempting in circumstances where code size or CPU usage are important.

RC4 has several weaknesses, some of which can be eliminated by discarding
the start of the keystream, which is a trivial operation.  Increasing its
key size is also trivial.  Some of RC4's other weaknesses are inherent in
its keystream generator.

My aim in writing draft-harris-ssh-arcfour-fixes was to ensure that the
fastest and simplest standard SSH cipher (a) wasn't unnecessarily weak and
(b) had its necessary weaknesses documented.  Other ways to accomplish the
same thing would be to somehow deprecate "arcfour" and force people to use
"blowfish-ctr" instead, or to standardise a new cipher that's faster,
simpler, and more secure than "arcfour".

It occurs to me that if someone could come up with a procedure for doing so,
my ideal here would be to cause "arcfour" to become NOT RECOMMENDED, and to
introduce "arcfour-128" and "arcfour-256" with the same status.

People wishing to read the papers referenced might find these URLs useful. 
The Fluhrer and McGrew paper is the scary one:

>S. Fluhrer, I. Mantin, & A. Shamir, "Weaknesses in the Key Scheduling
>Algorithm of RC4", Proceedings of 8th Annual International Workshop
>on Selected areas in Cryptography (SAC 2001), Toronto, ON, CA,
>August 2001.
<http://www.wisdom.weizmann.ac.il/~itsik/RC4/Papers/Rc4_ksa.ps>

>J. D. Golic, "Linear Statistical Weakness of RC4 Key Generator",
>Procedings of EuroCrypt 1997, Konstanz, DE, May 1997.
<http://www.wisdom.weizmann.ac.il/~itsik/RC4/Papers/Golic.PDF>

>S. Fluhrer & D. McGrew, "Statistical Analysis of the RC4 Key
>Generator", Proceedings of 7th International Workshop on Fast
>Software Encryption (FSE 2000), New York, NY, US, April 2000.
<http://www.mindspring.com/~dmcgrew/rc4-03.pdf>

>L. Knudsen, W. Meier, B. Preneel, V. Rijmen, & S. Verdoolaege,
>"Analysis Method for RC4", Proceedings of AsiaCrypt 1998.
<http://www.wisdom.weizmann.ac.il/~itsik/RC4/Papers/Knudsen.ps>

>S. Paul & B. Preneel, "Analysis of Non-fortuitous Predictive States
>of the RC4 Key Generator", Proceedings of 4th International Conference
>on Cryptology in India (IndoCrypt 2003), New Delhi, IN, December 2003.
<http://www.cosic.esat.kuleuven.be/publications/article-86.pdf>

-- 
Ben Harris

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf