Re: [TLS] simplistic renego protection

[Eric Rescorla <[e-mail]>]

At Mon, 16 Nov 2009 11:53:00 +0100 (MET),
Martin Rex wrote:
> 
> Joseph Salowey wrote:
> > > 
> > > I really like to hear convincing arguments why we need the 
> > > TLS extension in the renegotiation handshake, and why 
> > > changing the definition for the handshake message hash 
> > > instead is not a superior alternative.  In particular one 
> > > that will grow naturally into future TLS revisions.
> > 
> > [Joe] TLS Extensions is the standard way to extend the protocol.  Using
> > the ciphersuite field as a means to change the base protocol is a new
> > extension mechanism.  I don't think this is a particularly good thing
> > for TLS to grow into.  I don't see a reason to define a new extension
> > mechanism when we can achieve what is necessary using the existing
> > mechanism.   When TLS 1.2+x is defined in the future then it can address
> > the renegotiation problem as necessary and the version field will signal
> > the underlying changes.   
> 
> 
> You do not seem to understand the TLS renegotiation problem at all.
>
> We are NOT supposed to extend TLSv1.2, we are supposed to FIX
> all protocol versions of TLS out there SSLv3->TLSv1.2.

Perhaps you should consider that other people have a different view of
the problem than you do. In particular, I don't think there is 
anything like consensus that we need to fix SSLv3, a protocol
which was never controlled by IETF--and in fact wasn't even
published by it as informational.


> Requiring people to implement generic TLS extensions, something
> that was completely undefined even for TLSv1.0 and is still optional
> in TLSv1.2, 

Not that it matters, but his is incorrect. TLS 1.2 requires extension
processing. See S 7.4.1 of RFC 5246:

   Servers MUST NOT send this extension.  TLS servers MUST support
   receiving this extension.


> only to fix something that has nothing to do with
> TLS extensions and can be fixed much more easily without TLS extensions
> is a pretty bad idea and poor engineering.

You're entitled to your opinion, of course, but I'm unconvinced.



> Think about the lines of code for a client:

I don't agree with your analysis of code complexity, but even if
you were correct the implementation effort is in any case so
minimal compared to the size of the deployment problem
that it strikes me as largely irrelevant. Moreover, we already
have implementations of RI, so the marginal implementation
effort is even lower compared to doing something new.

-Ekr