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: <3e9dc325734760fc563661066cd42b813991e7ce.camel@redhat.com>
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



Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ