Re: [TLS] simplistic renego protection

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

Stefan Santesson wrote:
> 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:
>>>>
>>>> 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.

The data sent on the channel is only split into "messages" at the
application protocol layer (if at all). At the upper interface of the
TLS layer, it is just a duplex byte stream, so the client may have sent a
partial application message. The server will then receive the rest of that
message after having reset its state, so it will be out of sync with the
client. This situation would break the application protocol regardless of
any attack.

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

But you do have to take action to ensure that the server resets its state,
and/or perform channel binding. Given that you have to take action, it's
not at all clear that these particular actions are simpler than the
alternatives; in they are definitely more complex than some alternatives.

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

Your suggestion was that channel binding could be done above the TLS layer.
As far as I can see, any channel binding that occurs above the TLS layer
cannot work to prevent the attack unless it is aware of the TLS
renegotiation boundaries. If you think that it can, please give more detail
of the protocol you're proposing; "successful channel binding" is not a
specific enough description.

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

Well, I've previously proposed a solution that supported lenient servers
(changing the Finished hashes unconditionally on a renegotiation, but using
extensions for signalling). That doesn't change my mind that a lenient
server policy is a bad idea.

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