Document:  draft-harris-ssh-rsa-kex-05.txt 
Reviewer: Elwyn Davies [elwynd@dial.pipex.com]
Review Date:  Monday 12/12/2005 1:55 PM CST
Telechat Date:  Thursday 12/15/2005

Summary: This document appears to be almost ready for PS.  
There is possibly one minor nit (depending on the interpretation of -secsh-assignments) and a few desirable editorial fixes.  
Caveat: I am not a crypto expert and am 
therefore not in a position to be opionated on the 
accuracy/appropriateness of the algorithm.

It would be desirable to make it quite clear what the intention of the 
IANA -secsh-assignments process is as regards overloadable message 
number ranges (see notes on s7/s9 below).

Detail:
This document appears to be well written and is close to readiness for PS.

s7 and s9: Two of the suggested message numbers are apparently already 
taken (according to the latest version of -secsh-aassignments).  I note 
that the message numbers can be overloaded if required so this is not 
wrong, but I would suggest that either the overlap should be noted or 
non-overlapping numbers should be used.  Given that there is currently 
no shortage of numbers should different numbers be used?  I have to say 
that there is a certain ambiguity about the registration or otherwise of 
the range:
30 to 49   Key exchange method specific (numbers can be reused
           for different authentication methods)
-secsh-assignments specifies the numbers defined in this range in 
-secsh-transport but allows the numbers to be overloaded.  Is it the 
intention that future names/numbers in this range should be registered 
with IANA even though it may not be strictly necessary?

Editorial:
s1: It might be useful to mention that the terminology and abbreviations 
(such as K_S) are mostly taken from the -secsh-transport draft.

s3: Might be useful to introduce the K_S notation for the server host 
key here, if only to make it absolutely clear that it isn't the same as K_T.

s3: It would be useful to point to s8 of -secsh-transport for the 
mechanisms used for verifying the host key.

s4, para 1: s/, which are defined by the method name/that are specified, 
fixed values defined for each method name/

s4: There should be a note pointing to -secsh-architecture regarding how 
the message contents are specified.

s4: Generation of K: I would prefer (2*HLEN) to 2HLEN in the 
specification of the range for K.

Appendix A:  The previous comment applies to 4 places in Appendix A also.