Roy T. Fielding fielding@ebuilt.com
Sun, 17 Jun 2001 23:09:44 -0700

On Sat, Jun 16, 2001 at 09:14:35AM -0700, Dan Kohn wrote:
> However, my read of RFC 3080 is that it is possible for the BEEP peer to
> provide a tuning profile that ONLY indicates upgrading to TLS (or
> whatever, including intricate combinations of transport and SASL
> profiles), and fails to return anything else.  See, for example, the
> long example at the beginning of section 3.
> In that case, no cleartext data communication is made.  Phrased
> differently, the first resource request -- if it is a request for a
> secure channel -- is always tuned in the clear, and so a single URL
> scheme should suffice.

Yes, if the protocol is designed such that the client must read a message
from the server prior to it sending any data across the connection, then the
security context can be established prior to the client sending data.
That is, assuming that the server knows what the security context should
be when it establishes the connection.

The problem with such a mechanism is that it doesn't work with intermediaries.
A client with a long-lived session connected to a peer acting like an http
proxy isn't likely to be negotiating a new channel context before making
each request.  Thus, such an architecture would require that all proxy
communication be restricted to the GCD of all possible security profiles,
unless the identifiers contain the security information regardless.

Fortunately, HTTP doesn't have that feature.  ;-)