Re: SSL renegotiation

Florian Weimer wrote:
> On 02/22/2015 02:05 PM, Andres Freund wrote:
>> On 2015-02-22 01:27:54 +0100, Emil Lenngren wrote:
>>> I honestly wonder why postgres uses renegotiation at all. The motivation
>>> that cryptoanalysis is easier as more data is sent seems quite
>>> far-fetched.
>>
>> I don't think so. There's a fair number of algorithms that can/could be
>> much easier be attached with lots of data available. Especially if you
>> can guess/know/control some of the data. Additionally renegotiating
>> regularly helps to constrain a possible key leagage to a certain amount
>> of time. With backend connections often being alive for weeks at a time
>> that's not a bad thing.
>
> Renegotiation will be removed from future TLS versions because it is
> considered unnecessary with modern ciphers:
>
> <https://github.com/tlswg/tls13-spec/issues/38>
>
> If ciphers require rekeying, that mechanism will be provided at the TLS
> layer in the future.
>
> I think you could remove renegotiation from PostgreSQL as long as you
> offer something better than RC4 in the TLS handshake.

I'd say it is best to wait if and how OpenSSL change their API when they
implement TLS 1.3.

I'd vote against removing renegotiation. At the very least, if the feature
should provide unnecessary and cumbersome with future versions of OpenSSL,
we should retain ssl_renegotiation_limit and change the default to 0.
It might still be of value with older versions.

If changing the encryption is so useless, whe did the TLS workgroup
decide to introduce rekeying as a substitute for renegotiation?

Yours,
Laurenz Albe