On Sat, 2004-07-10 at 21:07, Mukund wrote:
> Support and absense of support for TLS are advertised as capabilities
> by the server, upon connection. The client also MUST respond with the
> capabilities in its response to the server. The capability word is
> `starttls' for TLS support and `nostarttls' for no use of TLS (without
> the quotes) for both the client and the server. Both the server and
> client MUST respond with at least one of these capabilities, i.e., they
> can't respond without at least one of these capabilities in their list
> of capabilities.
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.
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.
> the server ignores the `url' argument and responds with
Here we have a dilemma. Either:
* The client provides the URL before TLS negotiation, which allows the
server to use a different certificate and client cert database for each
repository, but doesn't protect the URL from eavesdropping or
modification. (The URL could be specified again in the TLS-protected
stream to prevent modification.) Or,
* The client does not provide the URL before TLS negotiation, so the
URL is protected. But the server's certitificate and client cert db is
fixed for all repositories.
HTTP does it the second way, which (as I understand it) interferes with
https virtual hosting using a single IP address and port. I don't know
what the right answer is; if we think of the URL as like the address and
port (part of what you can get with "traffic analysis"), then the first
answer might be okay.
> starttls: ( success ( starttls ) )
Why the "starttls" literal?
I'm not even sure there's a need for a round trip here. It should be
okay for the client to just launch into the TLS negotiation right after
sending the client response, assuming both the server and client
specified the tls capability. Particularly if we decide the client
isn't providing the URL in its initial response in the TLS case.
> If the client decides that the level of authentication or privacy
> is not high enough for it to continue, it SHOULD close the connection
> immediately after the TLS negotiation is complete. If the server
> decides that the level of authentication or privacy is not high
> enough for it to continue, it SHOULD reply to every command from
> the client with a failure command response (with a possible message
> string such as "Command refused due to lack of security").
I think the server can just send an error in its auth challenge and
close the connection.
> The list of capabilities returned by the server after the TLS
> handshake MAY be different than the list returned before the TLS
> handshake. For example, the server might not want to advertise
> support for a particular SASL mechanism unless a client has sent
> an appropriate client certificate during a TLS handshake.
SASL mechanisms aren't advertised in capabilities.
> A common approach which was adopted by many protocols for TLS support
> was to have a different port number with 's' suffixed to the URI scheme.
> Nowadays it is considered by many people to be a bad idea. Extending the
> protocol is recommended instead. A good list of points to support this
> argument can be found in section 7 of IETF's RFC 2595.
Having read this list several times, I can agree that a separate port
number is unnecessary, but I still can't help but feel that an "svns"
scheme, using the same port, would make a convenient shorthand for "svn
protocol, fail if TLS not negotiated with authenticated server
certificate and strong encryption."
> Another point to
> add to that list is the case of some protocols such as HTTPS and virtual
> hosting which suffers from the chicken-and-egg problem and hence needs a
> unique IP address per domain, as the virtual host to connect to cannot
> be specified by the client to the server until the TLS is established
> and operational, and the server is to return a certificate with the
> host's domain name in the CN field during the TLS setup.
I'm confused. The chicken-and-egg problem appears to be orthogonal to
whether a separate port is used, and it seemed like your proposal had
the chicken-and-egg problem.
Separate from all this, I have an implementation concern: I think the
OpenSSL library is only thread-safe if you provide it with locking
primitives in the single-threaded environment, and our client library
has no means of doing that.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sun Jul 11 05:13:19 2004