RE: secsh-sftp-scp-uri draft

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

<snip>

> > 2.  Specifying ciphers etc as parameters
> 
> I fail to see the need for these. Client already has a list 
> of preferred 
> algorithms and server can dictate use of a specific cipher as 
> the drafts 
> stand.
> Only place I can find this useful is when server wants to use 
> a cipher not 
> allowed by the default client policy (say, des or none). I'd be 
> very wary allowing such action.
> 
> Educate me, if I've missed something.
> 

[Joe] I think there is plenty of consensus to remove this from the
draft.

> 
> [snip]
> > 
> > 4.  Multiple host key algorithms and fingerprints
> 
> I'd like to see fingerprints removed from the draft. I think 
> it's calling 
> for trouble in a way of man-in-the-middle or impersonation attacks.
> 

[Joe] Don't think that fingerprints in the URI make these problems any
worse.  I think they can actually help.  If I receive a URL in a signed
email from someone that I know I can rely on the fact that the
fingerprint is accurate.  If I have a web page with a list of SSH URLs
that is delivered over a secure connection from a trusted source then
the fingerprints in the URIs are very useful.  If the finger print
doesn't match then I know there is a problem (see below).

> 
> > 5.  Security considerations in trusted vs. untrusted URLS
> 
> Is there such a thing as trusted URL? I doubt it. Maybe the 
> source can be 
> verified, but there's no validity protection on the URL 
> itself. Consider 
> someone being able to post content on a trusted site. 
>Or an attacker 
> tricking some trusted user to send crafted URL in e-mail. An 
> employee gone 
> bad and sending a malicious URL.
> 

[Joe] You are correct in that trusted URLs do not exists, but trusted
sources do.  It is entirely possible that a trusted source is
compromised, that is why the URL should never overwrite a locally
configured fingerprint.  If you don't have a locally configured finger
print then the URL information is better than nothing at all. However
there is probably danger in the automation of the connection.

If for example an SSH client by default puts up a message that says
"host key for server x is gobble-gobble-gobble and is not in you
database do you want to connect?" when invoked without a URL and doesn't
put up a message when it is invoked by a URL then there could be a
problem since currently there really is no way for the client to know
the source of the URL.  

If the key matches it probably should by default put up a message like
"host key for server x is gobble-gobble-gobble and is not in your
database, however it matches the fingerprint in the URL, do you want to
connect?"   

Even better if the fingerprint in the URL does not match the host key
and there is no locally configured value you can refuse to connect by
default "The host key for server x does not match the fingerprint in the
URL and is not in the local database so the connection is not allowed."

I think this provides value.  Perhaps the security considerations should
instead give some guidance along these lines.  

> It's hard to get it right, and in my opinion, the risks far 
> outweigh the 
> benefits (maybe some anonymous SFTP scheme?).
> 
> 
> My suggestion:
> Let the SSH/SCP/SFTP URIs be location pointers, and remove connection 
> parameters altogether. Treat all URIs as 'untrusted' and let 
> SSH handle the decissions over connection setup.
> 
> 
>  Best regards,
>   Heikki Nousiainen 
>