Re: [PATCH v2 0/5] wifi: add opt-in FIPS exception for iwlwifi

[Jose Ignacio Tornos Martinez <jtornosm@redhat.com>]

Hi Johannes,

> I don't _think_ it does that. It does behave a bit differently for MFP,
> but that's wrt. management frames.

Good to know. I will re-test with just MFP re-enabled and no data
keys to hardware, adding more debug logging to understand where
data gets stuck. Something else must have been wrong in my v1 test.

> Fundamentally, in this case the driver (even mac80211) shouldn't install
> (data) keys to hardware.

Ok

> I'd need to sit down and (re-)derive that, but I don't recall it being
> particularly tricky - just boils down to the various dependencies
> between features.

Ok, I can assume there are no other dependencies to start with.

> Presumably that would mean IGTK/BIGTK can be offloaded and remain
> working, but TK/GTK can't be known to the firmware since it's not FIPS
> certified.

Ok, I will take this approach for v3: IGTK/BIGTK offloaded to
firmware, PTK/GTK software-only.

> I mean, you _could_ push this further and keep almost all features: you
> still give PTK/GTK to firmware but don't use the offload mechanisms for
> data frames; though presumably then you'd not consider the result "good
> enough" since then a non-certified component (the firmware/hardware)
> holds the keys...?

Ok, for our customers having the keys in a non-certified component
would not be acceptable. The simpler approach is better for this case.

> I have no opinion on that, I guess the crypto folks should chime in
> about that. Having something very obvious makes sense to me, vs. having
> it at wifi or even driver level.

Then I will keep the boot parameter approach and make sure to Cc the
crypto maintainers for their input.

I will work on the feature dependencies myself and come back with
a cleaner v3. Thanks for the guidance, very helpful.

Best regards
Jose Ignacio