> > we have discussed this in the past on net...@vger.kernel.org but I > > just want to point out here again, that renewing the symmetric crypto > > keys is not supported in the kernel part (for the time being). > > > > So in case the application depends on renegotiation (TLS1.2, which is > > the only version supported right now by the kernel AFAIK) as well key > > updates in TLS1.3 won't work. > > It might be useful to be able to transfer the state in both directions, so > that > those things are possible.
Symmetrically to the setsockopt TLS_TX that provides keys, iv and record sequence number to the kernel there is getsockopt TLS_TX that retrieves the same parameters. Do you think that supporting renegotiation is a must to merge this kernel feature into OpenSSL? or is it possible to let users decide if they want to make the tradeoff? > > > Because this feature is not transparent yet, I think it definitely > > needs a switch for applications to control it. > > We will probably also at least need to have way to find out if a cipher is > supported by the kernel we're running on or not. Currently it is possible to call the setsockopt TLS_TX with some cipher. If it is not supported the operation will fail. -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
