Re: [Uri-review] ssh URI

David Booth <david@dbooth.org> Wed, 14 October 2009 04:20 UTC

Return-Path: <david@dbooth.org>
X-Original-To: uri-review@core3.amsl.com
Delivered-To: uri-review@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D2FDB3A6951 for <uri-review@core3.amsl.com>; Tue, 13 Oct 2009 21:20:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.317
X-Spam-Level:
X-Spam-Status: No, score=-3.317 tagged_above=-999 required=5 tests=[AWL=-0.033, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_MILLIONSOF=0.315]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NhmGpNXWgc61 for <uri-review@core3.amsl.com>; Tue, 13 Oct 2009 21:20:27 -0700 (PDT)
Received: from relay00.pair.com (relay00.pair.com [209.68.5.9]) by core3.amsl.com (Postfix) with SMTP id EEE6E3A6836 for <uri-review@ietf.org>; Tue, 13 Oct 2009 21:20:26 -0700 (PDT)
Received: (qmail 75921 invoked from network); 14 Oct 2009 04:20:27 -0000
Received: from 209.6.102.232 (HELO ?192.168.7.2?) (209.6.102.232) by relay00.pair.com with SMTP; 14 Oct 2009 04:20:27 -0000
X-pair-Authenticated: 209.197.102.232
From: David Booth <david@dbooth.org>
To: Eliot Lear <lear@cisco.com>
In-Reply-To: <4AD419D8.30907@cisco.com>
References: <20091009160149.GB16908@braingia.org> <1255366894.5481.8445.camel@dbooth-laptop> <5EAB4D387A4A4B7C854FBD1869729771@POCZTOWIEC> <1255395156.5481.10083.camel@dbooth-laptop> <81c242240910121816y4becb1aevae5008b23537df2c@mail.gmail.com> <1255398140.5481.10279.camel@dbooth-laptop> <81c242240910121855q52319dbatafb6ee46c3364ed@mail.gmail.com> <1255406578.5481.10704.camel@dbooth-laptop> <4AD419D8.30907@cisco.com>
Content-Type: text/plain
Date: Wed, 14 Oct 2009 00:20:26 -0400
Message-Id: <1255494026.25337.3062.camel@dbooth-laptop>
Mime-Version: 1.0
X-Mailer: Evolution 2.26.1
Content-Transfer-Encoding: 7bit
Cc: uri-review@ietf.org, uri@w3.org
Subject: Re: [Uri-review] ssh URI
X-BeenThere: uri-review@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Proposed URI Schemes <uri-review.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/uri-review>, <mailto:uri-review-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/uri-review>
List-Post: <mailto:uri-review@ietf.org>
List-Help: <mailto:uri-review-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/uri-review>, <mailto:uri-review-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 14 Oct 2009 04:20:27 -0000

On Tue, 2009-10-13 at 08:10 +0200, Eliot Lear wrote:
> On 10/13/09 6:02 AM, David Booth wrote:
> > 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.
> >    
> 
> 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.

Correct.

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

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.

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

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.

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

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