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: <20230125105743.16d7d4c6@kernel.org>
Date:   Wed, 25 Jan 2023 10:57:43 -0800
From:   Jakub Kicinski <kuba@...nel.org>
To:     Apoorv Kothari <apoorvko@...zon.com>
Cc:     <sd@...asysnail.net>, <borisp@...dia.com>, <dueno@...hat.com>,
        <fkrenzel@...hat.com>, <gal@...dia.com>, <netdev@...r.kernel.org>,
        <simo@...hat.com>, <tariqt@...dia.com>
Subject: Re: [PATCH net-next 0/5] tls: implement key updates for TLS1.3

On Wed, 25 Jan 2023 10:47:20 -0800 Apoorv Kothari wrote:
> > We'll need to keep the old key around until we know all the records
> > using it have been fully received, right?  And that could be multiple
> > old keys, in case of a quick series of key updates.  
> 
> Why does the hardware implementation need to store old keys? Does the need
> for retransmitted data assume we are operating in TLS_HW_RECORD mode and
> the hardware is also implementing the TCP stack?

We're talking about the Tx direction, the packets are queued to the
lower layers of the stack unencrypted, and get encrypted by the NIC.
Until TCP gets acks for all the data awaiting offloaded crypto - we
must hold onto the keys.

Rx direction is much simpler indeed.

> The TLS RFC assumes that the underlying transport layer provides reliable
> and in-order deliver so storing previous keys and encrypting 'old' data
> would be quite divergent from normal TLS behavior. Is the TLS_HW_RECORD mode
> processing TLS records out of order? If the hardware offload is handling
> the TCP networking stack then I feel it should also handle the
> retransmission of lost data.

Ignore TLS_HW_RECORD, it's a ToE offload, the offload we care about
just offloads encryption.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ