On Sun, 2004-07-11 at 08:04, Mukund wrote:
> > I think this is an abuse of capabilities. Capabilities should be about
> > what the server or client is capable of, not about policy. A single
> > "tls" capability should be adequate.
> I intended the policy to be automatically adopted based on the
> capabilities. We could use a command instead, but I wanted the protocol
> to enforce TLS if the capabilities were present. The side effect of
> enforcing capabilities is the client and server playing with these
> capabilities to turn TLS on or keep it off.
I think you may have misunderstood me. I'm not suggesting we use a
command to initiate TLS; I'm suggesting that if the server sends the
"tls" capability, and the client sends the "tls" capability, we do TLS
negotiation right after the client response. I don't see a need for a
"notls" capability which has no effect other than to help a new
non-TLS-supporting client recognize more quickly when it's not going to
get in.
> > Your goal here may be to avoid round trips, but I don't see that it's
> > necessary. If the server wishes to mandate TLS, it can generate an
> > error in response to a client response which doesn't mention the TLS
> > capability.
>
> In this case the server will also have to send command responses
> of failure on every command until the command to start TLS is sent by the
> client.
Normally, if the server sends an error in response to the client
response, it closes the connection.
> I did not think of virtual hosting with SVN when writing this,
> but it is a good idea.
Okay. Either the client can send the URL truncated at the hostname
part, or we can rely on the TLS extension David mentioned, if it's
implemented in the library we use. Whichever's easier to implement, I
think.
I note that the server certificate is not the only issue; different
repositories may also have different databases of user certificates for
user authentication. But I guess the server can just hold onto the
client certificate until the full repository URL is specified.
> This is a server response. It is generated to indicate a success
> or failure to the client on whether to go into the TLS handshake.
It seems simplest to just always do SSL in this case. If the server has
no certificate for the specified host, it can perform a handshake
without sending a server certificate. If that's okay with the client,
the connection might still reap the benefit of being opaque to passive
eavesdroppers, using a Diffie-Hellman exchange.
> > SASL mechanisms aren't advertised in capabilities.
>
> This is not what I understood from section 2 of the protocol
> document. After the greeting command-response's syntax, there is a
> paragraph following it which reads:
Whoops. The sentence you're quoting dates back to version 1 of the
protocol. I'll take it out.
> Yes this is a good idea. We could have a special suffix to the
> scheme as an alias to having it in the config file. Do you think keeping
> it the same as other protocols, i.e., the "s" part is a good idea?
Maybe, maybe not. It depends on what people read out of that final "s".
At a certain level of understanding, people will read in the expectation
that "svns:" indicates a secure connection, which is good, because
that's what we'd be ensuring. At a higher level of understanding,
people might read in a connection on a separate port with an immediate
TLS negotiation, and become confused because we don't do that ("what
port do I have to open for svns connections?").
Whatever we do to mark up the URL for this purpose (or, if we don't mark
up the URL, to mark up the command), I think it needs to be short. So
the 's' suffix is appealing on those grounds.
> The chicken-and-egg problem happens because any protocol with the
> 's' scheme suffix for TLS assumes that even before a single octet of
> protocol communication happens, TLS is established.
True for existing 's' protocols, certainly, but it's not written in
stone.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sun Jul 11 18:04:13 2004