Seeking feedback on default encryption algorithm for V4

[Chris Phillips]

I think getting the feedback is good -- thanks for asking!

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.
I also encourage this to be circulated on edugain-discuss at lists.geant.net to get more wider circulation than the Federation Operators list as they depend on the components and interop working.  The one that Ian posted to is a more private list and not easily circulated. Edugain-discuss is the best representation of operational people and those vested in interop (IMO __ ).

I'm a bit torn on this. Like you, I want Shib securely configured as the best outcome.  However as a FedOp I know not all SPs have their algorithm's published and I'm concerned about breakage and interop. 
 
My sense of what *could* break could  be >120 entities in eduGAIN's 2,634.  Given that Shibboleth software components are north of 90% or higher of these entities that's pretty impacting. This number also doesn't take into consideration schools who have 100's or 1000's of SPs they manage either. I know of at least 3 schools with over 500 internal services which eclipses the public ones in just 3 schools.  My bet is that those organizations are going to pay the highest price on a v4 upgrade.

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 ???

Rather than a toggle of on/off I suggest the Shib team keep on with the deprecation messaging approach for sunsetting things (features, syntax, and in this case, algorithms) and then sunset things in v4.x later.

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?

This accomplishes at least these things:
- assess the impact of the change
- highlight entities at risk.
- telegraphs there's a better way to secure things and that they will change in upcoming releases
- allows people to get on v4 faster without adding another reason to not do it

After initial deployment and enough usage this would give great intel on how to level up the community and who needs help.


Thoughts welcome as always and happy to help bring the message about this to others.

C

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

    We're finalizing the V4 defaults, and apart from a few obvious ones, the biggest remaining question is whether to flip the default encryption algorithms from AES-CBC over to AES-GCM for new installs. Upgrades would need to inherit the existing default, so we're not going to actually change the default internally, but the shipping configuration can be set differently, much as with the local storage change.
    
    I think it's now or never to do this, because there is no time at which there will be a majority of non-Shibboleth SPs that support GCM, so the situation is not going to be materially different later. It just is what it is: CBC is and has been broken for a decade and the only safe algorithm available is GCM. Virtually all but the most outdated Shibboleth SPs support it. I have no idea what else does and just take the default position that most nothing does. I'm sure a few do, but it's an easier planning assumption.
    
    So there's no illusion that it won't require effort by deployers to use it, and if people want to just not care and toggle the property off, they're free to do that.
    
    I just think we're obligated to ship secure configurations as best we can, and that is the only secure configuration we have.
    
    Admittedly, I'm also less impacted by the fallout because apart from member support, I really just don't have to care too much what trouble this causes. So I'm inclined to go along with the majority on it.
    
    -- 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/20200207/802318ad/attachment-0001.p7s>