Re: [TLS] simplistic renego protection

[Martin Rex <[e-mail]>]

Robert Dugal wrote:
> 
> I noticed you said this in the jabber log http://www.ietf.org/jabber/logs/tls/2009-11-12.txt 
> 
> [06:31:06] <EKR> It occurred to me the other day that there is
> a special case where hte server does not need to refuse renegotiation:
> when the client has sent no data yet.
> [06:31:20] <EKR> This would allow step-up/SGC to continue to work
> assuming we cared it)

Define "client has sent no data yet" ?

There is an implementors note in TLSv1.2, section about "Fragmentation"
that is as old as SSLv3 which requires that application can be
arbitrarily interleaved with a renegotiation handshake.

So the MitM can inject the data before forwarding the ChangeCipherSpec
message.  So whenever you implement something for this special case,
make sure that your TLS implementation checks "client has sent no data yet"
concurrently with verifying the finished message (unless it fails
reliably when receiving application data during the renegotiation
handshake).



> 
> Our products do support step-up/SGC and some customers may still be
> using it, or at least have servers with SGC certificates.
> Since there is no vulnerability is this special case, should
> some note be added to the draft? 

You mean like enumerating conceivable usage scenarios that
TLS extension RI is very likely to break?


Maybe a spec where that section is very small or empty
would be more appreciated by the community.


-Martin