RE: Comments on HTTP TLS Upgrade draft

> From: Henrik Frystyk Nielsen [frystyk@w3.org]
> Subject: Comments on HTTP TLS Upgrade draft

> [...]
> First, I would like to say that I think it is crucial to the integrity of
> the Web that it become possible to negotiate transport stacks dynamically
> instead of using new URI schemes. [...]

We'll accept that as a supporting comment :-)

> * Chapter 5.1: There is no link between the use of the Upgrade header
field
> and the cachability of a response as you indicate in the second last
> paragraph. Upgrade is optional and it is fully ok for a cache to serve an
> already cached HTTP response either using HTTP or HTTP/TLS (if the cache
> chooses to honor the Upgrade header field). Obviously, it is not OK to do
> it the other way.

I believe that you are referring to:

   Furthermore a caching proxy SHOULD not reply to a request with
   Upgrade tokens from its cache.

The intent here is just to remind the proxy that Upgrade, as a
hop-by-hop header, is not appropriate to cache with a response and
forward as part of that response; it is not a property of the returned
entity, but of the immediate (in this case origin-proxy) connection.

> If the client starts with an OPTIONS request and the cache honors the
> upgrade request, subsequent requests on that secure connection must of
> course be served on top of the same secure connection.

The rules that govern what happens after any upgrade are those of the
protocol to which the connection has changed, and are therefor beyond
the scope of this document.

> * Chapter 7: Saying that the protocol is HTTP doesn't say a whole lot more
> about the service than saying that it is TLS.

> More importantly, the Upgrade header field is also intended to upgrade
HTTP
> itself, for example from HTTP/1.1 to some future HTTP/3.0. However, when
> you collapse HTTP and TLS into one token, you loose the capability (or run
> into a multiplicative explosion) expressing that the application would
like
> to upgrade to both HTTP/3.0 *and* TLS/1.0. Instead it is more useful to do
> it like this:

> 	Upgrade: HTTP/3.0, TLS/1.0

> In other words, there is no need for the "clustering" of Upgrade header
> field tokens.

We considered this alternative at some length, and at one point had
written the draft that way.  We liked the idea of the Upgrade response
header being able to specify a series of protocol tokens so as to
specify a stack to be used after the change.  We were not sure that
this would be understood, however.  RFC 2616 is vague on just what
multiple tokens could mean in an Upgrade response.  We elected for the
simpler set of expectations.

> A general problem with the Upgrade header field tokens is, however, that
> they do not allow for parameters to be passed along: How do I specify
other
> parameters such as required encryption strength, the scope of resources
> available through that secure link, etc? It should not be part of the
> extension mechanism to describe such parameters directly but it must be
> possible for the application to at least pass that information through.

The syntax just doesn't have a space for it (for some reason, even the
usual extension mechanism of 'stuff after a semicolon' was omitted
from the Upgrade syntax).  In any event, TLS provides for negotiation
of these parameters directly; I suspect that leaving option
negotiation to the protocol to which we are switching (as opposed to
trying to shortcut it by doing it in HTTP) is the better approach.

> * Chapter 9: There is no guarantee that "http://w3.org" and
> "https://w3.org" point to the same resource just as well as there is no
> guarantee that "ftp://w3.org" and "http://w3.org" point to the same
> resource. In general, it is not possible to declare that the http
namespace
> can take over the https namespace as you write in chapter 9.

It was not our intent to redefine the 'https' scheme, or to suggest
that implementations should somehow map it to this new mechanism.
That scheme exists and will forever mean HTTP over SSL on TCP port
443.  From the reactions we got, we were evidently not successful at
making this clear.

> * I think there is a problem with the OPTIONS method and how you specify
> that it should interact with the upgrade header field. The OPTIONS request
> can be forwarded all the way to the origin server as described in HTTP/1.1
> section 5.1.2. However, the Upgrade header field can't (which you also
> point out) as it is a hop-by-hop header field. For example, the user agent
> sends an OPTIONS request like this:

> 	OPTIONS http://w3.org HTTP/1.1
> 	Upgrade : HTTP+TLS/1.0
> 	Connection: Upgrade

> this will be forwarded through the first proxy as

> 	OPTIONS http://w3.org HTTP/1.1
> or
> 	OPTIONS * HTTP/1.1
> 	Host: w3.org

> Note that the proxy hasn't agreed on tunneling yet - it has only forwarded
> the request according to normal HTTP/1.1 rules. If the user agent instead
> sends a request like this:

> 	OPTIONS * HTTP/1.1
> 	Host: w3.org
> 	Upgrade : HTTP+TLS/1.0
> 	Connection: Upgrade

> then the request is intended for the proxy only (in the role as a server)
> and won't get forwarded.

I'm not sure that I agree with your interpretation of this latter
formulation - I think that they are both the same, but I'm afraid that
I do agree with your conclusion that the Upgrade header should not be
forwarded, which causes some problems with what we suggest as an
end-to-end solution.  It would require, in effect, that the user agent
understand the entire proxy chain and do a series of OPTIONS/Upgrade
requests to create secure connections through each individually (not
an optimal solution, IMHO).

I wonder what existing proxies really do with Upgrade; in particular:
 - Do they in fact forward it (incorrectly?) in a response if it is
   _not_ (incorrectly) listed in a Connection header?
 - Whether or not they react to it in a 101 response (our draft would have
   them switch to tunnel mode - what do they do today)?

> I believe the intended semantics (I call it "repeated hop-by-hop") can be
> modeled by the HTTP extension framework like this (and is sort of the idea
> of the CONNECT draft [1]):

> 	M-OPTIONS http://w3.org HTTP/1.1
> 	Host: w3.org
> 	Man: "http://www.iana.org/http/ext/tls"

> This request will be tunneled through the proxy because it doesn't know
the
> extension (or if it does then it will know what it must tunnel), or it
will
> fail and refuse to cooperate (which also is the case for the OPTIONS
> method). As the extension is not hop-by-hop, it will be forwarded all the
> way to the ultimate recipient.

That is still a change to an existing proxy, though - because it
requires that the proxy conform to the extensions draft.  I agree that
would be a good thing, but I don't think that it changes our situation
at all now.

> The response could of course still be a 101 Switching Protocols which
would
> then be propagated all the way back to the user agent and all
> intermediaries will already be in tunnel mode.

But will they be expecting to stay there for all subsequent requests,
or will they just switch to tunnel mode for the current request and
then expect to be 1.1 again afterwards?

> ps: Reference 7 ([7]) doesn't seem to be used anywhere

We didn't put the marker in - it is in the acknowledgements; will fix in the
next go 'round.

--
Scott Lawrence           Director of R & D        <lawrence@agranat.com>
Agranat Systems, Inc.  Embedded Web Technology   http://www.agranat.com/

Received on Monday, 26 July 1999 06:51:23 UTC