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

["Joseph Salowey" <jsalowey%cisco.com@localhost>]

> -----Original Message-----
> From: ietf-ssh-owner%NetBSD.org@localhost 
> [mailto:ietf-ssh-owner%NetBSD.org@localhost] On Behalf Of Simon Tatham
> Sent: Wednesday, August 13, 2003 8:25 AM
> To: ietf-ssh%NetBSD.org@localhost
> Subject: Re: I-D ACTION:draft-ietf-secsh-scp-sftp-ssh-uri-00.txt
> 
> 
> <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.)
> 
I'm not sure, but I believe it is acceptable for the absolute path
section to contain C: or d:. 

Scp://c:/file.txt

Do you see an issue with this?



>  - 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? 
[Joe] Yes

>    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?
> 
[Joe] Yes

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

[Joe] This would be good, although I'm not sure you could achieve this
configuration in current web browsers and mail clients.   I was thinkin
that this could also involve user participation in the verification as
well.  Perhaps a prompt indicating "the host key from the server matches
(or does not match) the fingerprint in the URL; do you want to proceed?"



> 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?
>
[Joe] they should be listed in order of preference.
 
>  - 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.
> 
[Joe] Good point.

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