netdev - Re: kernel tls interface with user space modification proposal

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <4ff09a77-04c1-f32f-b8f2-f3f218ce502d@mellanox.com>
Date:   Thu, 21 Mar 2019 16:46:08 +0000
From:   Boris Pismenny <borisp@...lanox.com>
To:     Vakul Garg <vakul.garg@....com>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        Dave Watson <davejwatson@...com>,
        John Fastabend <john.fastabend@...il.com>,
        Daniel Borkmann <daniel@...earbox.net>,
        Aviad Yehezkel <aviadye@...lanox.com>
Subject: Re: kernel tls interface with user space modification proposal

Hi Vakul,

+TLS maintainers

I suggest you send this to TLS maintainers if you want to get more 
feedback, and it would be best to tag this as RFC.

On 3/5/2019 9:56 AM, Vakul Garg wrote:
> Hi
> 
> The present interface of kernel tls with user space has few shortcomings.
> 
> The biggest one is that when we need to add a ciphersuite in kernel tls, then we need to define new structures for passing cryptographic parameters required by record layer.
> And the user space ssl stack also has to be modified because it tries to use kernel tls only for a given set of ciphers implemented it it.
> 

As all TLS versions below 1.2 are being deprecated, and with TLS1.3 
supporting only 5 ciphersuites based on AES-GCM, AES-CCM and 
Chacha-Poly. I think that it is safe to go forward based on the existing 
model for these ciphers, while not supporting any other (older ciphers).

If we were to try and support all the available ciphers, then it might 
make sense to have a generic infrastructure for this.

> A better schema could be that if kernel tls support is compiled/enabled in user space SSL stack, it tries to use it for all record layer ciphers.
> If kernel tls does not support a given cipher, then setsockopt fails and SSL stack can fallback to non-ktls mode for the session and subsequent ones using same cipher type.
> > This would require passing the crypto material in a generic form 
which is same for all cipher types.
> 
> My proposal is that at the sestsockopt interface, instead of passing discrete keys/salt/IV etc of certain lengths (which are different for each cipher), we pass the cipher type and the full keyblock (128 bytes).
> Thereafter, kernel tls chops the keyblock into keys/iv/salt which are defined by the given cipher type.
> 
> (The keyblock is derived by SSL stack from master secret and then segmented in to keys/IV/salt).
> 

Does this work for TLS1.3?

> This would keep the interface between ktls and user space software independent of cipher types supported by kernel tls.
> 
> Further, it is redundant to pass same TLS version, cipher type info in both Rx and Tx direction.
>
> I propose that we define an additional setsockopt interface for passing crypto params in both directions.

Additional interfaces double the maintenance effort, and I'm not sure it 
is interesting to support any of the ciphers besides the once used by 
TLS1.3.

> This setsockopt() would be invoked by SSL stack after handshake is deemed completed to start record protocol offload in both directions.
> 
> struct tls_rec_prot_info {
>            unsigned short version;
>            unsigned short cipher_type;
>            unsigned char keyblock[128];
>            unsigned char tx_seq[8];
>            unsigned char rx_seq[8];
>    };
> 
> setsockopt(sock, SOL_TLS, TLS_INFO, &rec_prot_info, sizeof(rec_prot_info));
> 
> Kindly advise.
> 
> Regards
> 
> Vakul
>