2026-05-12, 10:55:35 -0700, Rishikesh Jethwani wrote:

quoted

Not blaming you for NIC behavior, but... the NIC passes up as
"decrypted" records that have failed decryption (because it was using
the wrong (old) key), or passes as "encrypted" the incorrectly
decrypted data (that it has "decrypted" with the old key)?

Or this is only the first record(s) after the KeyUpdate message, if
they fall within the same packet, the whole packet was "decrypted"
with the old key but only the KeyUpdate itself (and maybe some more
records before it) decrypted correctly ; but subsequent packets get
passed as !decrypted and don't need this reencrypt dance?

(this is maybe more of a question for Tariq or the other @nvidia
folks)


I haven't reviewed the whole patch at this point, because of Paolo's
suggestion and this confusion with the RX rekey.

The traces show how both NICs behave during the key transition:

  Broadcom (NIC preserves decrypted flags):
  - decrypted=1: NIC fully decrypted these with the old key; one reencrypt
pass (retry=0) re-encrypts those frags back to ciphertext, then SW decrypts
with the new key.
  - encrypted=0, decrypted=0: boundary-straddling record; same single
reencrypt pass.
  - encrypted=1: NIC never touched these; SW decrypts directly with the new
key.

  Mellanox (NIC clears decrypted flags on auth failure):
  - encrypted=0, decrypted=0: NIC partially processed the record but
cleared all decrypted flags on auth failure. retry=0 reencrypts with the
wrong frag interpretation and gets EBADMSG; retry=1 toggles the flags and
succeeds.
  - encrypted=1: NIC reported these as untouched; SW decrypts directly.

  The retry path exists specifically for the Mellanox case: cleared flags
hide which frags the NIC actually touched, so the first pass may pick the
wrong interpretation and need to flip it.

Thanks for describing this.

I don't think the core TLS implementation should implement workarounds
for HW/drivers doing strange things. IMO this should instead be
stuffed into a driver CB, which would implement the necessary steps to
perform during a rekey.

The core can provide a helper, but I would move the whole
"reencrypt+maybe retry" logic to a CB.

-- 
Sabrina