Re: Section on https

>> I didn't like it because it is just wrong.  Security policy can only 
>> be
>> negotiated if you decide to manage it prior to making a request, 
>> which is
>> obviously a bad idea for a protocol that does not require security
>> 99.999% of the time.
>
> I am not sure what you mean here.  To start a connection with HTTP and 
> then hand the TCP connection over to SSL always sounded an interesting 
> way to me. Client and/or server might require it, and they might want 
> it for various reasons.

The client in HTTP always sends the first message, after which it is
too late for the server to come back and say "you need to encrypt it
before sending".  Changing HTTP to wait for the server to send a
message first (like a session begin exchange in most other protocols)
would add about 600ms latency to every request across a typical
Internet connection.  That is why HTTP often appears faster than
other protocols even when the others have more efficient wire syntax.

It is a pity that the initial TCP/IP connection does not include a
"mandatory encryption" bit that would force the client to expand its
stack prior to sending the HTTP request, but even that has serious
drawbacks in that it would force a site to service all HTTP requests
with encryption or none of them (because, again, the server doesn't
know what resource is being acted upon until after the request is
received).

This is purely a question of efficiency/scalability versus privacy.
The latency of an initial SSL/TLS connection set up is huge.  It is
something that a person doesn't mind while working with a secure
forms-processing and session-based site, but they would mind a great
deal if it were to occur on every interaction (or even once per
persistent connection).

>>   It is therefore a better trade-off to separate
>> the need-to-negotiate services from those that don't need it, and the
>> only way to do that is by indicating the separation within the URI
>> because the client needs to know *before* the first request.
>
> One could argue that privacy and security and authentication should 
> all be visible up front - but it means you can't change them and it 
> means that the number of scheme names grows as the product.

Only privacy needs to be up front -- that is the only thing the browser
must know before revealing what it wants to access.  The others only
lose one round-trip, a latency cost, whereas privacy-leaks are a
safety cost.

>>   The
>> next question is then whether we want these services on the same
>> port as the unsecured protocol, and the answer is generally "no" since
>> that interferes with the ability to pipe-filter servers.  Finally,
>> would we want the same services to be available via both http and
>> https?  An emphatic "no" to that one, since it results in security
>> holes.
>
> On the contrary.  One might want user choice. The same service might 
> be available on HTTP to those inside a firewall, but by HTTPS by those 
> outside. One might want to be able to access the same images while 
> browsing a catalog using HTTP as one does later when order some items 
> with a secure connection.  A browser might want to go back and 
> re-access things it has in cache over a secure connection for security 
> (might, might not) but giving the secure one separate URIs is a > kludge.

I agree that one might want those things, but they don't come without
some inherent costs.  And while we might theoretically perceive some
benefit in going with some other solution than the "s" bit, it doesn't
belong in the webarch document until it is proven to work in practice.

An argument can be made that there is no need for "ftps", since that
protocol is session-based and extensions can be discovered before
the first request is made, but even then it would be a very
speculative argument that is not based on proven experience.

BTW, this issue was thoroughly discussed when the beep URIs were
defined, since privacy negotiation is an option within any BEEP
session.

....Roy

Received on Thursday, 4 December 2003 17:53:19 UTC