Seeking feedback on default encryption algorithm for V4

Wed Feb 12 10:03:18 EST 2020

Hi..
While this reply is starting mid thread my perception the topic so far(Feb 12,2020) is:

In a glimpse of impact to Federation Operator impact on this change:
- Ian postulates that the entities that entities with published algorithm support likely overlaps strongly with GCM support  and if so, implies those that don't have a higher risk of not supporting it 
-- 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.

Scott has weighed in a few areas and I won't be able to hit them all -- some are: 
-- 'proper' upgrades from latest 3x to v4 should be safe (I agree)
-- not many have cared on this topic (until now? __ )
-- and that public dialog is key on this (I agree).

There are a few other things in flight as well in the community that uses Shib that are orthogonal but also play into the security and upgrade story:
-- samesite cookie changes that may (will?) force people to review their story on the Idp (a simple case of if it's not broke don't touch it but now it may break)
-- 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:
 See: https://portal.msrc.microsoft.com/en-us/security-guidance/advisory/ADV190023

All in all makes for a complex land for IdP operators and FedOps on what to recommend to do. It's also why I'm being more vocal on this topic right now. 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)

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'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. It's hard to deliver in practice.  It also hits schools who have 100's of SPs internally and few tools. Some schools have more entities internally than some countries and less tools to do it too.

While we say 'stay current', it's a dilemma:
 I'm not seeing uptake in the recommendations of upgrade in place despite the advice out there.
We see the community lagging in upgrades because the Shibboleth components are a victim of their success -- the stability and reliability are great. In light of this sites don't pay attention to their components because they are solid and run. It's a key aspect which many value Shibboleth components BTW.  
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. 
Sure, this is contrary to the advice offered by the Consortium but it is what it is and how people are operationally behaving.  To be fair, this is a big paintbrush I may be applying and YMMV. 

I hope sharing the concerns on this from both how sites upgrade an IdP to how Federation Operators can support the best security outcome  for the v4 configs and appreciate the send to the Shib Members list so that there are more eyes on the topic.

As always, feedback welcome..

Chris.

On 2020-02-07, 3:22 PM, "dev on behalf of Cantor, Scott" <dev-bounces at shibboleth.net on behalf of cantor.2 at osu.edu> wrote:

    > 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

    -- 
    To unsubscribe from this list send an email to dev-unsubscribe at shibboleth.net

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4340 bytes
Desc: not available
URL: <http://shibboleth.net/pipermail/dev/attachments/20200212/1fb97009/attachment.p7s>