[JIRA] Commented: (SSPCPP-366) generated metadata should include cryptographic algorithms

[Ian Young (JIRA)]

    [ https://issues.shibboleth.net/jira/browse/SSPCPP-366?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14218#comment-14218 ] 

Ian Young commented on SSPCPP-366:
----------------------------------

On encryption, again I'm not sure I'd be thinking of tradeoffs but in terms of preferring the cheapest algorithm that provides "adequate" security (whatever that means, but presumably taking some margin for future medium term attack improvements into account).  The three MTI algorithms in XMLEnc and SAMLConf are 3DES (generally held to be 112 bit strength), AES-128-CBC and AES-256-CBC, and the IdP currently defaults to AES-128-CBC, presumably on the basis that 3DES is too weak, AES-128-CBC is strong enough and significantly cheaper than AES-256-CBC.

The real question is whether we think that AES-128-CBC is heading towards being not adequately secure (while still believing that AES-128-GCM is adequate for the foreseeable future) and that we'd therefore want to put it in the same category as SHA-1.  If so, we'd want to move it down a couple of spots to just above 3DES.

I don't know how to make that judgement, though.  There is definitely a cost to this, given that we don't expect GCM to be widely available and we'd therefore be pushing the majority of people to AES-256-CBC, which http://cr.yp.to/aes-speed/aesspeed-20080926.pdf estimates as about 40% more expensive on the basis that it does 14 rounds instead of 10.

> generated metadata should include cryptographic algorithms
> ----------------------------------------------------------
>
>                 Key: SSPCPP-366
>                 URL: https://issues.shibboleth.net/jira/browse/SSPCPP-366
>             Project: Shibboleth SP - C++
>          Issue Type: Improvement
>          Components: Other
>            Reporter: Ian Young
>            Assignee: Scott Cantor
>            Priority: Minor
>             Fix For: 2.5
>
>   Original Estimate: 1 day
>          Time Spent: 3 hours
>  Remaining Estimate: 5 hours
>
> The service provider should generate metadata describing the cryptographic algorithms supported, per the SAML v2.0 Metadata Profile for Algorithm Support Version 1.0.
> This should include alg:SigningMethod and alg:DigestMethod, as they are the ones we're most likely to need in the shorter term as MD5 and potentially SHA-1 go beyond their useful life.
> There's a note in the wiki that there are problems with OpenSAML-C 2.0 with respect to adding EncryptionMethod elements to KeyDescriptor elements. If this problem is isolated to IdP metadata, we should probably include EncryptionMethod elements as well. If the problem occurs even if EncryptionMethod is present in the metadata for another SP, there's an argument that the SP should not generate EncryptionMethod metadata until we really need it. I'd actually be interested in that clarification myself as at present UK federation checks preclude using EncryptionMethod on both SPs and IdPs, just to be on the safe side.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira