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
