Re: additional core draft nits in need of WG attention.

[nisse%lysator.liu.se@localhost (Niels Möller)]

I have a few comments, which I'm sending in separate mails.

Bill Sommerfeld <sommerfeld%east.sun.com@localhost> writes:

> transport draft:
> 
> > >5.  Section 4. SSH allows the client and server to employ different
> > >algorithms for the data that they encrypt. This practice should be
> > >discouraged somewhere in the document.  It is likely to cause
> > >interoperability problems, and it offers no security advantage.

I don't buy this at all. As for interoperability problems, it's true
that it's a rarely used (and likely not well tested) feature. But
that's about all, implementations must keep separate encryption
contexts and independent NEWKEY key switching anyway, so that they at
the same time must use no encryption on one direction and the
new negotiated cipher on the other.

And no security advantage? The general assertion that there's no
security advantage is false. As always, it's a tradeoff that depends
on lots of circumstances. For example, assume that

  1. The end nodes have constrained cpu capacity.
  2. The intersection of supported ciphers at both ends is { arcfour,
     des3 }
  3. In *one* of the directions, you want to send data at a higher
     rate than can be encrypted with des3 by the particular nodes.
  4. You believe des3 to have better security properties than arcfour.

Then the feasible cipher choices are

  arcfour   arcfour  (arcfour both ways)
  arcfour   des3     (arcfour for the bulk data only)

and the second has a security advantage.

/Niels