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

Hi,

Scott Lawrence wrote:

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

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

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.

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