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

[Martin Rex <[e-mail]>]

Nelson Bolyard wrote:
> > 
> > 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.

more than 90% of the world are on TLSv1.0 + SSLv3 combined.


> 
> 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.

This misrepresents facts.

What I am arguing for is that a solution does not need to unnecessarily
create interoperability problems that can be easily and reliably avoided.

If this solution should be patched into the installed base, then it
should address the issues of the installed base!

If you think the installed base doesn't matter, then you should
rather propose to defer the solution to TLSv1.3.


> 
> 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.

The open IETF standards process is about discussing technical
issues and providing solutions to technical issues.

A few valid technical issues that have been raised against
TLS extension RI, and not yet been addressed with sufficient
clarity.

Some issues were of the type
"I can not do this-and-this to my installed base".

And some answers have been
"Tough luck.  My installed base doesn't have that problem and
 I don't care about yours."


This would be OK if we were discussing about optional features of
a new protocol.  But we are actually discussing about a strongly
recommended, backwards-incompatible change to the entire installed
base that becomes as mandatory as it can get for protocols that
were finalized many many years ago.


A broken or incomplete patch that is widely distributed will
create much more damage than not shipping a patch at all,
and ultimately, a conforming patch based on a broken or
incomplete spec will create even worse problems.

The TLS renegotiation vulnerability itself is compliant implementations
of a vague and defective specification for the renegotiation, and we
currently see how painful it is to fix that.


No, I do not want to have the IETF ship a solution that is superficially
evaluated at best.  The fact that so many implementers completely
missed the TLS renegotiation vulnerability for over 14 years
worries me somewhat.  


A few implementors who have actually tried to implement both
proposed solutions for secure TLS renegotiation have shared
their results here.  So far their results were very similar.

If the original SSLv3 specification had described the
TLS renegotiation algorithm in full detail, then the vulnerability
would have been obvious from the beginning.

It's not very different for the interop problems with the extension
data in ClientHello and the protocol versions.  Instead of just
vaguely mentioning extensibility here or there, a specification
will need to spell out its expectations by example in order
for implementors to not create tomorrows interop problems today.


OpenSSL (in the days of 0.9.4) had nursing problems with the
TLSv1.0 protocol version, because the protocol version comparisons
were hardwired for major and minor version.
Today, OpenSSL is forwards compatible on the minor_version,
but the major_version is still hardwired.
Netscape 6 had problems sending correct protocol versions according
to the workarounds in OpenSSL, and Microsoft had a protocol version
problem in renegotiation handshakes.


To me, the effectively usable protocol version negotiation in TLS
(as inherited from SSLv3) for the installed base is a mess.
If they had used a set (like its done with the cipher_suites and
compression_methods), then the nursing problems would probably
be gone by now.  Another drawback from the exitisting version
negotiation is that implementations de-facto have to implement
all protocol versions, and given budget constraints of todays
world, TLSv1.0 is likely the protocol with the highest
return-of-investment.

Due to a complete lack of guidance about protocol version evolvement,
implementers made arbitrary choices which values they considered
valid and this is what resulted interop problems we currently face.
As a side-effect, the original "version rollback protection" no
longer works as expected for clients with re-connect fallbacks
and conservative clients.


> 
> >> 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.

The issue is more, that those environments where renegotiation was
offered to applications and got used, now have a vital dependency
on that functionality being available.  

And while _our_ own installed base has no such dependency on TLS
renegotiation, *I* do care for the installed base of others,
and would be willing to bear the effort and burden to ship
an update for the entire installed base, provided that the
operational risk such a backwards-incompatible change means
for an installed base of largely unknown usage scenarios
is designed to be sufficiently small, and the spec on which
this change is based is sufficiently clear as to not create
new interoperability problems.

There are probably less than 10% of the implementers of SSLv3
and TLS implementations participating the IETF.  So any spec
we come up with should be sufficiently clear and sufficiently
simple that implementors around the world can come up with
independent interoperable implementations when all what they
have is the RFC document that we publish.


While we can not fix all of the problems (like unexpected identity
changes) universally at the TLS level, we can fix the most serious
problems with a relatively modest change in a central location
of the software stack and with a much better prerequisites for
applying a consistent fix throughout the entire infrastructure
than any approach that all of the affected applications would
have to individually pursue.


-Martin