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

From: [email-masked] (Julien Pierre)
Date: Wed, 03 May 2000 22:42:42 -0700

Hi,

I know this is an old messsage, but I must ask : has anybody tried to
implement this TLS upgrade draft ? Or is anybody contemplating it ?
I would certainly like to get the benefits of secure software virtual
servers, but I have concerns about this draft.

At first, as a server implementer, the proposal in this draft looks good,
and quite straightforward to implement . All I have to do is parse the
clear-text TLS upgrade request from the client, find the right keys and
certs for the virtual host requested, and upgrade the existing connection to
TLS. Also, I can force a connection upon the client if an ACL is set. This
is nothing major and looks clean.

However, upon further examination, there are logistical and security
problems with doing a TLS upgrade. Here are a few.

1) It is a fact that many server products out there use confidential data,
like application session keys, or other confidential state information, as
part of the URI.

Section 8.1 states :
"servers may apply resource access rules such as 'the FORM on this page must
be served and submitted using TLS'

Even if a server enforces such a restriction, the URI will already be
compromised as part of the TLS upgrade process, because it is transmitted in
clear by the client before the server instructs it to upgrade to TLS.

2) Nowadays, web users know if they have an http link that the connection is
not secure, and that if it's https it is secure (SSL). It's possible by
looking at the source for an HTML form to determine ahead of time if the
data you will submit will go out in clear or not. The new upgrade draft
makes it unpredictable, by its use of regular http URLs.

With the new draft, there may be http:// link on a web form, for example to
submit (POST) confidential data, made with the assumption that the server
has an ACL requiring a TLS upgrade and therefore that the connection will be
secured.

A current-generation HTTP client will create a request with the form data
from the user, and submit it in clear text to the server, compromising the
data even before the server gets a chance to deny it by requesting a TLS
upgrade with an HTTP 426 return code. This compromises security in order to
retain compatibility with existing HTTP clients. I do not think it is an
acceptable compromise.

3) Section 8.1 states :

"8.1 Implications for the https: URI Scheme

   While nothing in this memo affects the definition of the 'https' URI
   scheme, widespread adoption of this mechanism for HyperText content
   could use 'http' to identify both secure and non-secure resources.

   The choice of what security characteristics are required on the
   connection is left to the client and server.  This allows either
   party to use any information available in making this determination.
   For example, user agents may rely on user preference settings or
   information about the security of the network such as 'TLS required
   on all POST operations not on my local net', or servers may apply
   resource access rules such as 'the FORM on this page must be served
   and submitted using TLS'. "

When it comes to security, I don't think ambiguity is a good thing, and it
is not good to leave it entirely
"up to the client and server" to determine what security characteristics are
needed for the connection.
I think the draft should define at least one standard way to tell clients
that an upgrade is in order before connection establishment.

Take the HTML form example described in my second remark.

What is a new HTTP client aware of the TLS upgrade draft supposed to do when
submitting such an HTML form ? Should it always try first thing to upgrade
the connection to any HTTP server to TLS, before issuing any meaningful
request (containing URI and maybe also POST data) ?

That would certainly work technically and ensure best possible security, but
it would be a major waste of bandwidth in 99% of the cases since current
servers will not understand the upgrade request and reject it. Many existing
servers don't support keep-alive and will even close the connection,
introducing extra latency due to the need to reconnect.

It may also be a waste of CPU for both the server and client, since perhaps
the connection didn't really need to be secure, but ended up as TLS because
of the way the client negotiated the upgrade for every server, and the
server just accepted it.

I think a key problem even for a next-generation HTTP client that is aware
of the upgrade mechanism in this draft, and would be able to perform the
upgrade to TLS - is that the original HTML form fails to specify that the
client should not POST the data in clear, but must request upgrade to TLS.

There needs to be a way to inform the client to request security prior to
the establishment of the connection. I think something still needs to be
specified in the URL to let the client know ahead of time that security is
required for the connection. It cannot be a regular https:// URL since that
will not allow the server to differentiate the virtual host for which the
data is intended. I believe a clean way to do it is to instead have a
distinct protocol name in the URL.

Perhaps there should be other ways to specify it than a protocol name, and
perhaps it doesn't belong in the HTML and not HTTP specification, but I
think that this is a major hole in the draft. Certainly, a new protocol name
means that some clients will not be able to follow some links on new servers
that require a TLS step up, but I think it is acceptable in the name of
uncompromised security.

I believe there is another approach to solving this problem of tying secure
virtual servers to IP addresses. It is completely different than the
proposal in this draft, and does not address the issues of using dual ports
for non-secure and TLS, but I believe is is still relevant.

Instead of trying to define a mechanism to upgrade the connection from
non-secure to secure, the virtual host negotiation could be made a standard
part of the SSL/TLS protocols. I think that makes sense since these
protocols exchange certificates which are tied to the virtual host names.
This is how I would envision it would work :

Let's take two virtual hosts, say secure.sun.com and secure.netscape.com .
They both resolve to the same IP address.

A client wants to connect to https://secure.sun.com . The server happens to
present its public key with the certificate for secure.netscape.com . At
that point, the client normally brings a pop-up dialog saying that the
certificate doesn't match the host requested - which was secure.sun.com ,
then asks the user if he wants to continue, and the user usually stops the
connection.

Instead, the client would by default agree to communicate with the server on
the current SSL/TLS socket, specifically to issue a "virtual host change"
request for secure.sun.com .

The server would then realize that it also knows the key and cert for
secure.sun.com, and would be given the opportunity to renegotiate the SSL
connection with the client, this time presenting secure.sun.com's public key
and certificate. The client could then verify that certificate and accept
it, and the whole process would be transparent for the user.

As you will note, this process requires two full SSL/TLS handshakes, so it
is more expensive in CPU. But that can be optimized. The secure virtual
server could have a unique public key, with several certificates signing
that same key - one certificate for each virtual host. It would then only
have to transmit the certificate for secure.sun.com, without having to
transmit a different public key. This second certificate would satisfy the
client, and would be much faster since it would save a second full
handshake. As part of TLS, this process would be generically applicable to
any other type of TCP client/server application with TLS, not specifically
tied to HTTP.

If you have made it this far, I'm now waiting for all your objections, so go
ahead and shoot !

Scott Lawrence wrote:

> The secretariat didn't forward this announcement to this list, so I
> will.
>
> The only change from version -04 is the addition of the standard
> boilerplate and references  regarding the keywords (MUST, SHOULD,
> MAY, etc).
>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> This draft is a work item of the Transport Layer Security Working
> Group of the IETF.
>
>         Title           : Upgrading to TLS Within HTTP/1.1
>         Author(s)       : R. Khare, S. Lawrence
>         Filename        : draft-ietf-tls-http-upgrade-05.txt
>         Pages           : 13
>         Date            : 05-Jan-00
>
> This memo explains how to use the Upgrade mechanism in HTTP/1.1 to
> initiate Transport Layer Security (TLS) over an existing TCP
> connection. This allows unsecured and secured HTTP traffic to share
> the same well known port (in this case, http: at 80 rather than
> https: at 443). It also enables 'virtual hosting,' so a single HTTP
> + TLS server can disambiguate traffic intended for several hostnames
> at a single IP address.
> Since HTTP/1.1[1] defines Upgrade as a hop-by-hop mechanism, this
> memo also documents the HTTP CONNECT method for establishing
> end-to-end tunnels across HTTP proxies. Finally, this memo
> establishes new IANA registries for public HTTP status codes, as
> well as public or private Upgrade product tokens.
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-tls-http-upgrade-05.t
> xt
>
> Internet-Drafts are also available by anonymous FTP. Login with the
> username
> "anonymous" and a password of your e-mail address. After logging in,
> type "cd internet-drafts" and then
>         "get draft-ietf-tls-http-upgrade-05.txt".
>
> A list of Internet-Drafts directories can be found in
> http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>
> Internet-Drafts can also be obtained by e-mail.
>
> Send a message to:
>         [email-masked].
> In the body type:
>         "FILE /internet-drafts/draft-ietf-tls-http-upgrade-05.txt".
>
> NOTE:   The mail server at ietf.org can return the document in
>         MIME-encoded form by using the "mpack" utility.  To use this
>         feature, insert the command "ENCODING mime" before the "FILE"
>         command.  To decode the response(s), you will need "munpack" or
>         a MIME-compliant mail reader.  Different MIME-compliant mail
> readers
>         exhibit different behavior, especially when dealing with
>         "multipart" MIME messages (i.e. documents which have been split
>         up into multiple messages), so check your local documentation on
>         how to manipulate these messages.
>
> --
> Scott Lawrence      Director of R & D        <[email-masked]>
> Agranat Systems   Embedded Web Technology   http://www.agranat.com/

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

---

From: Rohit Khare <[email-masked]>
Date: Wed, 3 May 2000 23:10:57 -0700

At 10:42 PM -0700 5/3/00, Julien Pierre wrote:
>implement this TLS upgrade draft ?

Yes, Scott has, and some other Internet Printing Protocol folks.

>and quite straightforward to implement .

Thanks! Scott  & I will take all the credit for the fine editing job, 
and none of the blame for the ideas :-)

>like application session keys, or other confidential state information, as

Can't do much about that.

This is a general theme of my following comments. Guns can be pointed 
at feet. Triggers can be pulled...

>clear by the client before the server instructs it to upgrade to TLS.

In general, I suspect that a secure-real-time web application should 
be negotiating TLS *before* handing out a FORM at all. But even if it 
did, the following rule applies:

You can *never* prevent a client from publishing data in the New York Times.

If the user's filling in sensitive data, it's the user-agent's job to 
demand secure upgrades before sending as much as the server's, if not 
more.

>not secure, and that if it's https it is secure (SSL).

User behavior has little to do with TCP port numbers. On the other 
hand, nothing in the draft supposes that we will ever change the 
existing practice for Web Hypertext surfing applications.

>retain compatibility with existing HTTP clients. I do not think it is an

Don't send the FORM in the clear, either.

>needed for the connection.

There is no such thing as absolute security. It is always, in the 
end, in the eye of the beholders.

>that an upgrade is in order before connection establishment.

Yes, it does -- 426.

>introducing extra latency due to the need to reconnect.

Bala Krishnamurthy's PRO-COW compliance survey can tell you about the 
smaller fraction that don't support any form of keep-alive.

>of the way the client negotiated the upgrade for every server, and the

Purely as a matter of opinion, I'm worried about keeping Andy Grove 
employed, not the other way around :-) Someday, every packet will 
finally be encrypted, and the cycle-time argument is moot.

>It cannot be a regular https:// URL since that
>data is intended.

Sure it can -- interpret https: in a next-generation "client" as an 
invitation to first try Upgrade on port 80, then fall-back to 423.

>protocols exchange certificates which are tied to the virtual host names.

This has long been on the "to-do" list for TLS/SSL. Installed base 
strikes again, though, in making this case fairly unlikely. But I 
agree that's the "right" solution for so many more TLS/SSL enabled 
apps than HTTP alone.

Late night thoughts,
Rohit Khare

---

From: "Scott Lawrence" <[email-masked]>
Date: Thu, 4 May 2000 07:55:30 -0400

Rohit covered the ground pretty well, and all the points you raise
were discussed the first time around in one way or another, but I'll
reiterate a point or two.

Users have been trained to believe that an 'https:' scheme means
'secure', but what does it really mean?  What it means is 'try this
connection first on port 443 and negotiate (via the TLS/SSL
handshake) a set of security services'.  Key to this is
'negotiate' - the resulting connection could negotiate a set of
services using any of several cipher suites, including easily
breakable or null encryption.  The 'https:' is, in effect, a single
bit of information about how secure the connection for the request
should be, and that isn't enough to be meaningful.  A proper
comprehensive mechanism might provide for (for example) additional
attributes to accompany HTML href that would specify the minimum
required security services, but those don't exist and are outside
the scope of a protocol spec.

Several reviewers objected (as you have) to the fact that an http:
URL is exposed when first requested, and suggested that this
represents a 'leak' - it should only be used on a secure connection.
The implication is that content (such as the link) should never be
used over a connection less secure than the one over which it was
first obtained (I serve a document over a secure connection, the
user clicks on a link and exposes a piece of it on an unsecured
channel).  The problem with this argument is that web clients do not
now and never have had this rule - secured and unsecured content is
treated in the same way.  What is the security status (rules for
linking) of a document I get from a floppy given to me by someone
else who downloaded it?  If there is a need for labelling of content
with security attributes, then that need is best met in the content
itself, and the 'single bit' of appending an 's' to the scheme name
is grossly insufficient.

The spec also serves to complete the definition of how the HTTP
Upgrade mechanism should be used for any protocol change on an
existing connection.  When we actually tried to work it out for this
one case, we found that a number of issues (such as the lack of 426)
had not been addressed in the original 1.1 RFCs.

---

From: Rohit Khare <[email-masked]>
Date: Thu, 4 May 2000 09:48:14 -0700

>Bala Krishnamurthy's PRO-COW compliance survey can tell you about 
>the smaller fraction that don't support any form of keep-alive.

To be sure, the blame is also on Martin Arlitt's shoulders :-)

http://fog.hpl.hp.com/techreports/1999/HPL-1999-99.html

>PRO-COW: Protocol Compliance on the Web
>
>Krishnamurthy, Balachander; Arlitt, Martin
>
>HPL-1999-99
>990921
>External
>
>Keyword(s): HTTP/1.1; protocol; World Wide Web; compliancy
>
>Abstract: With the recent (draft) standardization of the HTTP/1.1 
>protocol on the Web, it is natural to ask what percentage of popular 
>Web sites speak HTTP/1.1 and how compliant are these so-called 
>HTTP/1.1 servers. We attempt to answer these questions through a 
>series of experiments based on the protocol standard. The tests are 
>run on a comprehensive list of popular Web sites to which a good 
>fraction of the Web traffic is directed. Our experiments were 
>conducted on a global extensible testing infrastructures that we 
>built to answer the above questions. The same infrastructure will be 
>used to answer questions like the percentage of the traffic flow 
>that is end-to-end HTTP/1.1 protocol compliancy and the subset of 
>features actually available to end users.
>
>23 Pages

The bottom line is that two thirds or more of public Web servers 
already support persistent connections.

Best,
Rohit Khare

---

From: [email-masked] (Julien Pierre)
Date: Thu, 04 May 2000 14:03:55 -0700

Hi,

> and none of the blame for the ideas :-)

I don't think you'll get away with that. See below.

> be negotiating TLS *before* handing out a FORM at all.

My question is : what would cause it to perform that TLS negotiation before hand,
since the URL is regular http ?

> But even if it

I don't think users will waste their time filling forms if they are not ahead of
time certain that it will be transmitted securely.
The user-agent can only warn after the negotiation fails, and the user only has
the option of discarding all the data he entered.

> existing practice for Web Hypertext surfing applications.

Maybe your draft is appropriate for your internet printing applications. But
clearly, it will not fill the needs of web surfers and ISPs who want to provide
secure virtual hosting without exhausting the IPv4 address space.

The duplicate TCP port number issue is IMHO less of a problem because it is rare
to exhaust all 2**16 possible TCP ports on a server. That would mean you are
running that many different daemons ...

> Don't send the FORM in the clear, either.

Again, how do you propose that the client make the decision to upgrade ?
Does it have to try to upgrade on every non-secure HTTP link ?
Will the browser prompt users for every link whether they want security ?

> end, in the eye of the beholders.

That's no reason to make it easier for people to shoot themselves in the foot,
which is what this draft does.

> >that an upgrade is in order before connection establishment.

Just how do you get a 426 before you establish a connection with the server ?
Take the case with my HTML form, residing on site a, a product catalog site,
which has no security.
It's got a link to POST the order data to site b , which is a secure virtual
server supporting TLS upgrade.
With your proposal, this link must be a regular http link.
What will cause the browser to negotiate security when the credit card
information is submitted to site b ?
I contend that there has to be something on the order page to tell it to do so. I
think it should be part of the URL, perhaps a protocol of "httpt" - to specify
http over TLS with upgrade.
The trigger cannot be a prompting option configured globally in the user-agent,
because it would not be practical for users to be prompted for security on every
regular HTTP request, and they would just disable it.

> smaller fraction that don't support any form of keep-alive.

Even so, the original point is bandwidth waste, and it is still valid.
To implement this, the user-agent must always initiate an upgrade request to the
server as its first request, then wait for the server to accept or ignore that
request. This also adds latency in the initial client request to the server,
which is delayed by this negotiation.

> finally be encrypted, and the cycle-time argument is moot.

I'm in very strong disagreement. Keeping Intel (or Sun, for the matter) in
business is not the issue.
You may not be aware of that fact, but in a typical secure web server today, the
overhead of doing encryption represents about 90% of CPU cycles spent. This means
a web server is an order of magnitude slower if it has to server secure
connections vs non-secure.

In turn, your proposal would result in an average tenfold increase in the
hardware requirement for servers, as well as waste of energy to power all those
CPUs, all for no good reason at all. Or the alternative would be a tenfold
increase in average web server latency, given no hardware upgrade.

I contend that there are web applications for which it's perfectly ok to not be
secured - for instant, accessing publicly available content. And there is a
minority of web applications where security is absolutely required, like
electronic commerce.

So far, I have never heard of a single application where security "would be nice,
but it's ok if it is not available" . This is what this draft really enables. I
call it a misfeature and I'm not eager to see it appear in mainstream HTTP
clients and servers.

I think it is necessary for a web application to be able to enforce security or
no security.

> invitation to first try Upgrade on port 80, then fall-back to 423.

No, this would break the semantic of the https URL.
When you specify an https URL nowadays, it implicitly tells the client to connect
onto the default https protocol port, which is 443, as long as the port is not
explicitly specified.
It is not very common, but I certainly have seen URLs of the form
https://mysite:443 , with the port explicitly.
But the biggest problem is , if a different port is specified.
What would be the behavior that you would propose for, say, an https://mysite:444
URL ?
Should the client skip the connection to port 80 and try TLS directly on 444 ?
This proposal seems shaky to me, because it effectively modifies the protocol by
virtue of running on a different port. I think the protocol should be able to run
on any TCP port without major behavior changes like this.

> agree that's the "right" solution for so many more TLS/SSL enabled

Good. I think I will join their mailing list. Any pointers ?

---

From: [email-masked] (Julien Pierre)
Date: Thu, 04 May 2000 14:28:47 -0700

Hi,

Scott Lawrence wrote:

> breakable or null encryption.

Agreed. However, one can disable the null & easily breakable cipher
suites in their client, and therefore be sure that when https URLs are
submitted, the connection is secure. The NULL encryption is by default
disabled in mainstream browsers.

>  If there is a need for labelling of content

I agree that it would be better to get more security information in the
content links than just that one "s" bit.

However, the complete lack of even that one bit to determine the
security attribute, which is what you propose by using regular http
URLs, is not merely grossly insufficient, but completely unacceptable.

I understand that you are trying to keep some level of compatibility
with existing clients, and at the same time trying to unify the ports
for secure/non-secure servers, and allowing secure virtual servers. I
believe however that none of the problems are solved adequately :

- existing HTTP clients will compromise security when connected to the
new servers, because they will not be able to negotiate the TLS ugrade
- existing HTTPS clients will not even connect to the new servers,
because the server will be expecting an initial non-secure connection
followed by an upgrade

This shows that it's not a practical solution for saving TCP ports at
this time. It requires an entirely new generation of servers and
clients, and even then there is still doubt about how the upgrade to TLS
is enforced, as mentioned in previous e-mails.

---

From: John Stracke <[email-masked]>
Date: Thu, 04 May 2000 17:39:49 -0400

> increase in average web server latency, given no hardware upgrade.

Just because a client always asks to upgrade doesn't mean the server has to obey.

--
/==============================================================\
|John Stracke    | http://www.ecal.com |My opinions are my own.|
|Chief Scientist |=============================================|
|eCal Corp.      |"HTTP is what happens in the absence of good |
[email-masked]|design." -- Keith Moore                      |
\==============================================================/

---

From: "Scott Lawrence" <[email-masked]>
Date: Thu, 4 May 2000 18:28:00 -0400

> From: Julien Pierre

> time certain that it will be transmitted securely.

If they are that concerned about it, then they should not fill out
forms that were not delivered securely.  If the form was delivered
over an unsecured connection, it may have been modified in any
number of ways to subvert the apparent intent of the form.  Browsers
don't normally expose the ACTION attribute of a form - an attacker
may have changed that, or modified field names - the possibilities
are endless.  Encrypting one exchange in a multiple exchange
transaction is no security at all.

> to exhaust all 2**16 possible TCP ports on a server.

The concern is with the well-known ports - a much much smaller
space.

---

From: [email-masked] (Julien Pierre)
Date: Thu, 04 May 2000 15:32:22 -0700

Hi,

> Just because a client always asks to upgrade doesn't mean the server has to obey.

So how does that make the draft useful if the upgrade is never allowed ?

---

From: [email-masked] (Julien Pierre)
Date: Thu, 04 May 2000 18:35:14 -0700

Hi,

> transaction is no security at all.

OK, assume the form was delivered on a secure server. Then it gets
submitted to somebody else - a virtual host on a payment processing
server - to actually process the transaction. This is very common. The
action URL will use regular http .
How does the security upgrade get triggered ?

One more thing to consider :
Let's say you are browsing a site and the connection got upgraded to TLS
. Then you sit idle for a while, and your keep-alive connection times
out. You are on a different part of the site now, filled with normal
http:// links. You click on one. The client has to reconnect. How does
the security get restored ?

---

From: John Stracke <[email-masked]>
Date: Fri, 05 May 2000 11:23:00 -0400

> So how does that make the draft useful if the upgrade is never allowed ?

Who said never?

A client that wants to use the draft can ask for an upgrade on every HTTP request.
Servers that aren't willing to spend cycles on TLS for a particular request can just
ignore the Upgrade: header.

--
/==============================================================\
|John Stracke    | http://www.ecal.com |My opinions are my own.|
|Chief Scientist |=============================================|
|eCal Corp.      |"God does not play games with His loyal      |
[email-masked]|servants." "Whoo-ee, where have you *been*?" |
|                |--_Good Omens_                               |
\==============================================================/

---

From: [email-masked] (Julien Pierre)
Date: Fri, 05 May 2000 17:22:36 -0700

Hi,

> ignore the Upgrade: header.

That still does not solve the problem !!!

If the client tries to upgrade to TLS on every request, it will fail 99% of the time,
because servers don't support it. Suppose in 1% of the cases it will actually work.

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. The only way for a user to make sure he does not mistakenly submit data
unencrypted is to setup his browser to prompt him on every single HTTP request that
didn't successfully negotiate TLS.

In other words, a waste of time 98% of requests. Do you really find that to be acceptable
?

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.

It would be as simple as a new type of "httpt" URL - which would tell the user-agent to
connect insecurely with the server, and immediately negotiate a TLS connection; and
otherwise not to proceed if the TLS upgrade fail. This cannot be a global user-agent
setting for reasons explained before - security is not always required nor desirable.

If you really want to get ISPs to stop wasting IP addresses on multiple secure servers,
as well as separate the ports, then you need to make it possible to create new secure web
applications that will work with the new user-agents and servers proposed in the new
draft, without incurring a high risk of falling back to non-secure connections. The draft
is currently too vague in the way that the security is enforced and makes it way too easy
to shoot yourself in the foot and end up with a non-secure connection if the negotiation
fails, rather than aborting.

---

From: [email-masked] (Julien Pierre)
Date: Fri, 05 May 2000 19:27:42 -0700

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.

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

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

---

From: John Stracke <[email-masked]>
Date: Mon, 08 May 2000 10:00:04 -0400

Julien Pierre wrote:

> because servers don't support it.

Servers that don't support it ignore it, because RFC-2616 doesn't provide an error code to
mean "I don't understand that Upgrade:".  (I just tried it on Apache 1.3.9 and 1.3.12, NES
3.6, and IIS 5.0; they all behaved exactly the same with and without "Upgrade: foo".) This
means that a client that sends the Upgrade: all the time won't break anything; it will cost
a few extra bytes, but not the extra round trips you're talking about.

--
/================================================================\
|John Stracke    | http://www.ecal.com |My opinions are my own.  |
|Chief Scientist |===============================================|
|eCal Corp.      |The cheapest, fastest, most reliable components|
[email-masked]|of a computer system are those that aren't     |
|                |there.--Gordon Bell                            |
\================================================================/