Re: SSH paper and a possible transport layer extension [was: aside on formal methods]

[Heikki Nousiainen <htn%sumu.org@localhost>]

On Sat, 17 May 2003, Nicolas Williams wrote:
> 
> I don't see anything stopping a future SSHv2 encr/mac alg set from
> requiring larger sequence numbers.  I wouldn't mind sequence number
> sizes being negotiable though (I take it this is what you mean by
> "modularizing").

The only thing stopping this is the section 4.4 of the transport layer 
spec. As it now stands, the spec dictates 32 bit counter and 
authenticating the plaintext. It's an artificial limitation, which, I 
think, could be lifted by defining these properties with the MAC 
algorithm [algorithm, as defined for use in secsh].


> I think larger sequence numbers (e.g., 64 bits and up) are a must for
> protocols that don't support rekeying; for those that do, unless
> rekeying is onerous (and I don't think SSHv2 rekeking is), smaller
> sequence numbers (e.g., 32 bits) are not such a bad thing.

MAC is not the only part requiring rekey, but yes, with ciphers with 
bigger blocksizes, the rekeying is likely to be required for the MAC 
first.

Rekeying is not that much of a problem with the current algorithms, but it 
may be in the future. We need bigger DH groups and more expensive 
calculations for bigger keysizes. With data growing and transports 
getting faster we are likely to hit the limitation faster. Why not change 
the behaviour before it becomes a problem?

Regards,
 Heikki Nousiainen


Few corrections to my earlier post:
 - The underlying cipher doesn't know packets, so the rekeying requirement 
can't be expressed as 2^64 packets as I wrote. For 256bit block cipher, 
this should be every 2^64 blocks or with 64 bit sequence number, 2^64 packets, 
whichever comes first.
 - I mix use the term MAC algorithm with both the function and how MAC 
algorithm is specified in the spec; first occurence should be function, 
the latter two refer to how MAC is specified in the spec.