Evaluation: draft-ietf-secsh-architecture-14

[Russ Housley <housley@vigilsec.com>]

  Russ Housley        [   ]     [   ]       [ X ]      [   ]


draft-ietf-secsh-architecture-14

1.  The document contains non-ASCII characters.

2.  There are five authors listed. Later in the document,  it says that 
Darren Moffat is the "current document editor", who is not one of the 
people listed at the top. I suspect that this is a problem with history, 
that only Darren should be listed on the front page, and there should be an 
acknowledgement section at the beginning listing the other five (and 
probably others).

3.  Section 3.1.  The document says: "(currently DSS [FIPS-186])."  This 
indicates that it might change in the future; please remove "currently".

4.  Section 3.6.  Please reference RFC 3066, which obsoletes RFC 1766.

5.  Page 11, last bullet.  The example should be "@example.com", not 
"@ssh.com".

6.  Section 7, second paragraph on page 13.  This is technically incorrect. 
Names with at-signs are not allocated by zone administrators; they are 
allocated by mail system administrators, and they relate to names in the 
message store.  Please remove the whole paragraph.

7.  Section 7, last paragraph on page 13.  Please change "...should be 
allocated..." to "...are allocated...".

8.  Section 8.3.5, second paragraph.  Public key authentication also 
assumes that the server has not been compromised.  In particular, it 
assumes that the private key has not been compromised.

9. References. The list has to be split between normative and informative.


draft-ietf-secsh-connect-17

1.  The document contains non-ASCII characters.

2.  There are five authors listed. Later in the document,  it says that 
Darren Moffat is the "current document editor", who is not one of the 
people listed at the top. I suspect that this is a problem with history, 
that only Darren should be listed on the front page, and there should be an 
acknowledgement section at the beginning listing the other five (and 
probably others).

3.  Section 1, first paragraph. I don't understand what "(after user 
authentication)" means.

4.  References. The list has to be split between normative and informative.


draft-ietf-secsh-transport-16

1.  There are five authors listed. Later in the document,  it says that 
Darren Moffat is the "current document editor", who is not one of the 
people listed at the top. I suspect that this is a problem with history, 
that only Darren should be listed on the front page, and there should be an 
acknowledgement section at the beginning listing the other five (and 
probably others).

2.  Section 3.3. This is clearly here to allow servers to interoperate with 
SSH version 1. However, there is no specification for SSHv1. The WG decided 
to not document SSHv1, even as an informational RFC. There are many SSHv1 
implementations, and at least one very large vendor has no intention of 
moving to SSHv2. A reference to some kind of SSHv1 specification is needed 
to provide context.

3.  Please renumber Section 3.4 to 3.3.1, and renumber section 3.5 to 3.3.2.

4.  Page 6, first paragraph. The SHOULD NOT conflicts with the MUST at the 
bottom of page 4. Suggestion: change the MUST at the bottom of page 4 to 
SHOULD.

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.

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".

7.  Section 4.3, algorithms. Please change blowfish-cbc and twofish128-cbc 
to OPTIONAL.  There are not easily referenced documents to these algorithms 
for a Standards Track RFC.

8.  Section 4.3, algorithm descriptions. The reference for TripleDES should 
be ANSI X9.52, not Schneier. The reference for AES should be the NIST FIPS 
Publication.  Also, there should not be a statement about IDEA's patent.

9.  Section 4.6, table on page 12. "ssh-dss" and "ssh-rsa" should state 
that these are raw keys.

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

11.  Section 5.1, first paragraph on page 17.  Please reference RFC 3066, 
which obsoletes RFC 1766. There should be a sentence that says "Language 
tags SHOULD NOT be present unless they are known to be needed by the 
sending party." This has become clear in HTTP after RFC 1766 was created.

12.  Section 5.2, first full paragraph on page 18. The document says: "128 
bits (16 bytes) SHOULD be used for algorithms with variable-length 
keys."   All of the listed algorithms, except arcfour, have stated key 
sizes.  Also, the SHOULD will lead to interoperability concerns.

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).

14. References. The list has to be split between normative and informative.


draft-ietf-secsh-userauth-17

1.  The document contains non-ASCII characters.

2.  There are five authors listed. Later in the document,  it says that 
Darren Moffat is the "current document editor", who is not one of the 
people listed at the top. I suspect that this is a problem with history, 
that only Darren should be listed on the front page, and there should be an 
acknowledgement section at the beginning listing the other five (and 
probably others).

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.

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.

5.  References. The list has to be split between normative and informative