Re: IESG feedback on core drafts.

[Frank Cusack <fcusack%fcusack.com@localhost>]

Some more comments.  BTW, thanks for taking the time to collect and
compose this text.

On Mon, Mar 31, 2003 at 08:08:59AM -0800, Chris Lonvick wrote:
>    twofish, serpent and blowfish.  AES has been accepted by cryptographic
>    experts as being stronger than most of the other ciphers in use today

It has?  I don't think DES had that property and I'm not sure (ie, I don't
know either way) that AES has that property.  eg, one of the considerations
for selection was a design that allows for efficient implementation in
software (unlike DES).
http://csrc.nist.gov/CryptoToolkit/aes/pre-round1/aes_9709.html#sec4

Certainly, AES is strong.  Is it stronger than MOST of the other ciphers
in use today?  What ciphers are in use today?

I might just be being too picky.

>    and it is being implemented in other security protocols as it is within
                                                             ^^^^^^^^

"as well as", maybe?

>    SSH.  As always, implementors and users should check current literature
>    to ensure that no recent vulnerabilities have been found in ciphers used
>    within products.  Implementors should also check to see which ciphers
>    are considered to be relatively stronger than others and should
>    recommend their use to users over relatively weaker ciphers.  It would
>    be considered good form for an implementation to politely and
>    unobtrusively notify a user that a stronger cipher is available and
>    should be used when a weaker one is actively chosen.  Implementors may

cool.

>    wish to offer relatively weaker ciphers in their products for
>    interoperability but should strive to depricate them as soon as

"deprecate", and why would implementors deprecate, say 3DES which may
be weaker than AES?  3DES is required by SSH, AES is not.  (Although,
I believe that AES *should* be required and the 3DES req. dropped, but
that's not the point.)  I would just lose this sentence.

>    of this scheme.  Essentially, this mode is theoretically vulnerable to
>    chosen cipher-text attacks because of the high predictability of the
>    start of packet sequence.  However, this attack is still deemed
>    difficult and not considered fully practicable especially if relatively
>    longer block sizes are used.

"practical" might be better.

/fc