netdev - 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-next>] [day] [month] [year] [list]

Message-ID: <DB7PR04MB4252B1EB964B3A65EEFFB74C8B720@DB7PR04MB4252.eurprd04.prod.outlook.com>
Date:   Tue, 5 Mar 2019 08:56:07 +0000
From:   Vakul Garg <vakul.garg@....com>
To:     "netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: kernel tls interface with user space modification proposal

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.

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).

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.
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