Merge pull request #6 from emanjon/patch-1

Security considerations regarding short tags

draft-ietf-cose-countersign.xml

@@ -521,6 +521,11 @@ array to avoid confusion.
       </ul>
       <t>Analysis of the size of encrypted messages can provide information about the plaintext messages. This specification does not provide a uniform method for padding messages prior to encryption. An observer can distinguish between two different messages (for example, 'YES' and 'NO') based on the length for all of the content encryption algorithms that are defined in <xref target="I-D.ietf-cose-rfc8152bis-algs"/>.  This means that it is up to the applications to specify how content padding is to be done to prevent or discourage such analysis.  (For example, the text strings could be defined as 'YES' and 'NO '.)
       </t>
+
+      <t>When either COSE_Encrypt and COSE_Mac is used and more than two parties share the key, data origin authentication is not provided. Any party that knows the message-authentication key can compute a valid authentication tag; therefore, the contents could originate from any one of the parties that share the key.</t>
+
+      <t>Countersignatures of COSE_Encrypt and COSE_Mac with short authentication tags do not provide the security properties associated with the same algorithm used in COSE_Sign. To provide 128-bit security against collision attacks, the tag length MUST be at least 256-bits. A countersignature of a COSE_Mac with AES-MAC 256/128 provides at most 64 bits of integrity protection. Similarly, a countersignature of a COSE_Encrypt with AES-CCM-16-64-128 provides at most 32 bits bits of integrity protection.</t>
+
     </section>
 
     <section removeInRFC="true">