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