Using DNS to Securely Publish Secure Shell (SSH) Key Fingerprints
draft-ietf-secsh-dns-05

[Ballot comment]
In the text:

        While some security-conscious users verify the
        fingerprint out-of-band before accepting the key, many users blindly
        accepts the presented key.

accepts should probably be accept.

In the references, this refers to RFC 2535 and nothing else; an updated
reference would be good.

[Ballot discuss]
1. Introduction

      The SSH [5] protocol provides secure remote login and other secure
      network services over an insecure network. The security of the
      connection relies on the server authenticating itself to the client.

it also relies on the user on the client host authenticating
themself to the server. though this is not germane to this
document, the above statement could be dangerous out of context.

---

      Server authentication is normally done by presenting the fingerprint
      of an unknown public key to the user for verification.

the public key is not unknown, in fact the opposite. if it was
unknown, then all ssh would offer is being able to talk to the same
liar all the time. :-)

perhaps "unique" is what was meant?

---

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 trusted SIG RR.

may want to say that the trust must either come from a validated
trust descent from the root or from a validated descent from a zone
trusted because of a locally known association.

---

      The overall security of using SSHFP for SSH host key verification is
      dependent on detailed aspects of how verification is done in SSH
      implementations.

and of the practices of securing the data inserted in the SSHFP RR
in the dns and in the client host's diligence in accessing those
data securely. c.f. the discussion on
draft-ietf-dnsext-ad-is-secure-06.txt

---

nits:

      fingerprint out-of-band before accepting the key, many users blindly
      accepts the presented key.
                  ^
-
      algorithm and fingerprint of the key received from the SSH server
      matches the algorithm and fingerprint of one of the SSHFP resource
                ^^
-
            A message digest of the public key, using the message digest
            algorithm specified in the SSHFP fingerprint type, MUST match the
            SSH FP fingerprint.
                  ^
-
3.2 Presentation Format of the SSHFP RR

      The presentation format of the SSHFP resource record consists of two
      numbers (algorithm and fingerprint type) followed by the fingerprint
      itself presented in hex, e.g:

                  host.example. SSHFP 2 1 123456789abcdef67890123456789abcdef67890

well bad wording, actually, as the example shows, the presentation
format consists of the label, the RR type, SSHFP, and ...

randy