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

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

Message-ID: <20230125102233.1848e960@kernel.org>
Date:   Wed, 25 Jan 2023 10:22:33 -0800
From:   Jakub Kicinski <kuba@...nel.org>
To:     Marcel Holtmann <marcel@...tmann.org>
Cc:     Sabrina Dubroca <sd@...asysnail.net>,
        Boris Pismenny <borisp@...dia.com>, netdev@...r.kernel.org
Subject: Re: Setting TLS_RX and TLS_TX crypto info more than once?

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.