additional core draft nits in need of WG attention.

[Bill Sommerfeld <sommerfeld%east.sun.com@localhost>]

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.

[this is section 5 in version -17]

suggested resolution:

immediately after this text:

   The ciphers in each direction MUST run independently of each other,
   and implementations MUST allow independently choosing the algorithm
   for each direction (if multiple algorithms are allowed by local
   policy.

insert:

   Note that there is no security advantage to using different
   algorithms in each direction; implementations SHOULD use the same
   algorithm in both directions when allowed by policy.

> >6.  Section 4.3, second paragraph. The document says: "...effective key
> >length of 128 bits or more". Yet, Triple-DES is the REQUIRED algorithm,
> >and it does not meet this goal.  Suggestion: "...effective key length of
> >96 bits or more".

so, this is a "how do we count the bits" issue.  three-key triple-des
is under some circumstances vulnerable to a particular attack which
takes 2^112 time and 2^112 storage.  It is not clear to me whether
this particular attack is possible against 3des as used by SSH.

Do we:
	- Lower the recommended limit?  (to what? 96 bits? 112 bits?)
	- Explicitly grandfather triple-des?
	- Make AES REQUIRED?


Others:

> >10.  Section 5, last paragraph. What is "implicit server
> >authentication?"  The whole paragraph is unclear.

Can someone provide some fill-in text?

> >13.  Section 6.1.  There is only one Oakley group defined, and it has an
> >equivalent strength of 80-bit symmetric encryption. There should be
> >additional Oakley groups that offer strength commensurate with the other
> >recommendations in the document. The document should explicitly reference
> >RFC 3526, and make use of group 14 (2048 bits).

Any opinions here?  "Use dh-group-exchange if you're paranoid".


draft-ietf-secsh-userauth-17:

> >3.  Section 2, last paragraph. Setting the SHOULD for the timeout to 10
> >minutes seems very long.  Doesn't it open up some denial-of-service
> >attacks. The SHOULD for the timeout ought to be for interoperability.

I'm reluctant to change that.  First, it's a SHOULD, not a MUST..
also, making it too short may cause issues for the handicapped
(consider the combination of slow typing rate and high error rate..)

> >4.  Section 5, last paragraph on page 9.  Saying that UTF-8 is the
> >encoding for passwords means that implementations need to check for valid
> >UTF-8 encoding.  This could lead to unexpected failures. It would be much
> >better to say that passwords are arbitrary binary strings with no
> >specified encoding.  Exact match of the binary strings ought to 
> >be sufficient.

Thoughts?  My understanding is that requesting exact match of
internationalized input is problematic under some circumstances..

					- Bill