Re: [TLS] Non-extension solutions (requirements)

[Martin Rex <[e-mail]>]

Nelson B Bolyard wrote:
> 
> On 2009-11-14 19:46 PDT, Marsh Ray wrote:
> > 
> > === R5. Not using an extension to implement the fix.
> > 
> > Currently there are no examples of extensions used in a critical role
> > between interoperable systems, even where there would be significant
> > gain (financial and otherwise) from their use (e.g., SNI). An urgent
> > security-critical bug fix is absolutely not the place for blazing new
> > trails.
> > 
> > It appears that somewhere between 20% and 40% of current SSL/TLS traffic
> > is between systems that either preferred not to (or could not) use TLS
> > 1.0 with extensions.
> 
> The same logic kept some browsers from disabling SSLv2 for years.

Flawed comparison.  SSLv2 known security problems.
SSLv3 does not.  SSL renegotiation has a problem, but across the board
from SSLv3 all the way to TLSv1.2.

> 
> There will ALWAYS be companies who procrastinate as long as possible on
> any software upgrades.  Let's not let them dictate how we fix TLS.
> Let's do the right thing here, even if it means forcing some to upgrade.

That would be extremely poor engineering.

We are perfectly able to provide a solution that can be applied to
all protocol versions out there, SSLv3, TLSv1.0, TLSv1.1, TLSv1.2.

Designing the fix so that adding it to SSLv3 is much harder than
for TLSv1.2 is irresponsible.


> 
> > === R6. The fix must work for SSLv3.
> 
> What does that mean?
> 
> - Does it mean devising a "fix" for SSLv3 that allows patched but still
> SSLv3-only clients to safely renegotiate with patched but still SSLv3-only
> servers?

It means that secure renegotiation should also be used when both
peers negotiation protocol version 0x03.0x00.  If the fix does not
do that, then the fix is not a fix, but another failure.


> 
> That's what they said about SSL2.
> 
> > Even software that does support newer versions of the protocol will
> > often fall back to SSLv3 at the first sign of trouble. Any fix which
> > does not address SSLv3 can simply be bypassed by the attacker
> 
> I think you're assuming that the browsers will decide that continued
> interoperability with the old vulnerable servers is more desirable that
> being able to claim that their browsers are invulnerable to this attack.
> I tend to assume the opposite.

This is ridiculous.

Browser vendors added the fallback renegotiation not because they
had too much time on their hands.  They wanted to use TLS extension SNI
or newer TLS versions and encountered severe interop issues.

The TLS WG can easily devise a fix for secure TLS renegotiation that
will work even during the fallback, and that can be hotfixed into the
entire installed base immediately with an extremely low probability
of breaking interoperability.

I also would try to get a client-side fix to our customers in 2-3 weeks
if it does NOT use extensions. (we don't support renegotiation on the
server, so adding the signaling to the initial Handshake is all I
have to do for the server).

If the TLS WG ships the TLS extension RI, then it will be several months
before I will be shipping anything for the client side, because I first
will need to think about solutions for the interop problems that will
arise and how to make the client-side behaviour configurable (which
requires changes to all applications).

An extension-less Client->Server Signaling on initial handshake is
something that I would risk shipping immediately without a configuration
option, taking care about interop problems when they're reported.


> 
> Now, that perception may be changing (may have already changed), a LOT.

Huh?  What are you refering to?
Those that moved to newer implementations and started to rely
on renegotiation in their Website structure are now the ones
who suffer the most.


> 
> > === R7. The fix must be easy to merge across existing code branches.
> 
> Sorry, that presumes reasonable development practices have been followed
> in the creation of those branches.  I think this is at best a highly
> desirable thing, not a requirement.

That is a pretty significant and realistic requirement.

In particular, if you have several different code lines providing
different protocol levels of TLS, then a fix where 90% of the code changes
is the same for all code lines is much better than one that needs to
be individually developed for every codeline.

Therefore devising the fix so that is requires minimal changes for
the oldest implementation affected by this protocol defect (SSLv3)
is the most reasonable approach to fixing that defect.


> 
> > === R9. Must interoperate perfectly with unpatched systems.
> 
> Again, what does that mean?
> Does it mean that a patched client connects without hesitation to an
> unpatched and vulnerable server, thereby falling victim to the attack?

It means that if the fix is designed in a fashion that it can be
used by clients at all protocol levels, even SSLv3 immediately with
an extremely low probability of breaking existing usage scenarios
(and that DOES INCLUDE servers that are still unpatched), then
we will see by far the quickest adoption of the update.


-Martin