Subject: [Gen-art] Gen-art review of draft-harris-ssh-rsa-kex-05.txt

From: Elwyn Davies <[email-masked]>
Date: Mon, 12 Dec 2005 19:55:23 +0000

I was selected as General Area Review Team reviewer for this specification
(for background on Gen-ART, please see
http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).

Document: draft-harris-ssh-rsa-kex-05.txt
Intended Status: Proposed Standard
Shepherding AD: Sam Hartman
Review Trigger: IESG Telechat, 12 December 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.

_______________________________________________
Gen-art mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/gen-art

---

From: Sam Hartman <[email-masked]>
Date: Mon, 12 Dec 2005 15:17:31 -0500

Hi.  It is actually expected that the method numbers for key exchange
methods will be reused by each key exchange method.

That's actually been cleared up in auth48 and in the IANA registry.
So what this document is doing is appropriate.

Ben, how fast can you get around to dealing with these editorial
fixes?

---

From: Sam Hartman <[email-masked]>
Date: Mon, 12 Dec 2005 15:17:31 -0500