Subject: [lamps] Magnus Westerlund's No Objection on draft-ietf-lamps-cms-aes-gmac-alg-03: (with COMMENT)

From: Magnus Westerlund via Datatracker <[email-masked]>
Date: Thu, 25 Feb 2021 07:11:52 -0800

Magnus Westerlund has entered the following ballot position for
draft-ietf-lamps-cms-aes-gmac-alg-03: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-lamps-cms-aes-gmac-alg/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Should there be any comments in the security consideration section about the
security implications of using 96-bit truncated tags?

I know that shorter tags have significant vulnerabilities against forgery
attempts where successful forgery can be detected. John Mattsson and I wrote a
paper identifying why shorter tags would be very bad in SRTP in 2015.
https://eprint.iacr.org/2015/477.pdf

I guess the possibility to figure out if CMS forgery attempts are successful
depends on what the CMS is used for.

---

From: Roman Danyliw <[email-masked]>
Date: Thu, 25 Feb 2021 16:38:35 +0000

Hi!

> -----Original Message-----
> From: Spasm <[email-masked]> On Behalf Of Magnus Westerlund via
> Datatracker
> Sent: Thursday, February 25, 2021 10:12 AM
> To: The IESG <[email-masked]>
> Cc: [email-masked]; [email-masked];
> [email-masked]; [email-masked]
> Subject: [lamps] Magnus Westerlund's No Objection on draft-ietf-lamps-cms-
> aes-gmac-alg-03: (with COMMENT)
> 
> When responding, please keep the subject line intact and reply to all email
> addresses included in the To and CC lines. (Feel free to cut this introductory
> paragraph, however.)
> 
> 

>From the IESG discussion, a helpful statement to add in the Security Considerations would be to say something to the effect of "application developer using this algorithm (in CMS) will need to evaluate whether the tag length is appropriate for the desired security of their use case."

Regards,
Roman

> attempts where successful forgery can be detected. John Mattsson and I wrote
> a paper identifying why shorter tags would be very bad in SRTP in 2015.

> 
> 
> _______________________________________________
> Spasm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/spasm

---

From: Russ Housley <[email-masked]>
Date: Thu, 25 Feb 2021 13:19:26 -0500

Would this address your concern?

OLD:

   Within the scope of any content-authentication key, the AES-GMAC
   nonce value MUST be unique.  Use of a nonce value more than once
   allows an attacker to generate valid AES-GMAC authentication codes
   for arbitrary messages, resulting in the loss of authentication as
   described in Appendix A of [GCM].

NEW:

   Within the scope of any content-authentication key, the AES-GMAC
   nonce value MUST be unique.  Use of a nonce value more than once
   allows an attacker to generate valid AES-GMAC authentication codes
   for arbitrary messages, resulting in the loss of authentication as
   described in Appendix A of [GCM].

   Within the scope of any content-authentication key, the
   authentication tag length (MACLength) MUST be fixed.

   When IV lengths other than 96 bits are used, the GHASH function
   is used to process the provided IV, which introduces a potential
   of IV collisions.  However, IV collisions are not a concern with
   CMS AuthenticatedData because as a fresh content-authentication
   key is usually generated for each message.

   The probability of a successful forgery is close to 2^(−t),
   where t is the number of bits in the authentication tag length
   (MACLength*8).  This nearly ideal authentication protection is
   achieved for CMS AuthenticatedData when as a fresh
   content-authentication key is generated for each message.
   However, the strength of GMAC degrades slightly as a function
   of the length of the message being authenticated [F2005][MV2005].
   Implementations SHOULD use 16-octet authentication tags for
   messages over 2^64 octets.
   
REFERENCES:

   [F2005] Ferguson, N., "Authentication weaknesses in GCM", Comments
           to the NIST Modes of Operation process. 2005.

https://csrc.nist.gov/csrc/media/projects/block-cipher-techniques/documents/bcm/comments/cwc-gcm/ferguson2.pdf

   [MV2005] McGrew, D., and J. Viega, "GCM Update", Comments to the
            NIST Modes of Operation process. 2005.

https://csrc.nist.gov/CSRC/media/Projects/Block-Cipher-Techniques/documents/BCM/Comments/CWC-GCM/gcm-update.pdf

Russ

> On Feb 25, 2021, at 11:38 AM, Roman Danyliw <[email-masked]> wrote:
> 
> Hi!
>

---

From: Magnus Westerlund <[email-masked]>
Date: Fri, 26 Feb 2021 08:47:01 +0000

Thanks,

From my perspective this looks really good. It answers the questions I had when
reading the document regarding security properties, and also points to a very
important aspect about using a new key for each CMS messages which avoids the
weakness in the paper I linked to in my comment for truncated tags. 

Cheers

Magnus

> > > email
> > > From the IESG discussion, a helpful statement to add in the Security
> > > Considerations would be to say something to the effect of "application
> > > developer using this algorithm (in CMS) will need to evaluate whether the
> > > tag length is appropriate for the desired security of their use case."
> > 
> > Regards,
> > Roman
> >