Re: Core draft last call update.

[Wei Dai <weidai%eskimo.com@localhost>]

On Wed, Mar 13, 2002 at 09:54:23PM -0500, Bill Sommerfeld wrote:
> 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.

I don't agree with the proposed resolution to the issue I raised. Should
I contact the Area Director now or wait for the general Last-Call?

> > 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.

I wrote SHOULD in case people want to define their own CTR ciphers and use
little endian counters. BTW, what about these two "SHOULD"s in 4.3:

   The encrypted data in all packets sent in one direction SHOULD be
   considered a single data stream.  For example, initialization vectors
   SHOULD be passed from the end of one packet to the beginning of the
   next packet.

If one side doesn't follow these shoulds, it would be an interoperability
problem, as well as a security problem.

> > 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.

My assumption is that the implementor already knows what CTR mode is, and
we only need to specify the options (i.e. full-size IVs, big-endian
counter) that SSH uses. For comparison, there is no explanation of how CBC
mode works in the current draft, or even a specific reference for it.