-----Original Message-----
From: Dave Watson [mailto:davejwatson@fb.com]
Sent: Thursday, August 2, 2018 2:17 AM
To: Vakul Garg <redacted>
Cc: netdev@vger.kernel.org; Peter Doliwa <redacted>; Boris
Pismenny [off-list ref]
Subject: Re: Security enhancement proposal for kernel TLS

On 07/31/18 10:45 AM, Vakul Garg wrote:

quoted

quoted

quoted

IIUC, with the upstream implementation of tls record layer in
kernel, the decryption of tls FINISHED message happens in kernel.
Therefore the keys are already being sent to kernel tls socket
before handshake is

completed.

This is incorrect.

Let us first reach a common ground on this.

 The kernel TLS implementation can decrypt only after setting the keys on

the socket.

quoted

The TLS message 'finished' (which is encrypted) is received after receiving

'CCS'

quoted

message. After the user space  TLS library receives CCS message, it
sets the keys on kernel TLS socket. Therefore, the next message in the
socket receive queue which is TLS finished gets decrypted in kernel only.

Please refer to following Boris's patch on openssl. The  commit log says:
" We choose to set this option at the earliest - just after CCS is complete".

I agree that Boris' patch does what you say it does - it sets keys immediately
after CCS instead of after FINISHED message.  I disagree that the kernel tls
implementation currently requires that specific ordering, nor do I think that it
should require that ordering.

The current kernel implementation assumes record sequence number to start from '0'.
If keys have to be set after FINISHED message, then record sequence number need to
be communicated from user space TLS stack to kernel. IIRC, sequence number is not 
part of the interface through which key is transferred.