Re: [TLS] To extend or not to extend

[Martin Rex <[e-mail]>]

First of all, please keep in mind that server that do not
implement renegotiation have never been vulnerable in the first
place.

The only thing that those would have to add is the signaling on
the initial handshake.  They don't need to be able to exchange
finished messages and neither do they need to change their
finished message calculation.  Just recognizing the clients
signal and back-signaling "don't worry, I'm a nice server"
is all they ever need to patch.


Joseph Salowey wrote:
> 
> We need to close on this issue.  To summarize the RI proposal (the draft
> submitted last week) has the following properties in various situations
> 
> 
> A. The RI proposal works fine if both client and server are patched.  
> 
> B. The RI proposal works fine if the client is not patched and the
> server is (the server ends up disabling re-negotiation).  
> 
> C. The RI proposal works fine if the client is patched and the server is
> not, if the server is implemented correctly. 

That is an extremely huge if.

It is currently extremely unsafe to send an extension in the ClientHello,
therefore I'm extremely reluctant to add this to our client codebase,
because our apps do not have a reconnect fallback.

> 
> D. The RI proposal works fine if the client is patched and the server
> does not implement the SSL 3.0 and the TLS 1.x specs correctly (barf if
> they see an extension) and the client desires to implement an secure
> policy and disallows connections to non patched servers

This policy would mean that you brick the entire installed base,
including those that have never been vulnerable.

> 
> E. The RI proposal has an issue if the client is patched and the server
> does not implement the SSL 3.0 and the TLS 1.x specs correctly and the
> client as a lenient policy which allows connection to insecure servers.
> In this case the client would have to implement some fallback logic
> (reconnect without extensions) to deal with broken servers.  This logic
> is well-known, but it leaves a roll-back attack open.  This can be
> plugged by using the proposed ciphersuite signal only in the case where
> extensions cause a handshake or connection failure.  The fallback
> cipher-suite signaling for RI to prevent rollback extends TLS in an
> unexpected way, but this is limited only to the case where we have to
> deal with broken implementations.  
> 
> Situation E is one that we expect to get less common because we want all
> implementations to get patched and clients may start requiring the fix
> because this is the only way they can protect themselves.   
 
Situation E is the Killer for the TLS extension RI.

You can not seriously propose that people add reconnect fallbacks to all
their applications in order to be able to use TLS extension RI in their
clients during the transittion period and then after the transition period
ask the apps to dump that huge amounts of code they had to implement
because it is also a security problem.


With the current installed base, using TLS extension to wrap the fix
is a non-starter.


>
> The ciphersuite-changes-handshake proposal has similar properties except
> we expect that there are few broken servers that will barf on an unknown
> ciphersuite (Situation E).  This proposal extends TLS in a non-standard
> place by having the presence of a specific ciphersuite act as a side
> channel to change the behavior of the TLS handshake for all current
> versions of TLS.   I don't think this is something that we would want to
> promote in the future, the code to handle this would be "one-off" code.
> 
> From a functional point of view I don't see any difference between A) RI
> extension with option ciphersuite signal in the case of fallback for
> broken servers and B) ciphersuite-changes-handshake proposal.  

If we use signaling through special ciphersuite ID, then we do not
need the TLS extension anymore.

The real problem of the TLS extension RI is the presence of the
TLS extension on the initial handshake.  If you remove the TLS extension
RI from the ClientHello of the initial handshake, then the interop
problems will go away.  Only the superfluous waste of network bandwidth
on the renegotiation remains.


> 
> In TLS we have two standard ways of extending the functionality defined.
> One is extensions and one is the version number.

Excuse me, the Internet user do _NOT_ want us to make bold experiments
and play around with extensions.  They want us to fix a problem in the
protocol that has been there for a very long time.

If the SSL renegotiation had been designed correctly from the beginning,
noone would have come to the idea to invent and use a SSL or TLS extension
for this.  One would have added the finished messages of the previous
handshake into the handshake message hash of renegotiation handshake.


It is simple and straightforward to apply the fix to the protocol,
it creates significantly less interop problems with the installed base
and does not waste and network bandwidth.  And we want to only use the
secure renegotiation in the future, so there is absolutely no problem
in getting that "new code path" work correctly.  I assume that my
proposal is 50 lines of code at most. 


>
> Changing the version number is not really helpful at this point
> because it would require all systems to update to TLS 1.3 and
> its not clear that any of the situations above would change.

Huh?  What are you talking about?

My proposal works just fine with SSLv3 (0x03,0x00), noone will need
to upgrade anything.  But for TLSv1.3, we should no longer support
the old renegotiation.  This is why the extension, which will
stick around for eternity, looks pretty awful, continuing nuisance
and unnecessary waste of network bandwidth.


> Extensions are the way to extend the spec.
> Extensions are now part of the base specification and we want
> implementations to process extensions correctly even if they only
> support the RI fix.  

We do NOT NEED and extension for TLSv1.2.

We urgently need a _FIX_ for all deployed protocol versions, including
SSLv3, TLSv1.0 and TLSv1.1.

Please stop refering to the fix as an extension, it is not an extension,
and should not be described as one (and IMHO also not wrapped as one
on the network).

-Martin