IETF-SSH archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

draft-ietf-secsh-dns-04 comments



Hi,

A few layman's (to SSH specs & DNS details) comments to the secsh-dns 
draft.

Most of the comments should be easy to understand.  In 2.4, I think the 
language must be much more specific what's required.  "MUST .. unless" is 
not good, IMO.  

(looking back, you could also add a reference to RFC2434 in the IANA 
considerations section)

--- draft-ietf-secsh-dns-04.txt	Wed Apr  2 19:54:58 2003
+++ draft-ietf-secsh-dns-04.txt.new	Mon May 12 22:12:30 2003
@@ -8,7 +8,7 @@
                                                            April 2, 2003
 
 
-           Using DNS to securely publish SSH key fingerprints
+           Using DNS to Securely Publish SSH Key Fingerprints
                       draft-ietf-secsh-dns-04.txt
 
 Status of this Memo
@@ -125,14 +125,14 @@
    saved locally and used for verification for all following
    connections.  While some security-conscious users verify the
    fingerprint out-of-band before accepting the key, many users blindly
-   accepts the presented key.
+   accept the presented key.
 
    The method described here can provide out-of-band verification by
    looking up a fingerprint of the server public key in the DNS [1][2]
    and using DNSSEC [4] to verify the lookup.
 
    In order to distribute the fingerprint using DNS, this document
-   defines a new DNS resource record to carry the fingerprint.
+   defines a new DNS resource record, "SSHFP", to carry the fingerprint.
 
    Basic understanding of the DNS system [1][2] and the DNS security
    extensions [4] is assumed by this document.
@@ -196,8 +196,8 @@
 
 2.4 Authentication
 
-   A public key verified using this method MUST only be trusted if the
-   SSHFP resource record (RR) used for verification was authenticated by
+   A public key verified using this method MUST NOT be trusted if the
+   SSHFP resource record (RR) used for verification was not authenticated by
    a trusted SIG RR.
 
    Clients that do not validate the DNSSEC signatures themselves MUST
@@ -234,7 +234,9 @@
          /                          fingerprint                          /
          /                                                               /
          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
+==> please use the more common textual representation, seems much more
+natural
+==> the picture is 74 chars wide --- not good!
 
 3.1.1 Algorithm Number Specification
 
@@ -319,7 +321,7 @@
       replacing the corresponding SSHFP in DNS.
 
       If SSH host key verification can be configured to require SSHFP,
-      we can implement SSH host key revocation by removing the
+      SSH host key revocation by can be implemented by removing the
       corresponding SSHFP from DNS.
 
    As stated in Section 2.2, we recommend that SSH implementors provide

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings




Home | Main Index | Thread Index | Old Index