safe renegotiation: confirming consensus

[Simon Josefsson]

Daniel Kahn Gillmor <dkg at fifthhorseman.net> writes:

> On 05/03/2010 10:28 AM, Simon Josefsson wrote:
>> Based on recent discussion, here is my perception of what I believe
>> would be the best to implement.  Note that this is not what is
>> implemented today, so some of the priority strings below have slightly
>> different meaning now.
>> 
>> Client behaviour:
>   [...]
>>   Clients will talk to servers that do not support the extension by
>>   default, but will refuse any rehandshake attempts against those
>>   servers.  This would cause operational problems: can we confirm that
>>   NSS and/or OpenSSL clients behave like this?  Otherwise we probably
>>   shouldn't enable it.
>
> NSS appears to be using this approach:
>
>  https://wiki.mozilla.org/Security:Renegotiation#Control

Thanks for the pointer!

> That said, i don't currently see that this approach confers much of a
> security advantage.
>
> The user is already vulnerable just by having made the initial
> connection (which appears to the client as a negotiation, but might
> appear to the server as a renegotiation if there was a prefix injection
> that already happened).

Right.

> Can anyone describe what additional threat we defend against by
> declining to renegotiate with vulnerable servers?

I can't think of any concrete threat.

I know that Mandos is using TLS backwards, i.e., the client is running a
TLS server and the server is responding as a TLS client.  Mandos
probably doesn't support renegotiation at all, but maybe there are other
designs like this and some that support renegotiation.  Still, I'm not
certain even these designs would be vulnerable.

> PS i can imagine that by declining re-negotiation we might alert the
> server operator (via bug reports or error logs) that they should upgrade
> their TLS toolkit, but that doesn't seem like a good tradeoff to me if
> it means that we force our users to lose functionality.

Thanks for your opinion.  I don't have a particularly strong opinion
here.  Maybe others can chime in too.

On the one side, I don't want to remove interoperability for security
reasons without a clearly described threat, and on the other side, I
want to disable as much as possible by default unless there is a reason
why it has to be enabled.

Given that we don't know of even one GnuTLS client applications that
implements renegotiation today (except gnutls-cli) -- I believe we have
searched applications if they contained the necessary code to perform
renegotiation earlier -- I would be surprised if anyone will notice if
we disable client renegotiation against servers without support for the
extension.

I think we could even disable renegotiation completely and people
wouldn't notice (except for mod_gnutls)...  it just isn't used by the
majority of GnuTLS applications.

/Simon