Re: Setting TLS_RX and TLS_TX crypto info more than once?

[Jakub Kicinski <kuba@kernel.org>]

On Wed, 25 Jan 2023 11:24:18 +0100 Marcel Holtmann wrote:
> My bad, I kinda remembered they are from end of 2020. Anyway, following
> that thread, I see you fixed my problem already.
> 
> The encrypted handshake portion is actually simple since it defines
> really clear boundaries for the handshake traffic secret. The deployed
> servers are a bit optimistic since they send you an unencrypted
> ServerHello followed right away by the rest of the handshake messages
> fully encrypted. I was surprised I can MSG_PEEK at the TLS record
> header and then just read n bytes of just the ServerHello leaving
> everything else in the receive buffer to be automatically decrypted
> once I set the keys. This allows for just having the TLS handshake
> implemented in userspace.
> 
> It is a little bit unfortunate that with the support for TLS 1.3, the
> old tls12_ structures for providing the crypto info have been used. I
> would have argued for providing the traffic_secret into the kernel and
> then the kernel could have easily derived key+iv by itself. And with
> that it could have done the KeyUpdate itself as well.
> 
> The other problem is actually that userspace needs to know when we are
> close to the limits of AES-GCM encryptions or when the sequence number
> is about to wrap. We need to feed back the status of the rec_seq back
> to userspace (and with that also from the HW offload).
> 
> I would argue that it might have made sense not just specifying the
> starting req_seq, but also either an ending or some trigger when
> to tell userspace that it is a good time to re-key.

Could you say more about your use case?

What you're describing sound contrary to the common belief/design
direction of TLS which was to keep the kernel out of as much complexity
as possible, focus only on parts where we can add perf.