Subject: Re: [lamps] [EXTERNAL]Re: Mail regarding draft-ietf-lamps-cms-aes-gmac-alg-02

From: Mike Ounsworth <[email-masked]>
Date: Mon, 11 Jan 2021 18:20:52 +0000

Hi Russ,

(changing the subject line as this is now feedback on the recommended tag length in draft-ietf-lamps-cms-aes-gmac-alg-02)

Happy Monday! With a bit more reading, we're still not convinced 12 octets (96 bits) is the right recommendation for AES-GCM's authentication tag length in 2021. You reference RFC 5084 (published 2007) which does indeed recommend 12 octets in section 3.2. More recent IETF standards suggest using a 16 byte ICV, for example IPSec (specifically RFC 5282, published 2008) section 3.2 says:

   The AES GCM ICV consists solely of the AES GCM Authentication Tag.
   Implementations MUST support a full-length 16 octet ICV, MAY support
   8 or 12 octet ICVs, and MUST NOT support other ICV lengths.

As another reference, we're looking at NIST SP800-131Ar2 (published 2019). Section 10 (MACs) does not provide any guidance for GCM tag length. Section 3 (Digital Signatures) requires 112 bits of security for signatures. Since CRMF is using AES-GMAC, amongst other things, as a POP for obtaining certificates, we think it's reasonable to follow the digital signature strength requirements. 

Therefore we think for the GMAC tag length, a better RECOMMENDED value would be 16 octets (to match RFC 5282).  A value of 14 octets would also meet the digital signature recommendation in SP800-131Ar2 but may be a less common choice of GCM tag length. Is this a thing that CFRG could weigh in on?

---
Mike Ounsworth

-----Original Message-----
From: Mike Ounsworth 
Sent: January 9, 2021 12:57 PM
To: Russ Housley <[email-masked]>
Cc: LAMPS <[email-masked]>
Subject: RE: [EXTERNAL]Re: [lamps] Mail regarding draft-ietf-lamps-crmf-update-algs-02

Thanks Russ!

I think those changes fully address our concerns.

One response:

>> 5a. Which brings us to a question about draft-ietf-lamps-cms-aes-gmac-alg; where did the recommendation for a 12 byte GMAC tag come from? Is that supported by the referenced standards (NIST) or by an IRTF recommendation?

>This is for alignment with RFC 5084.  I was asked this so often that I added this information to the Implementation Considerations section of draft-ietf-lamps-cms-aes-gmac-alg.

Gotcha, thanks. Could you add that to your cms-aes-gmac draft just for the sake of an easy-to-follow citation chain? (I think 5084 is not currently in the references list)

---
Mike Ounsworth

-----Original Message-----
From: Spasm <[email-masked]> On Behalf Of Russ Housley
Sent: January 9, 2021 11:33 AM
To: Mike Ounsworth <[email-masked]>
Cc: LAMPS <[email-masked]>
Subject: [EXTERNAL]Re: [lamps] Mail regarding draft-ietf-lamps-crmf-update-algs-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.

Mike:

Thanks for the review and thoughtful comments.

> TL;DR: it would be great if this draft included a PBKDF2-based MAC (we suggest PBMAC1 defined in RFC 8018). We also have a few general nit-picks about the draft.

I think this is a good idea.  Before I add it, I would like to know whether others agree or disagree.  More below.

> PBKDF2-based MAC
> ---------------
> In draft-ietf-lamps-crmf-update-algs you are updating the underlying primitives inside 4211's id-PasswordBasedMac, but we note that the overall algorithm is still PBKDF1-like, so in effect your draft is encouraging use of PBKDF1-SHA256-MAC or PBKDF1-AES-GMAC. This came up for us while going through a government crypto audit and having a FIPS-compliant PBKDF2-MAC in CMP would have made the audit easier.
> 
> For backwards compatibility reasons you probably need to leave the PBKDF1-based 4211 id-PasswordBasedMac algorithm but with updated internal algs as you've done, but can you also offer as an alternative the PBKDF2-based RFC 8018 PBMAC1? I think we're asking that in the ASN.1:
> 
> ```
> PKMACValue ::= SEQUENCE {
> algId  AlgorithmIdentifier,
> -- algorithm value shall be PasswordBasedMac {1 2 840 113533 7 66 13}
> -- parameter value is PBMParameter
> ```
> the comment "-- algorithm value shall be PasswordBasedMac {1 2 840 113533 7 66 13}" also allow PBMAC1, as well as the corresponding parameter value type.
> 
> 
> The text in section 4.1 is already more tolerant, but explicitly mentioning (as a MAY) PBMAC1 as an alternative might make sense too:
> 
> ```
> algId identifies the algorithm used to compute the MAC value.  All 
> implementations MUST support id-PasswordBasedMAC.  The details on this 
> algorithm are presented in section 4.4.
> ```
> 
> We're working with Hendrik on draft-ietf-lamps-cmp-algorithms and it would be clean if we could reference PBMAC1 in your draft.

If the LAMPS WG agree with this approach, I would suggest an update to section 4.1:

OLD

      algId identifies the algorithm used to compute the MAC value.  All
      implementations MUST support id-PasswordBasedMAC.  The details on
      this algorithm are presented in section 4.4

NEW

      algId identifies the algorithm used to compute the MAC value.  All
      implementations MUST support id-PasswordBasedMAC as
      presented in section 4.4.  All implementations MAY also support
      PBMAC1 presented in Section 7.1 of [RFC8018].

> Other general comments
> ----------------------
> 1. Section 3.2 - The change is "All implementations MUST support SHA-256 [SHS].", which used to require SHA-1.  I don't know how this is typically done, but should your draft provide guidance on whether SHA-1 MAC is still safe to be used in backwards compatibility scenarios?

I'd rather not see anything about SHA-1.  The situation for Certificate Request Message Format (CRMF) is not like S/MIME.  By that I mean, one will not need to process a CRMF message many years later from an archive folder.  A CRMF message should not need to be validated after the requested certificate is issued.

> 2. Section 3.3 - "A lower iteration count can be used, if automated generation produces shared secrets with high entropy".  We find the wording slightly confusing; after several re-reads we think you mean "lower than 10,000", but someone doing a quick read might interpret "lower than 100". What is your intent here?

I suggest:  As part of that tradeoff, an iteration count smaller than 10,000 can be used when automated generation produces shared secrets with high entropy.

> 3. Section 3.4 - There is a typo in "When this The algorithm 
> identifier is used" ("The" should be removed)

Thanks.  I'll fix it.

> 4. Section 5 - "Therefore, the entropy of the password is crucial for 
> the security of password-based MAC function." should be "of the 
> password-based MAC function." ("the" missing)

Thanks.  I'll fix it.

> 5. You're copying the GMACParameters ASN.1 from your draft-ietf-lamps-cms-aes-gmac-alg, including the recommendation to use 12 bytes as default GMAC tag length. If at some point the recommendation changes to a larger value that would mean both documents need to be updated. Maybe better to leave the recommendation out of this draft and only reference the aes-gmac-alg draft? 

Okay.

> 5a. Which brings us to a question about draft-ietf-lamps-cms-aes-gmac-alg; where did the recommendation for a 12 byte GMAC tag come from? Is that supported by the referenced standards (NIST) or by an IRTF recommendation?

This is for alignment with RFC 5084.  I was asked this so often that I added this information to the Implementation Considerations section of draft-ietf-lamps-cms-aes-gmac-alg.

Russ

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

---

From: Russ Housley <[email-masked]>
Date: Tue, 12 Jan 2021 10:42:40 -0500

Mike:

This document is with the IESG.  IETF Last Call has not started yet, but I'll treat this as a Last Call comment when it does start.

My opinion is that we should not prevent anyone from using all of the Tag size choices.  CMS is used in many different contexts.  I would be supportive of requiring an implementation to support tags of 12 and 16 octets.

Russ

> On Jan 11, 2021, at 1:20 PM, Mike Ounsworth <[email-masked]> wrote:
> 
> Hi Russ,
> 
> nks.  I'll fix it.