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

["Joel N. Weber II" <ietf-secsh%joelweber.com@localhost>]

> > Is there a good reason to define scp URLs in addition to sftp URLs?
> > 
> [Joe] SCP is is use today, we thought it would be useful.

I guess I'm not really clear on what the working group and ssh
implementors think should be the future of scp vs sftp.  If there is a
desire to depreciate scp in favor of sftp, it may be best to not
define a URL scheme for scp to encourage the use of sftp.

> > I don't think explicitly specifying port 22 in all cases 
> > where the URL doesn't specify a port number is correct; what 
> > about SRV DNS records?
> [Joe] So the suggestion would be something like:
>
> If the URL doesn't specify a port number the it should check for a SRV
> DNS record if it is available, if it is not then it should use port 22.

It might be better to come up with language along the lines that if
the port number is specified in the URL, it is used, otherwise the
port number to use is determined by what is specified in the other
secsh documents.  However, it seems like there's a little bit of
vagueness there; the transport draft says that ssh normally listens on
port 22, and there's no mention of SRV records anywhere in the secsh
documents, as far as I can tell.

> > What is the rationale for allowing the URL to specify 
> > information about ciphers, integrity protection, etc?  It 
> > seems allowing this to be specified might allow an attacker 
> > providing a URL to perform a downgrade attack, which at the 
> > very least should be mentioned in the security considerations 
> > section.  There doesn't seem to be anything prohibiting an 
> > attacker from specifying ``none'', either.
>
> [Joe]  This was added as an afterthought to the fingerprint parameter.
> The thought was that the this would allow the URL to specify what
> parameters should be used.  However for parameters that are negotiated
> such as cipher, integrity, etc. It's not clear that they add much value.
> The list should not add to what is configured as acceptable to the
> client confiuration.  If the client allows none in its default
> configuration there is a potential problem whether the URL speficies it
> or not.  Perhaps it would be better to let the SSH negotiation take care
> of this and remove it from the URL.      

I can have a client which is set up to accept AES, or if that is not
available, single DES, or if that is not available, none.  As long as
I'm properly verifying the host key, the client allowing that fallback
will not reduce security in the cases where the server does support
AES, because the signature made with the host key is against a hash
that includes all of the cipher algorithms that both sides offered.

But I do agree that letting ssh negotiation decide these things makes
sense.  (The only times I can remember I've overridden a list of
algorithms that my ssh client had by default were testing pgp-sign-*
support before I'd written the code to add those algorithms to the
default proposal list, and overriding the cipher when doing a long
file transfer between relatively slow machines over ethernet.  And if
the latter problem is worth fixing, it should be done with careful
consideration of which ciphers are both fast and secure, and putting
such a cipher at the begining of the list for all file transfers.)

> > It looks to me like there is no mechanism for specifying the 
> > public key host key algorithm to be used, nor does the 
> > fingerprint contain that information.  Combined with only 
> > allowing one fingerprint, that has the potential to cause 
> > interoperability problems: if I have a server with one 
> > ssh-rsa key, and one ssh-dss key, and some clients happen to 
> > prefer ssh-rsa over ssh-dss and others are the other way 
> > around, how do I provide a URL with a fingerprint that will 
> > work with both types of clients?
> > 
> [Joe] Yes, I didn't think about this.  There should be a way to
> accomplish this.  It seems like we may need to allow for multiple
> fingerprints and multiple host algortihms.  Perhaps the fingerprint
> parameter should be something like
> fingerprint=<hostkeyalg>:<fingerprint>;

I'm not sure that there's necessarily a need to allow for multiple
fingerprints.  If you are getting an ssh:// url from a trusted source,
you could just use an ssh-dss key, and all clients will support that.

The set of characters that can theoretically be used in the name of a
host key algorithm is probably a superset of what you want to allow in
a URL, so there probably needs to be an escaping mechanism, sigh.