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

From: Russ Housley <[email-masked]>
Date: Mon, 5 Mar 2018 15:23:09 -0500

I would like to make people on this mail list aware of this Internet-Draft.

Russ

= = = = = = = = = =

A new version of I-D, draft-housley-cms-mix-with-psk-03.txt
has been successfully submitted by Russell Housley and posted to the
IETF repository.

Name:		draft-housley-cms-mix-with-psk
Revision:	03
Title:		Using Pre-Shared Key (PSK) in the Cryptographic Message Syntax (CMS)
Document date:	2018-03-05
Group:		Individual Submission
Pages:		13
URL:            https://www.ietf.org/internet-drafts/draft-housley-cms-mix-with-psk-03.txt
Status:         https://datatracker.ietf.org/doc/draft-housley-cms-mix-with-psk/
Htmlized:       https://tools.ietf.org/html/draft-housley-cms-mix-with-psk-03
Htmlized:       https://datatracker.ietf.org/doc/html/draft-housley-cms-mix-with-psk-03
Diff:           https://www.ietf.org/rfcdiff?url2=draft-housley-cms-mix-with-psk-03

Abstract:
  The invention of a large-scale quantum computer would pose a serious
  challenge for the cryptographic algorithms that are widely deployed
  today.  The Cryptographic Message Syntax (CMS) supports key transport
  and key agreement algorithms that could be broken by the invention of
  such a quantum computer.  By storing communications that are
  protected with the CMS today, someone could decrypt them in the
  future when a large-scale quantum computer becomes available.  Once
  quantum-secure key management algorithms are available, the CMS will
  be extended to support them, if current syntax the does not
  accommodated them.  In the near-term, this document describes a
  mechanism to protect today's communication from the future invention
  of a large-scale quantum computer by mixing the output of key
  transport and key agreement algorithms with a pre-shared key.

---

From: Daniel Van Geest <[email-masked]>
Date: Fri, 9 Mar 2018 00:24:36 +0000

Hi Russ,

I have a few minor nits and one (still minor) comment.

Section 2:

(nit) s/then all recipient obtain/then all recipients obtain/
(nit) s/then key-derivation key is mixed/then the key-derivation key is mixed/ (x2)

Section 6:

“Compromise of the key transport private key or the agreement private key may result in the disclosure of all contents protected with that key. Compromise of the key-derivation key that is established with the key transport private key or the agreement private key may result in disclosure of the associated encrypted content.”

In this draft, disclosure of these keys would not result in the disclosure of the protected content unless the PSK was also disclosed.  I guess the “may” hedges those statements and makes them still technically true.  RFC 5652 says the same thing about the private keys, except in that case the disclosure of the keys would definitely allow disclosure of the protect content.  So maybe in this draft you want to qualify that if the private keys and the PSK are disclosed, the protected content may also be disclosed.

(nit) s/randomly generate key-derivation key/randomly generate key-derivation keys/
(nit?) s/as well as the content-encryption key/as well as the content-encryption keys/
(nit?) s/or content-authenticated-encryption key/or content-authenticated-encryption keys/
(nit) s/If the key-encryption algorithm is different that/If the key-encryption algorithm is different than/
(nit) s/Implementer should not/Implementers should not/
(nit) s/send the same content in different in separate messages/send the same content in different/

Thanks,
Dan

On 2018-03-05, 8:23 PM, "Spasm on behalf of Russ Housley" <[email-masked] on behalf of [email-masked]> wrote:

    Russ
    
    = = = = = = = = = =

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

---

From: Russ Housley <[email-masked]>
Date: Fri, 9 Mar 2018 12:27:33 -0500

Thanks for reading the document.  I will go through your comments and update the document.

You are correct.  I was probably being too subtle with the "may" in the security considerations.  I will come up with better wording.

Russ

> On Mar 8, 2018, at 7:24 PM, Daniel Van Geest <[email-masked]> wrote:
> 
> Hi Russ,
>

---

From: Daniel Van Geest <[email-masked]>
Date: Mon, 12 Mar 2018 22:57:06 +0000

Hi Russ,

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.

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.

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).

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.

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?

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.

Thanks,
Dan

On 2018-03-09, 5:27 PM, "Russ Housley" <[email-masked]> wrote:

    
    Russ

---

From: Tim Hollebeek <[email-masked]>
Date: Thu, 22 Mar 2018 10:57:45 +0000

It is unfortunate this dropped off the bottom of the schedule this week.

I think this is extremely important work, and well thought out
countermeasures
like this will give people the runway to wait until NIST and others get
post-quantum crypto figured out, and then all the related standards updated,
which will take some time.

I read the document and believe it is in pretty good shape, especially with 
the other comments that have been made.

-Tim

> -----Original Message-----
> From: Spasm [mailto:[email-masked]] On Behalf Of Russ Housley
> Sent: Monday, March 5, 2018 8:23 PM
> To: SPASM <[email-masked]>
> Subject: [lamps] draft-housley-cms-mix-with-psk-03
> 
> has been successfully submitted by Russell Housley and posted to the IETF
> repository.
> 
> Title:		Using Pre-Shared Key (PSK) in the Cryptographic
Message
> Syntax (CMS)
> URL:
https://www.ietf.org/internet-drafts/draft-housley-cms-mix-with-
> psk-03.txt
> Status:
https://datatracker.ietf.org/doc/draft-housley-cms-mix-with-psk/
> Htmlized:
https://tools.ietf.org/html/draft-housley-cms-mix-with-psk-03
> Htmlized:
https://datatracker.ietf.org/doc/html/draft-housley-cms-mix-
> with-psk-03
> Diff:
https://www.ietf.org/rfcdiff?url2=draft-housley-cms-mix-with-psk-03