Re: I-D ACTION:draft-ietf-secsh-scp-sftp-ssh-uri-00.txt

[Simon Tatham <anakin%pobox.com@localhost>]

<Internet-Drafts%ietf.org@localhost> wrote:
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-secsh-scp-sftp-ssh-uri-00.txt

The SSH and SFTP schemes look basically sane to me. Some comments on
the rest:

 - SCP is a bit harder, because AIUI there's no requirement for
   absolute path names on an SCP server to begin with a slash, so
   the stated syntax is potentially ambiguous. (A Windows SCP
   server, for example, is at liberty to begin all its absolute path
   names with "c:\" and "d:\" and so on, I believe.)

 - In the parameters section, there is repeated text saying `This
   parameter MUST NOT add a mechanism to a configured list of
   default configured acceptable encryption types'. I can't
   immediately parse that. Does that mean that if an SSH client
   doesn't by default enable (say) "des-cbc", it must not enable it
   solely on the say-so of the URL? Does it in fact mean that the
   client should restrict its existing set of ciphers (or whatever)
   to the intersection of its preconfigured/default set and the set
   provided in the URL? If not, what does it mean?

 - I'm particularly concerned about the "fingerprint" parameter. I
   appreciate that the document already mentions that it makes a
   difference whether the URL's fingerprint was obtained through a
   trustworthy mechanism, but it strikes me that this might be fun
   to implement in the average software setup in which the web
   browser and the SSH client are separate, because if the client is
   just handed a URL it won't in general know how it was obtained.

   Perhaps a solution is for the web browser to allow separate
   configuration of SSH client commands for securely and insecurely
   obtained SSH URLs, and then those could be configured to be
   respectively `putty --trust-fingerprint-parameter <URL>' and just
   plain `putty <URL>'.

Less fundamental nits:

 - There may be more than one cipher/integrity/key-xchg parameter in
   a given URL, but if there is, what preference order does that
   imply? Or none?

 - Come to think of it, why must there not be more than one
   fingerprint parameter? A host might perfectly well have ssh-dss
   and ssh-rsa host keys, and want to supply the fingerprints of
   both because it can't predict which key exchange mechanisms the
   client supports.

 - `They fingerprint' -> `The fingerprint'.

 - Shouldn't there be references describing the protocols specified
   by the three schemes? (_Is_ there even a document describing SCP?)

 - Why is `Guidelines for new URL schemes' a normative reference?

-- 
Simon Tatham         "Imagine what the world would be like if
<anakin%pobox.com@localhost>    there were no hypothetical situations..."