Re: [TLS] COMMENT: draft-ietf-tls-renegotiation

[Nelson Bolyard <[e-mail]>]

Peter Saint-Andre wrote:
> On 12/15/09 9:31 AM, Marsh Ray wrote:

>> Why should we keep renegotiation?
>>
>> Because any spec which "drops" it is just going to be ignored, with the
>> side effect of the industry dropping the IETF rather than the IETF
>> dropping renegotiation.
> 
> Given that the TLS WG list is full of discussion about remaining
> backward-compatible with SSLv3, it's not clear if the industry is paying
> attention to the IETF anyway.

There is a small number of individuals in this list who are generating a
very high volume of traffic arguing that it is necessary to preserve
backward compatibility with servers that are not only SSL 3.0 but a subset
thereof that is intolerant of any hello extensions and of client hellos
that bear any higher version than 3.0, being unable to successfully
negotiate an SSL 3.0 handshake in the presence of either.

If one judges purely by the volume of traffic in the list, one might conclude
that the industry as a whole is behind that position.  But I believe that
conclusion would not be supported by an actual poll of vendors of SSL 3.x
(including TLS 1.x) server products.  I think we are merely hearing from a
very vociferous minority who hopes to defeat the current draft by filibuster.

>> Removing support for (i.e., not fixing) a fundamental and widely-used
>> protocol feature like renegotiation is not an option.
> 
> I think the question Russ raised is: just how fundamental is TLS
> renegotiation? And the answer so far seems to be: some deployments seem
> to use it, but it might not be fundamental.

I believe it is very heavily used in business-to-business https transactions
including so-called intranet transactions, where parts of a web site require
different authentication than the rest.

Several alternatives have been proposed to achieve those same ends without
renegotiation, such as using separate logical servers on separate ports
each with its own authentication requirements that are enforced on the
initial handshake, rather than during renegotiation.  These proposals all
present numerous challenges, any of which is orders of magnitude greater
for the many shops that would need to implement them than merely deploying
a "safe" version of renegotiation.  Numerous server vendors have expressed
that they believe their customers would rather live with the vulnerability
than be faced with completely refactoring all their https web sites, and/or
multiplying the number of deployed reverse proxies.