Re: draft-ietf-tls-http-upgrade reissued

Hi,

Rohit Khare wrote:

> You know, we send the HTTP/1.1 and Host: tokens 100% of the time.
> Isn't that wasteful, too?

Not as much. I meant also that the 98% of the time security pop-up *
millions of users would be a huge waste of time. I'm sure most everyone
would disable the browser setting if it existed.

> >Now, suppose that in 2% of the cases, the request data was intended
> >to be confidential
> >and the user really didn't want to submit the data unsecured, but
> >the server didn't
> >negotiate TLS.
>
> This client would have to force the upgrade via OPTIONS as outlined
> in the spec.

But how would the end-user inform its client of the fact that he wanted
the data to be secure ? You would have to remember to "force" security
somehow before submitting on a form ?

The security requirement is usually dictated by application logic. I
think the web application should have a way to hint the client, in the
way of something in the referring document, so that it would happen
transparently.

I'm not criticizing the underlying network protocol. I'm criticizing the
URL specification that clients will use.
The server will support both HTTP and HTTP with TLS upgrade. But there is
no good way for the client to decide when to use which, since http://
URLs are used.

> >The whole point I'm trying to make is that there should be a way for
> >a web application
> >that is intended to be secure to enforce that fact and reasonably
> >function on a server
> >running on a common port with HTTP and TLS upgrade support. The
> >draft does not propose a
> >way to do that.
>
> We believe it does, the last-call in the working group and the ietf
> announce list believes it does, and now it falls to all of us,
> including yourself, to find out if any of that rough consenus can be
> backed by running code.

I am quite confident that I can, but I'm not convinced yet that this is
the right way to do it.

> An "application" -- say,
> http://www.foo.edu/randompath/ReallySecureApp.cgi should send back a
> 426 for ANY request for a resource under /randompath/. A "user" who
> requires the same can use OPTIONS. A user who does not care, but
> wants to follow the lead of the server, should reuse the Upgraded TLS
> connection as long as he would have an equivalent port 443.

Again, what mechanism tells the client to use OPTIONS ?

> And recall that this method is *not* being proposed as the idea for
> hypertext publishing. The common browser is too deployed to be
> changed in its ways.

I don't think that's true. The rate of adoption for new HTTP software may
not be what it was in 1994 - 1996, but HTTP is still evolving, and there
is still an evolution in the mainstream browsers and servers. In fact,
the whole reason I'm here on this list is that I'm trying to make the
Netscape server support this evolution. I know some Netscape client
engineers are reading this as well, and they would like to make it happen
on their side too.

The fact is, routable static IP addresses have become expensive due to
the fact that we are quickly running out of them. ISPs want a way to do
secure software virtual servers, without buying expensive IP addresses
for each. There is a demand in the marketplace for this, maybe not
necessarily for the purpose of hypertext publishing, but certainly for
electronic commerce. Since the current protocols do not allow this, the
solution calls for a new generation of servers and clients. It will
certainly take time to upgrade a significant portion of HTTP clients and
servers in use today, but I think it can happen gradually. My wish is to
see it happen using open IETF standards in the next generation of HTTP
servers and clients, rather than have to wait for the one after that,
once the quirks in the current specs are acknowledged.

--
for a good time, try kill -9 -1