Re: [TLS] simplistic renego protection

[Stefan Santesson <[e-mail]>]

I don't think this discussion is critical to selecting a solution, but one
more go in-line;


On 09-11-21 11:09 PM, "David-Sarah Hopwood" <[e-mail]>
wrote:

> 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).

Frankly, I can't see why it isn't enough for the server to reset it's state
regardless of the client. The server will simply regard the first message
after channel-binding as the first legitimate message from the client.

> 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.

The difference is that channel binding offers a safe point in time when you
can do this reset.

> 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?
> 

I agree, you have a point here. The point is more that you don't need to
take action to turn re-negotiation off if you are safe from the attack.

>> 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,

No. If the renegotiation occurs after a successful channel binding, the
server can be assured that this is not an attack.

So the server will reset it's state after channel binding but not on
following renegotiations.

> 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.

You might be absolutely right here. However, I think the burden of proof
should be reversed. Lenient servers should be supported unless we know for
sure that there is no legitimate use case. It should be the choice of the
local administrator to be strict, not the choice of the protocol designer.

IMO, if one solution can support of lenient servers, and the other proposal
can't then the one that can has merit.

/Stefan