Re: Suggestion for a new URL type

Marc VanHeyningen <mvanheyn@cs.indiana.edu>
From: Marc VanHeyningen <mvanheyn@cs.indiana.edu>
To: Rob Raisch <raisch@ora.com>
Cc: www-talk@nxoc01.cern.ch
Subject: Re: Suggestion for a new URL type 
In-reply-to: Your message of "Sat, 26 Jun 1993 15:59:37 -0400."
             <Pine.3.03.9306261536.R5397-b100000@amber.ora.com> 
Date: Sat, 26 Jun 1993 17:13:41 -0500
Message-id: <22625.741132821@moose.cs.indiana.edu>
Sender: mvanheyn@cs.indiana.edu
Thus wrote: Rob Raisch
>I strongly disagree.  The security issue is inherent in the network, not
>in URLs. We should not attempt to scale some moral high ground simply to
>stop up some possible security holes, which are not ours to stop up in the
>first place. 
>
>The answer to insecure network services is to make them more secure, not
>to limit the deployment and usefulness of URLs. 
>
>If a dedicated cracker wishes to break the system, I would suggest that
>writing an HTML document, and using that as a lock pick on doors which
>have no locks to begin with, would be a marvelous exercise in stupidity.

I believe we should have an attitude similar to that of MIME regarding
security:

- Security is more important than interoperability
- No additions should be made without a careful review of possible
  security issues
- User agents should present the user with sufficient information for
  the user to avoid possible traps, and should do so in a way that
  even a relatively inexperienced user can understand

Allowing an attacker to cause a victim to telnet to an arbitrary port
on an arbitrary machine and send arbitrary data certainly has some
potential risks.

Scenario:  Someone installs a document with a hyperlink that, when
activated, causes bad mail (say, a death threat) to be mailed to the
President of your organization/university/whatever.  You click on it.
Depending on the implementation of the client, you may or may not see
anything out of the ordinary, and you may or may not understand what
it means.  If the attacker is clever, it's labeled something like
"Click here to see some sample SMTP output."

Three days later, you are brought up on charges of mailing a death
threat.  An investigation of transfer logs, RFC 931 authentication
protocols, or whatever reveal that the message did come from your
account/machine (which is correct; it *did*.)  You have no idea what
happened.  Even if you did suspect a bad hyperlink, the offending HTML
document has been changed (and may have even been rigged by the server
to only look that way for you, and only once.)

That's just an offhand scenario.  It might also be possible to forge
postings (including control postings that do damage, like sendsys or
rmgroup or cancel) or muck with other widely used protocols.

Being able to do that kind of arbitrary URL referencing would have
some advantages, and would lessen the need for gateways; this is good.
My own inclination is that a client would have to take significant
steps to reduce the risk of problems, and that the advantage of this
kind of URL would be outweighed by the added inconvenience of users
being warned of arbitrary transactions for approval (not to mention
the trouble for client writers.)  That's just an inclination, though.
I'd be interested in the results of a security review; maybe it's not
as much a problem as I'm guessing.

- Marc
--
Marc VanHeyningen  mvanheyn@cs.indiana.edu  MIME, RIPEM & HTTP spoken here