Re: [TLS] simplistic renego protection

[David-Sarah Hopwood <[e-mail]>]

Stefan Santesson wrote:
> On 09-11-21 8:00 PM, "David-Sarah Hopwood" <[e-mail]>
> wrote:
> 
>> That's an oversimplification.
>>
>> The attacker is able to add a prefix to the server's view of the session.
>> This changes the server's state from what it would have been on an
>> initial connection. How far the attacker's influence on the server's
>> state extends into that session, is dependent on the application protocol.
> 
> So we are saying the same thing.
> 
> As you say, it depends on the application. What I claim is that it is
> possible to design an application that use channel binding to keep itself
> safe from this attack. All it needs to do is to make sure that it's state is
> reset after completed channel binding.

That's not correct; it needs to know that the client's state is reset as
well (see below). But suppose for the sake of argument, that both the client
and server's state is reset when a renegotiation occurs. In that case,
channel binding is a red herring. Resetting the client and server states
prevents the attack regardless of channel binding. But then, why use
renegotiation (and unnecessarily risk interoperability problems) if you're
going to use it in a way that is completely equivalent to making a new
connection?

> The fact that it is possible to be safe despite this vulnerability is an
> argument that lenient servers should be supported in the solution.

Suppose that an unpatched client performs a renegotiation. The server
doesn't know whether this is an intended renegotiation or an attack; so,
it must reset its state, as though the client had made a new connection.
But with most application protocols, that won't work, because the client
hasn't reset its state.

It might work in some special cases, where the application protocol is
stateless between requests (like HTTP) and the renegotiation occurred
at a request boundary. But then, there is absolutely no advantage to
using renegotiation; it's unnecessary complexity.

One might argue: OK, renegotiation is unnecessary, but what if we want to
retain interoperability with clients that do it anyway (between stateless
requests, since that's the only case that would work)? However, in practice
clients don't renegotiate just for the fun of it; we need to consider how
renegotiation is actually used. I have not yet seen any plausible use case
for continuing to support renegotiation with unpatched clients, where it
wouldn't be simpler and more secure to do something else (given that you're
suggesting that we modify how the server uses the application protocol in
any case). For instance, when using renegotiation to prompt the client to
present a client cert, it's easier to have it make such requests on a
different port.

-- 
David-Sarah Hopwood  ⚥  http://davidsarah.livejournal.com