netdev - Re: [PATCH net-next 0/5] tls: implement key updates for TLS1.3

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]

Date:   Wed, 25 Jan 2023 16:17:26 -0500
From:   Simo Sorce <simo@...hat.com>
To:     Jakub Kicinski <kuba@...nel.org>,
        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,
        tariqt@...dia.com
Subject: Re: [PATCH net-next 0/5] tls: implement key updates for TLS1.3

On Wed, 2023-01-25 at 10:57 -0800, Jakub Kicinski wrote:
> 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.

Is this because the NIC does not cache the already encrypted outgoing
packets?

If that is the case is it _guaranteed_ that the re-encrypted packets
are exactly identical to the previously sent ones?

If it is not guaranteed, are you blocking use of AES GCM and any other
block cipher that may have very bad failure modes in a situation like
this (in the case of AES GCM I am thinking of IV reuse) ?

> 
> 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.
> 

-- 
Simo Sorce
RHEL Crypto Team
Red Hat, Inc