Re: [lamps] draft-housley-cms-mix-with-psk-03

Russ Housley <housley@vigilsec.com> Tue, 03 April 2018 19:55 UTC

Return-Path: <housley@vigilsec.com>
X-Original-To: spasm@ietfa.amsl.com
Delivered-To: spasm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC5761267BB for <spasm@ietfa.amsl.com>; Tue, 3 Apr 2018 12:55:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eIZCt2ImQcEY for <spasm@ietfa.amsl.com>; Tue, 3 Apr 2018 12:55:20 -0700 (PDT)
Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DE9B61241F8 for <spasm@ietf.org>; Tue, 3 Apr 2018 12:55:19 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id C71B9300670 for <spasm@ietf.org>; Tue, 3 Apr 2018 15:55:17 -0400 (EDT)
X-Virus-Scanned: amavisd-new at mail.smeinc.net
Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 02yk8vj4QV1m for <spasm@ietf.org>; Tue, 3 Apr 2018 15:55:16 -0400 (EDT)
Received: from a860b60074bd.home (pool-108-45-101-150.washdc.fios.verizon.net [108.45.101.150]) by mail.smeinc.net (Postfix) with ESMTPSA id D49E430044B; Tue, 3 Apr 2018 15:55:15 -0400 (EDT)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
From: Russ Housley <housley@vigilsec.com>
In-Reply-To: <998C7BFA-0C23-4CAF-A1E0-B442352E2C4D@isara.com>
Date: Tue, 03 Apr 2018 15:55:36 -0400
Cc: "spasm@ietf.org" <spasm@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <872C03F5-6B1B-4963-BFB2-6550245A675C@vigilsec.com>
References: <836CB2DA-9A82-4DEC-845A-15A7ED195C8A@vigilsec.com> <B4849071-AFEE-40FC-BDC7-D0DE290E775A@isara.com> <1A02FB20-9018-43ED-BE2B-BFC3CE82B168@vigilsec.com> <998C7BFA-0C23-4CAF-A1E0-B442352E2C4D@isara.com>
To: Daniel Van Geest <Daniel.VanGeest@isara.com>
X-Mailer: Apple Mail (2.3273)
Archived-At: <https://mailarchive.ietf.org/arch/msg/spasm/t1IrLuNKfI4T1qh2GN4uH1iF6Xo>
Subject: Re: [lamps] draft-housley-cms-mix-with-psk-03
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." <spasm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/spasm>, <mailto:spasm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/spasm/>
List-Post: <mailto:spasm@ietf.org>
List-Help: <mailto:spasm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/spasm>, <mailto:spasm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 03 Apr 2018 19:55:28 -0000

I am working on -04.  It will address these comments.


> I had some more thoughts on the draft, all from the Security Considerations section.
> 
> 1) "A large-scale quantum computer will effectively cut the security
>   provided by a symmetric key algorithm in half.  As a result, the PSK,
>   the key-derivation key, and the key-encryption key need at least 256
>   bits of entropy to provide 128 bits of security.  For this reason,
>   these symmetric keys SHOULD be at least 256 bits in length.”
> 
> Assuming the existence of a large-scale quantum computer which can break RSA/ECDH, the entropy of the key-derivation key is irrelevant since the key would be fully recoverable by a quantum computer. So, what’s really important is that the PSK contains 256 bits of entropy and the KDF is quantum resistant and outputs a key-encryption key with a length of at least 256 bits.

You are right.  I suggest:

   A large-scale quantum computer will essentially negate the security
   provided by the key transport algorithm or the key agreement
   algorithm, which means that the attacker with a large-scale quantum
   computer can discover the key-derivation key.  In addition a large-
   scale quantum computer effectively cuts the security provided by a
   symmetric key algorithm in half.  Therefore, the PSK needs at least
   256 bits of entropy to provide 128 bits of security.  To match that
   same level of security, the key derivation function needs to be
   quantum-resistant and produce a key-encryption key that is at least
   256 bits in length.  Similarly, the content-encryption key or
   content-authenticated-encryption key needs to be at least 256 bits in
   length.

> 2) This draft focuses on key transport and key agreement for the obvious reason that these are vulnerable to attack by a large-scale quantum computer, so maybe this suggestion is outside the scope of this draft.  For KEKRecipientInfo should you explicitly mention that this is already quantum resistant as long a quantum resistant key-encryption algorithm with key size of at least 256 bits is used?  Similarly that PasswordRecipientInfo is quantum-resistant as long as a quantum-resistant key-encryption algorithm with key size at least 256 bits is used and a quantum resistant KDF is used with a sufficiently large password (for some definition of sufficient). Or if no KDF is used, the key-encryption key from the external source has at least 256 bits of entropy.

Perhaps adding this to the end of the Introduction:

   Note that the CMS also supports key management techniques based on
   symmetric key-encryption keys and passwords, but they are not
   discussed in this document because they are already quantum
   resistant.  The symmetric key-encryption key technique is quantum
   resistant when used with an adequate key size.  The password
   technique is quantum resistant when used with a quantum-resistant key
   derivation function and a sufficiently large password.

> 3) This is hinted at in the introduction, but nowhere in the security considerations section do you state that the content-encryption key should be at least 256 bits long to be quantum resistant (as mentioned above, you do make this recommendation for the other keys in this draft).

This is addressed in the revised paragraph in 1).

> 4) "When using a key agreement algorithm, a key-encryption key is
>   produced to encrypt the content-encryption key or content-
>   authenticated-encryption key.”
> 
> In this draft, this is true not just for key agreement algorithms but for key transport algorithms as well.

I suggest:

   When using a PSK with a key transport or a key agreement algorithm, ...

> 5) "Implementers should not mix the quantum-resistant key management
>   algorithms with their non-quantum-resistant counterparts.  That is,
>   the same content should not be protected with KeyTransRecipientInfo
>   and KeyTransPSKRecipientInfo, and the same content should not be
>   protected with KeyAgreeRecipientInfo and KeyAgreePSKRecipientInfo.
>   Doing so would make the content vulnerable to the future invention of
>   a large-scale quantum computer.”
> 
> This is true not just for QR RecipientInfos with their non-QR counterparts, but for any QR RecipientInfo combined with any non-QR RecipientInfo, such as KeyTransPSKRecipientInfo with KeyAgreeRecipientInfo. So, I think this should be generalized to mixing QR and non-QR RecipientInfos.  I also wonder if this should be a SHOULD NOT rather than just a should not?

Yes, but I do not think we want to enumerate all four cases.  I suggest:

   Implementers SHOULD NOT mix quantum-resistant key management
   algorithms with their non-quantum-resistant counterparts.  For
   example, the same content should not be protected with
   KeyTransRecipientInfo and KeyTransPSKRecipientInfo.  Likewise, the
   same content should not be protected with KeyAgreeRecipientInfo and
   KeyAgreePSKRecipientInfo.  Doing so would make the content vulnerable
   to the future invention of a large-scale quantum computer.

> In the following paragraph talking about implementers sending the same content in different messages, I suppose you added this to prevent an implementer from getting around the previous paragraph by sending two messages without the user being aware?  This is fine, though I don’t think an implementer could/should practically prevent a user from being dumb and actively sending the same message twice.

In the CMS, EnvelopedData includes:

      RecipientInfos ::= SET SIZE (1..MAX) OF RecipientInfo

The first paragraph is saying do not mix QR and non-QR in this set.

The second paragraph is saying that you get the same consequence if separate messages are used to do the mixing.

Russ