Seeking feedback on default encryption algorithm for V4

Christopher Bongaarts cab at umn.edu
Mon Feb 10 10:50:48 EST 2020


On 2/7/2020 2:22 PM, Cantor, Scott (quoting Chris Phillips) wrote:
>> 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'd have to wonder if the set of SPs with published algorithm support in 
their metadata overlaps completely with the set of SPs that support 
AES-GCM...

> The simple fact is people don't value the encryption or they would have cared about this a long time ago.

These days I'd expect most/all transport of the encrypted 
response/assertion would be over TLS, which is enforcing its own 
encryption (likely GCM if you're using a relatively current browser).  
So the only real risk of exposure would be via browser shenanigans, and 
if the attacker controls the browser, it doesn't seem like it buys them 
much to crack open the authN response when they can use it as-is to 
access the SP directly.

So while I question the effective value of changing the default, I like 
the way you're proposing changing it.  New installations can use the new 
default, and work things out as they onboard SPs, while upgrades are 
left alone.  And deployer get a switch to flip the way they want either 
way, and can switch to the new default when it's convenient (or a clever 
new hack makes it necessary).

-- 
%%  Christopher A. Bongaarts   %%  cab at umn.edu          %%
%%  OIT - Identity Management  %%  http://umn.edu/~cab  %%
%%  University of Minnesota    %%  +1 (612) 625-1809    %%

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/dev/attachments/20200210/bac838f5/attachment.html>


More information about the dev mailing list