[JIRA] (OSJ-355) ConcatKDF parameter requirements too restrictive in ECDH

[Stefan Santesson (Jira)]

Stefan Santesson ( https://shibboleth.atlassian.net/secure/ViewProfile.jspa?accountId=5e1f387fa531f30ca3849078 ) *commented* on OSJ-355 ( https://shibboleth.atlassian.net/browse/OSJ-355?atlOrigin=eyJpIjoiNjdiNGQ5NWRmZjU2NGE4M2E5NWRmY2MyNzg1OTM3MmUiLCJwIjoiaiJ9 )

Re: ConcatKDF parameter requirements too restrictive in ECDH ( https://shibboleth.atlassian.net/browse/OSJ-355?atlOrigin=eyJpIjoiNjdiNGQ5NWRmZjU2NGE4M2E5NWRmY2MyNzg1OTM3MmUiLCJwIjoiaiJ9 )

A relevant input to this discussion is the example provided by XML enc in section 5.6.2.1 (Diffie-Hellman Key Agreement with Explicit Key Derivation Functions)

In this example they specify: AlgorithmID="00" PartyUInfo="" PartyVInfo="">

<xenc:AgreementMethod Algorithm="http://www.w3.org/2009/xmlenc11#dh-es">
 <xenc11:KeyDerivationMethod Algorithm="http://www.w3.org/2009/xmlenc11#ConcatKDF">
   <xenc11:ConcatKDFParams AlgorithmID="00" PartyUInfo="" PartyVInfo=""> 
     <ds:DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/>
   </xenc11:ConcatKDFParams>
 </xenc11:KeyDerivationMethod>
 <xenc:OriginatorKeyInfo>
   <ds:X509Data>
     <ds:X509Certificate><!-- X.509 Certificate here --></ds:X509Certificate>
   </ds:X509Data>
 </xenc:OriginatorKeyInfo>
 <xenc:RecipientKeyInfo>
   <ds:X509Data>
     <ds:X509SKI></ds:X509SKI>
     <!-- hint for the recipient's private key -->
   </ds:X509Data>
 </xenc:RecipientKeyInfo>
</xenc:AgreementMethod>

This is clearly wrong and probably a bug in the specification, but I still think this is relevant to us as implementers, because it gives a hint about what we must expect others to send when applying “Postel’s principle”. Based on this we decided to allow ““ to be equivalent to “00” meaning “no data and no padding” adding an empty byte array to be concatenated as ConcatKDF input.

So if we set aside what is right and wrong, it makes sense to be less restrictive in absence of negative consequences or security threats. In this case I see no benefits from being restrictive and requiring explicit content.

( https://shibboleth.atlassian.net/browse/OSJ-355#add-comment?atlOrigin=eyJpIjoiNjdiNGQ5NWRmZjU2NGE4M2E5NWRmY2MyNzg1OTM3MmUiLCJwIjoiaiJ9 ) Add Comment ( https://shibboleth.atlassian.net/browse/OSJ-355#add-comment?atlOrigin=eyJpIjoiNjdiNGQ5NWRmZjU2NGE4M2E5NWRmY2MyNzg1OTM3MmUiLCJwIjoiaiJ9 )

Get Jira notifications on your phone! Download the Jira Cloud app for Android ( https://play.google.com/store/apps/details?id=com.atlassian.android.jira.core&referrer=utm_source%3DNotificationLink%26utm_medium%3DEmail ) or iOS ( https://itunes.apple.com/app/apple-store/id1006972087?pt=696495&ct=EmailNotificationLink&mt=8 ) This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100201- sha1:66eda1f )
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/commits/attachments/20220628/6981f368/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: jira-generated-image-static-comment-icon-5f4cb370-7b32-41d9-a15c-8d2de07d0a96
Type: image/png
Size: 1084 bytes
Desc: not available
URL: <http://shibboleth.net/pipermail/commits/attachments/20220628/6981f368/attachment-0003.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: jira-generated-image-avatar-7f4db63a-1235-4ac6-9d86-d4128bbafda9
Type: image/png
Size: 425 bytes
Desc: not available
URL: <http://shibboleth.net/pipermail/commits/attachments/20220628/6981f368/attachment-0004.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: jira-generated-image-static-footer-desktop-logo-43bd9358-568d-414b-a0af-5a6dd82f30b3
Type: image/png
Size: 10805 bytes
Desc: not available
URL: <http://shibboleth.net/pipermail/commits/attachments/20220628/6981f368/attachment-0005.png>