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

[Nicolas Williams <Nicolas.Williams%sun.com@localhost>]

On Sun, May 18, 2003 at 08:32:49AM +0300, Heikki Nousiainen wrote:
> 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 

Sure, but I don't think that really stops a future SSHv2 mac/enc alg
spec from saying otherwise.

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

I'm not saying "don't."  I'm pointing out that I don't think the current
drafts need modifying to accomodate larger sequence numbers and so on -
unless one wishes to make those directly negotiable during initial keyex,
as opposed to indirectly by negotiation of enc/mac algs, but that would
be a an incompatible change unless it were associated with a new keyex
type, but that would mean introducing a new keyex type for GSS-API.

It will be easier to associate these features of the SSHv2 crypto system
with mac and enc alg types than to make them directly negotiable, so the
current drafts, IMO, need no changes then.

Cheers,

Nico
--