2023-02-15, 11:10:20 -0800, Jakub Kicinski wrote: > On Wed, 15 Feb 2023 18:29:50 +0100 Sabrina Dubroca wrote: > > > And how will we handle re-keying in offload? > > > > Sorry for the stupid question... do you mean that I need to solve that > > problem before this series can progress, or that the cover letter > > should summarize the state of the discussion? > > I maintain that 1.3 offload is much more important than rekeying. Sure, it'd be great if we had 1.3 offload (and it should also support rekeying, because you can't force the peer to not rekey). But I can't implement offload. > Offloads being available for 1.2 may be stalling adoption of 1.3 > (just a guess, I run across this article mentioning 1.2 being used > in Oracle cloud for instance: > https://blogs.oracle.com/cloudsecurity/post/how-oci-helps-you-protect-data-with-default-encryption > could be because MITM requirements, or maybe they have HW which > can only do 1.2? Dunno). > > But I'm willing to compromise, we just need a solid plan of how to > handle the inevitable. I'm worried that how this will pay out is: > - you don't care about offload and add rekey I think that's a bit unfair. Not having to deal with offload at all would make things easier for me, sure, but I'm open to the discussion, even if I don't have a good understanding of the offloading side. I'd just like to avoid holding this feature (arguably a bug fix) until the vendors finally decide that they care about 1.3, if possible. If not, so be it. I wasn't trying to force you to accept this series. Sorry if that's what it sounded like. I really wanted to understand what you were asking for, because your question wasn't clear to me. Now it makes sense. > - vendors don't care about rekey and add 1.3 > ... time passes ... > - both you and the vendors have moved on > - users run into issues, waste their time debugging and > eventually report the problem upstream > - it's on me to fix? > > :( Yeah, I see. If the rekey already exists in SW, I think it'll be a bit harder for them to just not care about it, but maybe I'm being optimistic. I'm not sure we can come up with the correct uAPI/rekey design without trying to implement rekey with offload and seeing how that blows up (and possibly in different ways with different devices). Picking up from where the discussion died off in the previous thread: On transmit, I think the software fallback for retransmits will be needed, whether we can keep two generations of keys on the device or just one. We could have 2 consecutive rekeys, without even worrying about a broken peer spamming key updates for both sides (or the local user's library doing that). If devices can juggle 3 generations of keys, then maybe we don't have to worry too much about software fallback, but we'll need to define an API to set the extra keys ahead of time and then advance to the next one. Will all devices support installing 2 or 3 keys? On receive, we also have the problem of more than one rekey arriving, so if we can't feed enough keys to the device in advance, we'll have to decrypt some records in software. The host will have to survive the burst of software decryption while we wait until the device config catches up. One option might be to do the key derivation in the kernel following section 7.2 of the RFC [1]. I don't know how happy crypto/security people would be with that. We'd have to introduce new crypto_info structs, and new cipher types (or a flag in the upper bits of the cipher type) to go with them. Then the kernel processes incoming key update messages on its own, and emits its own key update messages when its current key is expiring. On transmit we also need to inject a Finished message before the KeyUpdate [2]. That's bringing a lot of TLS logic in the kernel. At that point we might as well do the whole handshake... but I really hope it doesn't come to that. It's hard, but I don't think "let's just kill the connection" is a nice solution. It's definitely easier for the kernel. [1] https://www.rfc-editor.org/rfc/rfc8446#section-7.2 [2] https://www.rfc-editor.org/rfc/rfc8446#section-4.6.3 -- Sabrina
