Re: [TLS] Doing without renegotiation

Henrick Hellström <henrick@streamsec.se> Thu, 17 April 2014 05:44 UTC

Message-ID: <534F6A06.6090508@streamsec.se>
Date: Thu, 17 Apr 2014 07:43:34 +0200
From: Henrick Hellström <henrick@streamsec.se>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0
MIME-Version: 1.0
To: tls@ietf.org
References: <20140417035011.GA25499@localhost>
In-Reply-To: <20140417035011.GA25499@localhost>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/vdJEGPdx_wFpykyPiQpyA4dtfhY
Subject: Re: [TLS] Doing without renegotiation
Precedence: list
Reply-To: henrick@streamsec.se

On 2014-04-17 05:50, Nico Williams wrote:
> My proposals:
>
>   - For rekeying just introduce a CCS-like record whose purpose is to
>     indicate that the sender is changing to new keys on the send side.
>     The new keys are derived from the same master secret as the preceding
>     keys, in the same way, but with a counter appended to the "key
>     expansion" salt.
>
>     There's no need to synchronize, but DTLS requires retransmission of
>     such messages else when dropped the recipient will not be able to
>     decrypt any subsequent messages.

This might be an option if the purpose of the renegotiation is just to 
reduce the risk of state collisions in the bulk encryption cipher, but 
it is no replacement for renegotiation of DHE/ECDHE sessions in order to 
refresh the perfect forward secrecy.

[TLS] Doing without renegotiation Nico Williams
Re: [TLS] Doing without renegotiation Henrick Hellström
Re: [TLS] Doing without renegotiation Yoav Nir
Re: [TLS] Doing without renegotiation Nico Williams
Re: [TLS] Doing without renegotiation Nico Williams
Re: [TLS] Doing without renegotiation Watson Ladd
Re: [TLS] Doing without renegotiation Martin Thomson
Re: [TLS] Doing without renegotiation Martin Thomson