Subject: Re: [lamps] AD Review: draft-ietf-lamps-cms-aes-gmac-alg-02

From: Roman Danyliw <[email-masked]>
Date: Fri, 5 Feb 2021 21:31:10 +0000

Hi!

> -----Original Message-----
> From: Spasm <[email-masked]> On Behalf Of Roman Danyliw
> Sent: Monday, January 25, 2021 9:10 PM
> To: LAMPS WG <[email-masked]>
> Subject: [lamps] AD Review: draft-ietf-lamps-cms-aes-gmac-alg-02
> 
> Hi!
> 
> I conducted an AD review draft-ietf-lamps-cms-aes-gmac-alg-02.  Thanks for
> the work to bring AES-GMAC to CMS.  Here is my feedback:
> 
> ** Questions about the recommendation in Section 3.1 for a 12 octet tag has
> come up a few times [1][2][3].  Thanks for adding the text in -02 to explain the
> origin as being from RFC5084 per [1]. If we decide to go that way, [2] makes a
> good suggestion to also add it to the comments.  [3] acknowledges the
> alignment with RFC5084 but speculates whether 13-year old guidance since
> applies. Like [3] I couldn't find any relevant NIST or RFCs to meaningfully cite.
> In addition to RFC5282, there is also RFC4543 which also recommend 16-bytes
> for the nonce.  However, I'm sensitive to those requirements potentially being
> protocol specific and CMS has a wider set of applications.  As an aside, this
> variability in application should be explicitly stated.
> 
> Is the thinking with [4] to make support for 12 and 16 octets a MUST, with the
> 12 there for parity with RFC5084 and the 16 because we think that's the right
> balance in 2021?
> 
> [1] https://mailarchive.ietf.org/arch/msg/spasm/KrmkF6kkbg8-
> pU4MpjgpTVmxzik/
> [2] https://mailarchive.ietf.org/arch/msg/spasm/T9UhA9T9j85o6VYjT-
> 9D2JnTEic/
> [3]
> https://mailarchive.ietf.org/arch/msg/spasm/7qqXzNFuA1YDFnfHw8oL9OVK_D
> c/
> [4] https://mailarchive.ietf.org/arch/msg/spasm/g1-
> 09MkwebIO3kI0T2sY5nBF2JM/

Answering myself ...

There has been a various off-list multi-party discussions and further search on the tag length topic.  To summarize for later reference, beyond following the previously discussed RFCs, there don't appear to be better academic pointers on attacks or outside SDO guidance to motivate the choice of 12 or 16 octets beyond what we have.  Therefore, let's keep the RECOMMENDED 12 octets when generically referencing CMS which keeps symmetry with RFC5084.  When we get into specific "application domains" (e.g., CRMF), we should consider this case by case.  draft-ietf-lamps-crmf-update-algs  can take a more conservative approach of 16 octets -- which is the current text as of -03.

[snipping all of the other AD review feedback]

Thanks for addressing it in -03.

Regards,
Roman

---

From: Mike Ounsworth <[email-masked]>
Date: Fri, 5 Feb 2021 22:02:14 +0000

Thanks Roman (and I assume Russ).

Sounds like the right resolution to me!

---
Mike Ounsworth

-----Original Message-----
From: Spasm <[email-masked]> On Behalf Of Roman Danyliw
Sent: February 5, 2021 3:31 PM
To: LAMPS WG <[email-masked]>
Subject: [EXTERNAL] Re: [lamps] AD Review: draft-ietf-lamps-cms-aes-gmac-alg-02

WARNING: This email originated outside of Entrust.
DO NOT CLICK links or attachments unless you trust the sender and know the content is safe.

______________________________________________________________________
Hi!

> I conducted an AD review draft-ietf-lamps-cms-aes-gmac-alg-02.  Thanks 
> for the work to bring AES-GMAC to CMS.  Here is my feedback:
> 
> ** Questions about the recommendation in Section 3.1 for a 12 octet 
> tag has come up a few times [1][2][3].  Thanks for adding the text in 
> -02 to explain the origin as being from RFC5084 per [1]. If we decide 
> to go that way, [2] makes a good suggestion to also add it to the 
> comments.  [3] acknowledges the alignment with RFC5084 but speculates 
> whether 13-year old guidance since applies. Like [3] I couldn't find any relevant NIST or RFCs to meaningfully cite.
> In addition to RFC5282, there is also RFC4543 which also recommend 
> 16-bytes for the nonce.  However, I'm sensitive to those requirements 
> potentially being protocol specific and CMS has a wider set of 
> applications.  As an aside, this variability in application should be explicitly stated.
> 
> 12 there for parity with RFC5084 and the 16 because we think that's 
> the right balance in 2021?
> 
> [1] 
> https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/msg/spas
> m/KrmkF6kkbg8-__;!!FJ-Y8qCqXTj2!Peh119Sbv_x8E5HgR2x6pfe6O9hZBlK-trJr9y
> QY51jUrw7fFcNRLvXScvR5LyrLbn3vBrA7wA$
> pU4MpjgpTVmxzik/
> [2] 
> https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/msg/spas
> m/T9UhA9T9j85o6VYjT-__;!!FJ-Y8qCqXTj2!Peh119Sbv_x8E5HgR2x6pfe6O9hZBlK-
> trJr9yQY51jUrw7fFcNRLvXScvR5LyrLbn0Lg3E3hw$
> 9D2JnTEic/
> [3]
> https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/msg/spas
> m/7qqXzNFuA1YDFnfHw8oL9OVK_D__;!!FJ-Y8qCqXTj2!Peh119Sbv_x8E5HgR2x6pfe6
> O9hZBlK-trJr9yQY51jUrw7fFcNRLvXScvR5LyrLbn3c2ur6DA$
> c/
> [4] 
> https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/msg/spas
> m/g1-__;!!FJ-Y8qCqXTj2!Peh119Sbv_x8E5HgR2x6pfe6O9hZBlK-trJr9yQY51jUrw7
> fFcNRLvXScvR5LyrLbn3X0lVqrA$

Answering myself ...

Regards,
Roman

_______________________________________________
Spasm mailing list
[email-masked]
https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/spasm__;!!FJ-Y8qCqXTj2!Peh119Sbv_x8E5HgR2x6pfe6O9hZBlK-trJr9yQY51jUrw7fFcNRLvXScvR5LyrLbn0ODNIKXA$