Seeking feedback on default encryption algorithm for V4

[Cantor, Scott]

> -- As a FedOp I'm advocating v4 start with deprecation WARNING then change
> in future releases to ramp to GCM as default rather than full on in GCM default
> to mitigate interop breakage upon v4 install.

It can't because we could never change the running default out from under people because of the lack of support across such a wide range of systems. It just can't be justified as a breaking change. So there's again nothing to warn on here. Either we do it or we don't. I've factored in the need for additional logging to facilitate the change being useful, but it's not this kind of logging.
 
> -- not many have cared on this topic (until now? __ )

I don't think people care now, not significantly.

> -- Those who use AD as a backend for Shibboleth are seeing LDAPS Channel
> binding come but then get delayed because they too are suffering the same
> problem of trying to raise all the boats in the harbour to better security:

According to MS, somehow simple binds over TLS are not being affected. I don't understand that but that's what the docs say, so this is a no-op if that's the case. Very few people would still be doing plaintext nowadays. That said, I get the sense their docs may be wrong because if they see real fallout from this worth delaying it, it can't be as simple an issue as the docs claim.

> There's a lot of change about to happen or in flight and want to have a great
> outcome (read: not get crushed on support, have sites have easier upgrades,
> and still do the best thing for security posture holistically)

Arguably the situation next year will be worse because right now there are no SameSite implications for the IdP software to speak of, and MS is delaying their change, whatever effect it happens to have. So it seems to me that V4 would be a better time to do something than V5. I would already project that V5's a bad time to do it because of the big changes on the OIDC side coming. It will be a breaking change in a way that V4 isn't.

> One of these great outcomes is how to get people to latest v4 with least pain as
> well as not trigger a rebuild of federation operator tools overnight to publish
> algorithms for SPs.

I am not suggesting any federations can, or should, do that.

> I'm not sure this was thought of yet because if one is not operating a Fed, it's
> not felt thus easy to say  just rely on published algorithms in metadata.

I have never said that. That's largely a dead end for all the usual reasons. It's a thing you can do *locally* via filters or for local metadata to carve out the exceptions, but it's useless when it comes to metadata you get from others, I'm well aware. That's just not something people have the ability to know and document for their systems. And they have no incentive to because the encryption is of no interest to the SP, the IdP is the one that cares about it.

>  I'm not seeing uptake in the recommendations of upgrade in place despite the
> advice out there.

GCM is the least of the problems with doing that.

> The byproduct of this stability  are that sites only  upgrade when absolutely
> necessary and are further between versions and likely to be 'just install v4 and
> port configs over' rather than upgrade in place.

That's an argument to me to do this, because the more pain that causes, the less people will do it and the less of a support problem everybody has. Word does get around. You CANNOT do this. If we have to put warnings into the installer about it, I'm more than willing, though it is utterly beyond me how anybody could think that's the right way to upgrade. I can't think of any software that requires that, or even works if you do a good percentage of the time.

We also have the compromise option of simply prompting new installs for this question and asking them if they want the default to be GCM. I’m willing to do that (as I speak for Rod, who has to do the actual work).

-- Scott