Comments on HTTP TLS Upgrade draft

Here are some comments on the draft-ietf-tls-http-upgrade-01.txt 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. Now to the comments:

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

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.

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

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.

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

What instead you *can* do is to provide a mechanism for making http: URIs
secure and for resolving https: URIs using HTTP just as well as ftp: URIs
can be resolved using an HTTP gateway. 

* 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 tunnelling 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. In order for the proxy to forward the request for
a tunnel, it must itself send a new OPTIONS * request which isn't sent on
behalf of the user agent but of the proxy because the two OPTIONS *
requests (the one from the user agent and the one from the proxy) are not
related in any way.

I believe the intended semantics (I call it "repeated hop-by-hop") can be
modelled 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.

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.

Furthermore the extension framework would allow for additional parameters
to be sent in the request, like for example the required key length etc:

	M-OPTIONS http://w3.org HTTP/1.1
	Host: w3.org
	Man: "http://www.iana.org/http/ext/tls"; ns=65
	65-keylength: 128

Something to consider,

Henrik

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

[1]
http://www.kashpureff.org/nic/drafts/draft-luotonen-web-proxy-tunneling-00.t
xt.html
--
Henrik Frystyk Nielsen,
World Wide Web Consortium
http://www.w3.org/People/Frystyk

Received on Saturday, 24 July 1999 11:19:01 UTC