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

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.

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

Received on Thursday, 4 May 2000 05:01:18 UTC