Re: secsh-sftp-scp-uri draft

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

> 1.  Default port issue
>
> Status:  Proposed change- "If the port is not included, the default port 
> (22) is assumed."

I'd prefer to see something along the lines of ``If the port is not
included, the default port that is used when the user does not specify
a port is assumed.''  In particular, I would like the text to have the
property that if the ssh protocol were changed to support SRV in the
future, that ssh URLs would automagically start using SRV records when
the port is not specified, without needing to update the URL spec.

> 2.  Specifying ciphers etc as parameters
>
> Status: Looking for consensus.

I would like to see the URL scheme not provide a way to specify any of
the cihper etc parameters that were specified in the original draft,
because they facilitate downgrade attacks, and I don't think anyone
has argued that they actually would get any value out of using these
parameters.

> 4.  Multiple host key algorithms and fingerprints
>
> Status: Looking for consensus.

I have rather mixed feelings about this.

I do think if we are going to support host key fingerprints in URLs at
all, we should allow multiple fingerprints to be included, and we
should have an explicit algorithm identifier.

Are there any implementors who intend to implement the host key
fingerprints?  Do these implementors have confidence that they can
distinguish between trusted and untrusted URLs?  (Like, are there any
web browsers they're going to interact with that provide enough
information to determine this when passing a URL to the ssh client?
Or is there a reasonable expectation that browser APIs would gain this
functionality?)

If https://evil.example.com has a link to ssh://goodguy.example.com
where the ssh URL on evil.example.com's webpage has a fingerprint, is
that going to make things less secure than if we omit fingerprints
from the ssh URL?

Do we suspect that there are a non-trivial number of cases where
people can deal with getting for their web page an X.509 certificate
that is in some useful way certified, but they can't deal with getting
an X.509 certificate for their ssh server?  (I've seen fas.harvard.edu
be an example of being able to deal with X.509 for ``the web'' but not
for ssh, but this may be mostly a matter of poor documentation being
made available to the sysadmins, along with a lack of support for
certificates in at least one popular ssh implementation, although I
think the implementation they were using when I was paying attention
to this does support certificates.  In particular, their helpdesk
insisted that I was being too paranoid when I asked them for some way
to cryptographically verify their host key.  Eventually they sent me
completely unauthenticated mail with the fingerprint, but that didn't
really solve the problem I cared about the way I wanted it solved.)

(Also, I'm handwaving a bit in assuming that the web is always secured
using X.509, but at the moment, it basically is; I don't think my web
browser will do either krb5 or OpenPGP.)