On 06/14/17 10:15 PM, Hannes Frederic Sowa wrote:
> one question for this patch set:
> What is the reason for not allowing key updates for the TX path? I was
> always loud pointing out the problems with TLSv1.2 renegotiation and
> TLSv1.3 key update alerts. This patch set uses encryption in a
> synchronous way directly in the socket layer and thus wouldn't suffer
> from problems regarding updates of the key. My hunch is that you leave
> this option open so you can later on introduce asynchronous crypto which
> might be used on hardware? It looks also be doable in case of MSG_MORE.
> Otherwise by allowing key updates to the data path I would not see any
> problems with key updates in TLS.
I don't currently have any reasons to not support renegotation, we
just don't currently use it, so I didn't add support for it. I don't
work on the hardware, but yes it looks like it would have to keep the
old keys around until everything sent using them has been acked.
> Anyway, this patch seems easy and maybe with key updates added later on
> doesn't seem to have any problems pointed out by me so far.
Indeed, it would be easy to flush any unencrypted data, and then
change the keys.