From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dave Watson Subject: Re: Security enhancement proposal for kernel TLS Date: Fri, 3 Aug 2018 08:46:32 -0700 Message-ID: <20180803154632.GA34510@macbook-pro-81.local.dhcp.thefacebook.com> References: <20180725155946.GA37315@davejwatson-mba.local> <20180730211611.GA48199@glawler-mbp.dhcp.thefacebook.com> <20180801204647.GA6180@davejwatson-mba.dhcp.thefacebook.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Cc: "netdev@vger.kernel.org" , Peter Doliwa , Boris Pismenny To: Vakul Garg Return-path: Received: from mx0b-00082601.pphosted.com ([67.231.153.30]:60404 "EHLO mx0b-00082601.pphosted.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727171AbeHCRmx (ORCPT ); Fri, 3 Aug 2018 13:42:53 -0400 Content-Disposition: inline In-Reply-To: Sender: netdev-owner@vger.kernel.org List-ID: On 08/02/18 05:23 PM, Vakul Garg wrote: > > 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. The setsockopt call struct takes the key, iv, salt, and seqno: struct tls12_crypto_info_aes_gcm_128 { struct tls_crypto_info info; unsigned char iv[TLS_CIPHER_AES_GCM_128_IV_SIZE]; unsigned char key[TLS_CIPHER_AES_GCM_128_KEY_SIZE]; unsigned char salt[TLS_CIPHER_AES_GCM_128_SALT_SIZE]; unsigned char rec_seq[TLS_CIPHER_AES_GCM_128_REC_SEQ_SIZE]; };