Re: [TLS] draft-rescorla-tls-renegotiate.txt

[Marsh Ray <marsh at extendedsubset.com>]

Michael D'Errico wrote:
> 
> A server can still negotiate an SSLv3 connection as it does today.
> It just can't re-negotiate that connection later.

But on the server question:

There is a large, but unknown, group of sites that really depend on
being able to serve different requirements for client certs from the
same IP.

For example, one development tool widely used in the industry is MS
Visual Studio 2005. It provides a nice IDE for developing web apps
(among other things). It has wizards all over the place. One will
generate a "web service" project, another will make an installer for it.
This WS architecture frequently uses client cert authentication and IIS
provides features to map client certs to OS user accounts. There are
other client auth schemes in use, too, pretty much anything supported by
HTTP. Server certs are expensive (or require approval to obtain) so I
suspect it's very common to serve web service projects requiring client
cert auth from the same hostname and IP as a web site that does not.

Just making an argument for how important per-request renegotiation is
in some deployments.

My guess is that any patch introducing an (SSLv3 xor renegotiation)
requirement is likely to cause a bit of headache. Consider the
possibility that a developer has an app that he tests and works fine on
his machine. But once he installs his app on the production server, all
the sudden some mysterious subset of clients (those using SSLv3) will
stop being able to connect to some different service which shares the
same IP address. Trial-and-error troubleshooting causes puts the blame
on the developer.

We should consider the possibility that it could introduce more (and
more confusing) incompatibilities than just deprecating SSLv3 outright.

> This is true for
> all TLS versions as well; you can still allow unpatched clients to
> connect, just not renegotiate.

I strongly suspect it also applies to many SSLv3 clients.

- Marsh