Re: [TLS] simplistic renego protection

[Martin Rex <[e-mail]>]

David-Sarah Hopwood wrote:
> 
> Martin Rex wrote:
> > Do you realize how much implementation and testing is involved when
> > shipping the fix as a TLS extension.
> 
> Yes. Are you suggesting that a fix that uses some other ad hoc signalling
> mechanism does not need to undergo thorough interoperability testing?

For the ad-hoc signaling a patched browser will be perfectly
sufficient for testing.

For TLS extensions, you will need to develop yourself a whole test client
that is able to generate a certain number of test-scenarios.

See here: http://www.ietf.org/mail-archive/web/tls/current/msg04351.html


> 
> > If someone with an old server, who doesn't implement renegotiation and
> > TLS extensions wants to add this patch, he will need to add the entire
> > TLS extensions handling in a generic fashion and require a significantly
> > larger interop testing scenario to make sure that it acutally works:
> 
> If a server doesn't implement renegotiation, then it is already as secure
> as it can be with respect to this attack. The server only needs to be
> patched so that strict clients will recognize it as patched.
> 
> To achieve that, the server clearly must signal something in a message
> that it sends. If that is not done using an extension, then it must be
> done using another mechanism such as recognizing a magic ciphersuite and
> stuffing its response in some covert channel (which I cannot believe we
> are even seriously discussing, frankly).

Huh?

If the client is signaling that it is updated and will understand
whatever the spec says the server should indicate in return,
then this is just fine.  The spec could even go as far as completely
redesigning the ServerHello, completely different from TLS.

We could also invent a new handshake message to be sent just after
ServerHello, if people prefer this instead of re-purposing
an existing element of ServerHello in a well-defined situation.
(it would need to be a handshake message, alerts are invisible
to the handshake message hash and finished mac).


> 
> Remember, complicated kludges such as fallback to accomodate broken server
> implementations are only needed, if they are needed at all, on the client
> side. Implementing extensions on the server side is completely trivial.
> Many server implementors have already done that work, whereas *no* server
> implementors have done the work to support any newly invented signalling
> mechanism.

I have seriously thought about how to implement my ideas in OpenSSL,
and there your assumption about TLS extensions being easier do _not_ apply.


> 
> > You're going to waste network bandwith eternally in a completely
> > useless fashion.
> 
> The bandwidth usage is completely insignificant, even for highly constrained
> environments. If I've calculated correctly, the size of the extension is
> 5 bytes in each direction in the most common, non-renegotiating case
> (17 or 29 bytes when renegotiating), and it adds no round-trips. Compare
> that to X.509 certificate sizes, which are typically at least 1 KiB each.

It is still pure waste, any way you look at it.

-Martin