Re: Core draft last call update.

[Bill Sommerfeld <sommerfeld%orchard.arlington.ma.us@localhost>]

> > It needs to be turned into a stand-alone internet-draft.
> 
> Why?

I made a ruling as working group chair that, because (a) the problem
could be fixed by a separate document introducing new ciphers, and (b)
there clearly did not exist consensus on the a fix, that we should not
hold up advancement of the rest of SSH while we attempted to solve the
problem.  

You've missed the train.  The core specs are now out of our hands.

> block size of the cipher in bits.  Network order SHOULD be used to convert

s/SHOULD/MUST/.  If both sides don't increment the counter in the same
way, you won't interoperate.

[By comparison, random padding is only a SHOULD since getting it wrong
won't break interoperability (but might have subtler ramifications).
RFC2119 is quite clear that implementors may ignore SHOULD but they
do so only at their own peril.  ]

> For block cipher based algorithms with variable-length IVs, the IV length
> SHOULD be the block size of the underlying block cipher.

I think this misses the point.  Something like:

   For counter mode, we use a counter equal in size to the cipher's
   block size.  The first block-size bytes of the "initialization
   vector" value negotiated by the transport protocol are used to
   initialize the counter.

would be much clearer.

> Ok, add this reference to the first mention of CTR:
> 
>    [SP800-38A] "Recommendation for Block Cipher Modes of Operation", 
>    United States of American, National Institute of Science and 
>    Technology, NIST Special Publication 800-38A 2001 Edition, December 
>    2001. 

I still think the text is confusing and vague.  The counter value is
not used to encrypt the plaintext.