Subject: [Uri-review] ssh URI

From: Steve Suehring <[email-masked]>
Date: Fri, 9 Oct 2009 11:01:49 -0500

Hello,

Attached is a draft to be submitted to the IETF for URI scheme related 
to secure shell (ssh).  The draft was originally included in the secsh 
Working Group which has since concluded.  

http://tools.ietf.org/wg/secsh/draft-ietf-secsh-scp-sftp-ssh-uri/

I recently received a request to pick this draft back up and the 
co-author and I will be submitting it to the IETF under the Application 
Area.

Please provide feedback as appropriate.

Thank you for your time.

Steve Suehring

---

From: Křištof Želechovski <[email-masked]>
Date: Fri, 9 Oct 2009 19:51:50 +0200

1. [4.4] Outdated internal references: The parameters are not described in
section 4.1.
  2. [4.4] The syntax does not forbid having a nonempty path component but a
semantic for one is not described.
  3. [5.1] I would rather have 
ssh://[email-masked]?fingerprint=ssh-dss-c1-b1-30-29-d7-b8-de-6c-97-7
7-10-d7-46-41-63-87
for obvious reasons.
Please consider
Chris

---

From: Eliot Lear <[email-masked]>
Date: Fri, 09 Oct 2009 20:01:41 +0200

According to RFC 3986 you can have a ; in the userinfo.  Still I agree 
with the other reviewer.  It's asking for a kick in the teeth with some 
broken parser somewhere.

Elioty

On 10/9/09 6:01 PM, Steve Suehring wrote:
> _______________________________________________
> Uri-review mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/uri-review
>

---

From: 'Steve Suehring' <[email-masked]>
Date: Fri, 9 Oct 2009 15:42:54 -0500

Hello,

Thank you for the feedback.  Could you help me with #2 on your list?  We 
have this in the draft now:

"The SSH URI does not define a usage for a non-empty path element.  If a 
non-empty path element is included in an SSH URI then it SHOULD be 
ignored."

Should that specific sentence be amended or is there some additional 
clarification necessary?

Steve

---

From: Křištof Želechovski <[email-masked]>
Date: Fri, 9 Oct 2009 22:58:15 +0200

Thanks for the clarification.  In this case, the specification should say
that the path component MUST be empty.  It is confusing to have a feature
that serves no purpose.
Chris

-----Original Message-----
From: 'Steve Suehring' [mailto:[email-masked]] 
Sent: Friday, October 09, 2009 10:43 PM
To: K?i?tof ?elechovski
Cc: [email-masked]; [email-masked]
Subject: Re: [Uri-review] ssh URI

Hello,

Steve

---

From: David Booth <[email-masked]>
Date: Mon, 12 Oct 2009 13:01:34 -0400

I don't see a need to define a new URI scheme for this.  You can just
define an http URI prefix for this purpose, as described in
http://dbooth.org/2006/urn2http/

Furthermore, as Graham Klyne suggested during a similar discussion
earlier, "an HTTP URI can also retrieve a protocol [handler]
implementation"
http://lists.w3.org/Archives/Public/uri/2009Sep/0029.html
This could dramatically improve the adoption rate of a new protocol.

David Booth

-- 
David Booth, Ph.D.
Cleveland Clinic (contractor)

Opinions expressed herein are those of the author and do not necessarily
reflect those of Cleveland Clinic.

---

From: David Booth <[email-masked]>
Date: Mon, 12 Oct 2009 13:42:30 -0400

On Mon, 2009-10-12 at 19:07 +0200, Dan Brickley wrote:
> On Mon, Oct 12, 2009 at 7:01 PM, David Booth <[email-masked]> wrote:
> You'd really be advocating retrieval of SSH protocol handlers over
> untrusted HTTP connections? That's brave or something!

Good point.  For this application one would presumably choose an HTTP
URI prefix that starts with "https:" rather than "http:".  :)

---

From: Eliot Lear <[email-masked]>
Date: Mon, 12 Oct 2009 19:50:13 +0200

David,

I see some definite negatives to what you are suggesting:

   1. Requires some sort of consortia or legal framework.
   2. Requires an additional resolution.  SSH is commonly used for
      administration, and so I would be loathe to add that sort of step.
   3. Requires ssh applications to understand HTTP URI schema.

Or do I misread what you are suggesting?

Eliot

---

From: Steve Suehring <[email-masked]>
Date: Mon, 12 Oct 2009 12:53:31 -0500

I don't think that the http URI prefix is a good solution for the ssh 
protocol.  There is too much room for userland confusion which is 
undesirable due to the nature of ssh traffic.

Steve

---

From: David Booth <[email-masked]>
Date: Mon, 12 Oct 2009 14:55:59 -0400

>      1. Requires some sort of consortia or legal framework.

It does require something, but it isn't much -- just the maintenance of
a URI domain.  You could even base your URI prefixes on purl.org PURLs,
if want to permit the resolution to move around over time:
http://purl.org/docs/index.html

>      1. Requires an additional resolution.  SSH is commonly used for

No, it doesn't *require* an additional resolution.  The additional
resolution only comes into play as a fallback, if the client doesn't
know how to handle them as special SSH URIs.  

>      1. Requires ssh applications to understand HTTP URI schema.

No, they just need to know to recognize the special SSH HTTP URI prefix,
which might be something like "http://sshuri.org/".  This is no
different in principle from recognizing the special "ssh:" URI prefix if
a new scheme is used.

David Booth

---

From: Kristof Zelechovski <[email-masked]>
Date: Mon, 12 Oct 2009 21:35:05 +0200

David, you do not see a need to define a new URI scheme for anything, do
you?.  If I you do, please enumerate the requirements for a protocol that
would save it from the http black hole.
SSH is not a new protocol, and the "adoption rate" does not depend on the
URI; it is an agreement between the owner and the user that counts.  This
agreement already provides all technical information the user needs, and
explaining it over HTTP would not be useful.
And how would you persuade the Web browser to send an HTTP SSH URI to an
external handler instead of navigating to it?  (Think Internet Explorer, for
clarity.)
Chris

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of David Booth
Sent: Monday, October 12, 2009 7:02 PM
To: Steve Suehring
Cc: [email-masked]; [email-masked]
Subject: Re: [Uri-review] ssh URI

David Booth

---

From: Eliot Lear <[email-masked]>
Date: Mon, 12 Oct 2009 22:29:36 +0200

> know how to handle them as special SSH URIs.

 From a security standpoint, why is reliance on 3rd party by 
non-participants better than a hard error?

Eliot

---

From: "Daniel R. Tobias" <[email-masked]>
Date: Mon, 12 Oct 2009 19:51:51 -0400

> would save it from the http black hole.

It does seem to be an ideological position for some.

-- 
== Dan ==
Dan's Mail Format Site: http://mailformat.dan.info/
Dan's Web Tips: http://webtips.dan.info/
Dan's Domain Site: http://domains.dan.info/

---

From: David Booth <[email-masked]>
Date: Mon, 12 Oct 2009 20:52:36 -0400

> would save it from the http black hole.

You are correct that I see very little need for new URI schemes.  Nearly
all of what would be done by defining a new URI scheme can be done
(better, IMO) by leveraging http URIs.  

However, there *are* some inherent differences that I see between using
a new URI scheme and using http URIs, as described in
http://dbooth.org/2006/urn2http/#differences
[[
 * URI Length.  HTTP URIs will generally be longer.
 * Governing Authority.  New URI schemes must be registered with IANA,
whereas specialized HTTP prefixes may be defined by any URI owner.  This
may be a concern, both because IANA may be perceived as being more
reputable than other organizations, and because IANA provides a single
place to look for scheme definitions.  However, if this concern is
important enough, a registry of specialized HTTP prefixes could be
created by a reputable organization -- potentially even IANA.
 * Expectations.  Users discovering an xyzscheme URI expect it to be
governed by a separate specification, whereas users discovering an HTTP
URI with a specialized prefix may not realize that there is a separate
specification governing it (over and above the http scheme
specification).  This can be mitigated by educating users, and one good
way to do so is to serve useful metadata (indirectly) via the URI, as
described above.
]]

I *do* think that these differences provide reasonable grounds for new
schemes in some cases.  But I think proposers of new URI schemes far too
often fail to adequately explore the possibilities (and bootstrapping
benefits) of using http URIs and, in some cases, HTTP protocol
extensions.  I think there is a strong tendency to assume (erroneously)
that http URIs are limited to the HTTP protocol and thus dismiss them.
This has been quite evident in past discussions about proposed new
schemes.

I don't think I could enumerate all of the considerations important in
deciding whether a new URI scheme is justified, but I do think it would
be appropriate to play out the scenario both ways and compare the
results.  

For example, suppose an HTTP URI prefix were defined, such as
"http://sshuri.org?" (and as of this writing, that domain is available,
BTW).  And suppose that site were set up such that dereferencing one of
those URIs in a browser redirected to a page containing:

 - A brief explanation of SSH URIs, and pointers to tutorials and
specifications.

 - Downloadable software that would cause the browser to recognize such
URIs in the future, and handle them appropriately (i.e., by opening a
secure shell, rather than by fetching a page from sshuri.org).
Furthermore, such software might even be programmed to recognize and
handle the "ssh:" URI scheme as well.

How quickly would user clients implement SSH URIs this way versus if a
new scheme (only) had been used?

Basically, instead of *guessing* that the market would accept and
implement SSH URIs (through a new URI scheme), the HTTP URI approach
would provide a means to demonstrate that the market *had* accepted and
implemented support for SSH URIs.

> explaining it over HTTP would not be useful.

I was referring to the adoption rate for clients (such as browsers)
recognizing these new SSH URIs and using them for their intended
purpose.  A browser encountering a URI beginning "ssh:..." will not be
able to do anything useful with it until it knows the special semantics
assigned to the "ssh:" prefix.  But a browser encountering a URI
beginning "https://sshuri.org/..." could try to dereference that URI and
could be led to software that, once installed, *would* know to open an
SSH connection when encountering such a URI.  This could dramatically
improve the rate at which browsers learn how to handle these SSH URIs.
Make sense?

> external handler instead of navigating to it?  (Think Internet Explorer, for

The same way you would persuade it to launch an SSH connection when an
"ssh:" URI is encountered: the browser needs to know about the semantics
associated with that URI prefix.

David Booth

---

From: David Booth <[email-masked]>
Date: Mon, 12 Oct 2009 21:12:39 -0400

> It does seem to be an ideological position for some.

Excuse me?  By piggy-backing on http URIs, you can get easier, faster
adoption with more user-friendly fallback behavior.   To my mind that's
an engineering concern -- not an idealogical position.

---

From: Bob Aman <[email-masked]>
Date: Mon, 12 Oct 2009 21:16:33 -0400

> handle the "ssh:" URI scheme as well.

I have a problem with this in the general case because I don't think
there's currently a way for such a URI to be registered to a specific
application in any major browser.  And for the specific case, I can
think of at least one use case where you might want to link to an ssh
URI in a browser:  HTTP-based admin interfaces to machines.

And I'll also repeat my previous comment for emphasis:  This concept
is just confusing.

-1 to the concept of using anything under the http/https scheme to
formally represent an ssh identifier.

-Bob Aman

---

From: David Booth <[email-masked]>
Date: Mon, 12 Oct 2009 21:42:20 -0400

On Mon, 2009-10-12 at 21:16 -0400, Bob Aman wrote:
> application in any major browser.  

Take a look at greasemonkey:
https://addons.mozilla.org/en-US/firefox/addon/748 
Greasemonkey is based on recognizing URI patterns and performing special
functions when such patterns are recognized.

David Booth

> And for the specific case, I can

---

From: Bob Aman <[email-masked]>
Date: Mon, 12 Oct 2009 21:55:59 -0400

> functions when such patterns are recognized.

I'm familiar with greasemonkey.  Last I checked, greasemonkey didn't
launch applications so much as rewrite pages in place, and even if it
could, that's not even remotely user-friendly.  Beyond that, it's not
something that really applies outside of the Firefox ecosystem.  The
point isn't that it's not technically feasible, the point is that it's
a path that has way more technical and psychological hurdles to
overcome than getting a scheme registered with the IANA.

-Bob Aman

---

From: David Booth <[email-masked]>
Date: Tue, 13 Oct 2009 00:02:58 -0400

> overcome than getting a scheme registered with the IANA.

Getting a scheme registered is the *easy* part.  The hard part is
getting millions of installed clients to implement the special
recognition of that scheme.

---

From: David Booth <[email-masked]>
Date: Tue, 13 Oct 2009 00:20:36 -0400

On Tue, 2009-10-13 at 12:35 +0900, Conrad Parker wrote:
> 2009/10/13 David Booth <[email-masked]>:
> >
> Encouraging end-users to download ssh client software from a random
> web site specified by a third-party web-page author, and then
> (automatically) using that software to connect to the desired ssh
> server ... and hoping that this is somehow secure by using an SSL/TLS
> connection to access that software?

It wouldn't be a random web site, it would be the official web site of
SSH URIs!  That's no more random than mozilla.com or adobe.com, from
which software is routinely downloaded thousands of times a day.

> 
> No, this does not make sense. It encourages use of untrusted ssh
> client software (eg. not sourced from your operating system vendor,

That's a policy choice that should not be baked into the technical
design.  Making the software more difficult to obtain is a minus, not a
plus.

> unsigned etc.) 

Any such software certainly could and should be signed.

> so the scheme could be easily exploited by a third
> party to serve an ssh client with a backdoor. 

That's no different than access to *any* web site.  *Any* site can try
to serve up a trojan horse.  But that doesn't mean that there isn't
value in visiting web sites and value in making information and software
more readily available with existing mechanisms.

David Booth

> Using https to access
> that info/software does nothing to secure the initiation of the ssh
> connection.
> 
> If anything, ssh provides a good use-case for a custom uri scheme.
> 
> Conrad.
> 
>

---

From: John Cowan <[email-masked]>
Date: Tue, 13 Oct 2009 00:27:05 -0400

> recognition of that scheme.

No harder than getting them to recognize a load-ssh-protocol-driver
meta-scheme.

-- 
Eric Raymond is the Margaret Mead               John Cowan
of the Open Source movement.                    [email-masked]
        --Bruce Perens,                         http://www.ccil.org/~cowan
          some years ago

---

From: Eliot Lear <[email-masked]>
Date: Tue, 13 Oct 2009 08:10:32 +0200

> recognition of that scheme.

I agree, and I think what you're proposing is interesting along those 
lines.  I also appreciate your answers to my earlier questions.  Right 
now we have no guidance or analysis that goes into the associated risks 
of what you are proposing.  A few examples of things that can and will 
go wrong with non-participants:

1.  A query goes out to a third party, and the site is down or 
unreachable.  In this case, the non-participant will hang in an 
unspecified way rather than get a hard error.
2.  A query goes out and the third party has been compromised.  And in 
this case, the third party is a really attractive target because one can 
map administrative resources with SSH.  Worse, the client acts on the 
meta-information in some way, leading to additional compromises.  You're 
already using redirects.  So what can a bad guy redirect to in order to 
make things interesting?  Well, he's got a Browser: header.  Perhaps he 
redirects to an appropriate exploit.

Now to be fair to you, I haven't done the analysis to say, "this is 
ABSOLUTELY a problem", but nor have I seen an analysis from you that 
leads me to conclude that this is not a problem.

Eliot

---

From: Kristof Zelechovski <[email-masked]>
Date: Tue, 13 Oct 2009 10:26:44 +0200

The browsers, at least the ones I have used, do not know the semantics about
URI schemes, except for the ones they handle internally.  They do not need
that to launch an external client or to invoke a plug-in which, at
installation, informed the browser that it can handle such schemes.  As has
already demonstrated, there is no such mechanism for URI prefixes, and
indeed there should not be because the surprise factor is too big.
There is no value in educating browser users how to connect to random SSH
servers because every such connection is backed by a preceding contract
between the provider who runs a server and the customer who is allowed to
connect.  So there is nothing to discover here.
Best regards,
Chris

---

From: Bob Aman <[email-masked]>
Date: Mon, 12 Oct 2009 18:58:18 -0400

> undesirable due to the nature of ssh traffic.

I have to agree with Steve on this.  I'm already terribly confused by
David's suggestion.

-Bob Aman

---

From: Conrad Parker <[email-masked]>
Date: Tue, 13 Oct 2009 12:35:25 +0900

No, this does not make sense. It encourages use of untrusted ssh
client software (eg. not sourced from your operating system vendor,
unsigned etc.) so the scheme could be easily exploited by a third
party to serve an ssh client with a backdoor. Using https to access
that info/software does nothing to secure the initiation of the ssh
connection.

Conrad.

---

From: Dan Brickley <[email-masked]>
Date: Mon, 12 Oct 2009 19:07:31 +0200

Dan

---

From: Dan Brickley <[email-masked]>
Date: Mon, 12 Oct 2009 21:59:48 +0200

> external handler instead of navigating to it?  (Think Internet  

...which in turn would have rather awkward privacy characteristics.

A custom scheme makes sense to me.

Dan

---

From: Dan Brickley <[email-masked]>
Date: Tue, 13 Oct 2009 09:44:04 +0200

[snip]

David,

Can I suggest a new workflow for these ideas?

Instead of intervening when every new URI scheme proposal comes
through these lists, perhaps you could work to persuade the W3C TAG of
them instead? I think I understand where you're coming from, but the
approach is pretty alien to URIs as currently deployed, particularly
with regard to browser infrastructure, which at the moment is
universally keyed off of the scheme prefix and unlikely to change
rapidly due to the huge security implications.

There might be something in these ideas (though I remain generally
skeptical when it comes to protocols - such as ssh - rather than
content/object identifiers eg. doi, xri, ...). At the moment they're
being discussed in an ad hoc way whenever someone proposes a new
scheme. Could it be more efficient to propose and refine them through
the TAG, perhaps?

cheers,

Dan

---

From: Ted Hardie <[email-masked]>
Date: Tue, 13 Oct 2009 12:19:54 -0700

While I applaud the basic sentiment of not having this discussion
every time a new URI scheme comes up, I think you'd have to persuade
the IETF rather than the TAG.  The IETF is responsible for URI
registration, and the documents are pretty clear on that point.  The
IESG and IAB take the TAG's input very seriously, of course, but the
question of URI registration is one where there has been divergence
for some time.  As the discussion above notes, having HTTP always in
the URI loop may make sense for the web; it doesn't work for other
deployments and other protocols.

I personally agree with those saying ssh ought to be an independent
scheme.  It has a widely installed user base and I have seen
individuals use ssh:hostname as a pseudo-URI for some time.  Pushing
out a real spec for the URI scheme would avoid interoperability
problems there, and that in itself is goodness.

2 cents from:

Ted Hardie

---

From: Dan Brickley <[email-masked]>
Date: Tue, 13 Oct 2009 21:35:31 +0200

On Tue, Oct 13, 2009 at 9:19 PM, Ted Hardie <[email-masked]> wrote:
> the IETF rather than the TAG.

You're right, of course. I should have put it differently. I meant to
express gently that if anyone around here is going to be persuaded of
this approach, it's most likely to be the TAG. Or at least the TAG
might be the right forum for knocking the ideas into more widely
appealing shape. If they're persuaded, then the approach would be
worth requesting serious review from other parties, chief amongst
those being IETF.

>                                                    The IETF is responsible for URI

Yes. Even in W3C circles there are a fair number of different views
bouncing around.

I spent a while re-reading the early years of www-talk today, and it's
a bit disheartening how much the same old questions are still bouncing
around 18 years later. And I'm sure not so fun for people just trying
to register a scheme who get dragged into this decades-long
permadiscussion.

> problems there, and that in itself is goodness.

Completely agree...

cheers,

Dan

---

From: David Booth <[email-masked]>
Date: Wed, 14 Oct 2009 00:19:39 -0400

> No harder than getting them to recognize a load-ssh-protocol-driver

I disagree.  If a client doesn't recognize a new scheme, the user has
little choice but to search around for an implementation or hope that
the client vendor adds support for it in the future.  But if an http URI
is used, the URI (as a fallback) could dereference directly to a page
providing information about those new URIs, where to download client
software that supports them, and -- potentially -- even attempt to
auto-download a client extension for them.  This certainly seems like it
would encourage faster adoption.

---

From: David Booth <[email-masked]>
Date: Wed, 14 Oct 2009 00:20:26 -0400

> unspecified way rather than get a hard error.

Correct.

> redirects to an appropriate exploit.

Yes, this is a risk.  But it is a similar risk as for any site that
provides downloadable software.  Ultimately, when offered information
(or software) the user must decide whether to trust it.   But this
doesn't mean that there isn't benefit to offering such information (or
software).  We mustn't throw the baby out with the bath.

> leads me to conclude that this is not a problem.

Likewise, I have not done the analysis to say "this is absolutely NOT a
problem".  But I do think the potential benefits are enough to warrant
more thought.

---

From: David Booth <[email-masked]>
Date: Wed, 14 Oct 2009 00:21:56 -0400

Some comments:

 - Until there are clear criteria for deciding when a new URI scheme
should be used, these discussions will be unavoidable and necessary.  

 - It is quite clear from these discussions that the possibilities and
benefits available through piggybacking on http URIs are not well
understood by many of those who have been proposing new URI schemes.
The confusion that has been expressed when the idea has been proffered
clearly illustrates this.

 - There is an existing W3C TAG issue related to this, though not
specifically about criteria for registering new URI schemes:
[[
HTTPSubstrate-16: Should HTTP be used as a substrate protocol? Does W3C
agree with RFC 3205?
http://www.w3.org/2001/tag/issues.html#HTTPSubstrate-16
]]

 - I actually think an ssh: scheme is one of the most justifiable
proposals for a new scheme that I have seen lately, because ssh already
has widespread adoption, and I would not be at all upset to see it go
through.  In the long run it would be convenient.  But the ability to
serve useful information and software as a fallback for clients that do
not recognize SSH URIs is an undeniable benefit of http URIs, and I do
not think any proposal for a new scheme should be considered complete
without serious consideration of these potential benefits. 

 - BTW, http URI prefixes and new schemes do not need to be mutually
exclusive.  It is also possible to define *both* a new URI scheme *and*
an http URI prefix for the same purpose -- as synonyms.  For example,
both the "ssh:" and "http://sshuri.org?" prefixes could be defined.  By
first using URIs that are based on the http URIs, support for the SSH
URIs could be bootstrapped faster, because http URIs can dereference to
information and software to support *both* prefixes.  Later, when nearly
all clients support these prefixes, authors could start using the
briefer "ssh:" versions of the URIs.  This of course would have the
downside of creating pairs of URIs that mean the same thing.  But it
would provide a faster adoption path.

In short, although I think there is some good justification for defining
a new scheme for SSH, I don't think the http-based alternatives been
adequately explored yet and the pros/cons weighed.

David Booth

---

From: Steve Suehring <[email-masked]>
Date: Wed, 14 Oct 2009 07:49:28 -0500

David,

Thank you for your input on the http prefix for the ssh uri.  I think 
the general consensus and what I'm reading from your message indicates 
that we'll continue to move forward with the ssh draft as-is, opting for 
a new uri scheme as you indicate.  

We have some revisions to make to the draft itself based on feedback 
here about the location of the fingerprint and feedback from from the 
ssh working group mailing list.  When we get that revisions settled 
we'll submit it back to these mailing lists for a final walkthrough.

Thanks everyone for their input.

Steve

---

From: Paul Prescod <[email-masked]>
Date: Wed, 14 Oct 2009 07:36:08 -0700

On Fri, Oct 9, 2009 at 9:01 AM, Steve Suehring <[email-masked]> wrote:
> ...

> Please provide feedback as appropriate.

What does SFTP support GET and not PUT?

Is the syntax/protocol of directory listings standardized elsewhere?

What happens if I open a directory without the correct typecode? My
potentially naive impression is that the whole typecode thing adds
more complexity than value: it is easy to pipe the output into a tool
that does the right newline conversions.

What happen to scp URLs?

The assertion that the ssh URI scheme is designed to invoke an
interactive terminal session strikes me as expressing a user interface
decision, which URI schemes typically do not.

I would reword it this way:

The intended usage of the SSH URI is to declare the existence of an
SSH listener. This information could be used (for example) by a web
user agent to invoke an interactive SSH terminal program, or as input
to a script that would automate some action on the remote host."

It would be nice if a server could configure a list of "safe commands"
that it would accept as parameters. A future curl might allow this:

curl ssh://[email-masked]?uptime > remote_uptime.txt
curl ssh://[email-masked]?ifconfig > remote_config.txt

The server config might be as simple as a list of commands that are
whitelisted for use this way.

 Paul Prescod