Seeking feedback on default encryption algorithm for V4

[Cantor, Scott]

> BTW I think this kind of question is also welcomed on the members list
> (apologies if it was sent, I didn't see it.) as I think the members are impacted by
> any outcome on this.

Generally speaking unless there's an issue that only impacts members, I wouldn't confine it to that list. We know who the members are, and we get a tremendously small amount of feedback on anything in general, so it's not difficult to factor that into the responses we get when necessary. If the issue becomes contentious, and we need to really formally debate it, I would raise the question there.

We prefer to operate in total transparency, and this is an open list, so this is where I feel we need to share the information. I also meant to send this several weeks ago, and did, and it never made the list. I didn't realize that until today.

> My bet is that those organizations are going to
> pay the highest price on a v4 upgrade.

They wouldn't pay any price for an upgrade because nothing will change unless they don't upgrade in the proper way.

> What I don't know and need guidance on is what happens in cases where the
> entity doesn't signal it's algorithms and if IdP v4 is set to 'use GCM for best
> security'. Will it just break the sign on flow or ???

The SP fails to decrypt with errors that will be dependent on the SP.

> How about using existing logstream in idp-warn.log and log  non GCM
> transactions with "WARN -- lower strength algorithm in use, recommend to
> <entityid> to have better as this will be deprecated in the future." message?

I don't know what that would accomplish, really. There isn't enough use of the algorithm metadata to be significant, is there? I would expect nothing but warnings, and there's no way to know what could be fixed and what couldn't.
 
I can see maybe adding some kind of warning machinery if we *did* change the default, so maybe warning when a non-GCM algorithm is selected *because* of metadata, which is a small set of cases. But it doesn't seem to accomplish much in the other direction. Maybe I'm missing a win there.

We could also look at this on the audit side. We don't currently audit algorithms, but that's certainly a possibility, so that makes it much more vaulable as a thing you can search and sort our data for with tools like Splunk, so you could find all the current (and very minimal) GCM traffic and know when you've made progress by hand switching systems over.

When we did the SHA2 switch, the only reason it wasn't total disaster is that everything generally supported it. This isn't the same kind of thing. This will cause pain, and it can't really not do that.

I think the fallback choice is really to punt it (likely forever) and just add a startup warning and explore some of these other enhancement ideas. And if people don't want to do the work to start testing everything they support one by one and switching by hand, they won't. Even I have not yet done it, though I plan to start this year.

That's a totally reasonable position, by the way. The simple fact is people don't value the encryption or they would have cared about this a long time ago.

-- Scott