> -----Original Message-----
> From: Dave Watson [mailto:davejwat...@fb.com]
> Sent: Thursday, August 2, 2018 2:17 AM
> To: Vakul Garg <vakul.g...@nxp.com>
> Cc: netdev@vger.kernel.org; Peter Doliwa <peter.dol...@nxp.com>; Boris
> Pismenny <bor...@mellanox.com>
> Subject: Re: Security enhancement proposal for kernel TLS
>
> On 07/31/18 10:45 AM, Vakul Garg wrote:
> > > > 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.
> > The TLS message 'finished' (which is encrypted) is received after receiving
> 'CCS'
> > 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.
