Re: [TLS] To extend or not to extend

["Joseph Salowey (jsalowey)" <[e-mail]>]

> > 
> > 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.
> 
[Joe] Eric pointed out that if you are going to have a lenient policy
that you don't need to send the extension in the initial handshake.  

> >
> > 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.
> 
[Joe] OK, right.  SO it seems that situation E with RI is not as bad as
I stated.