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

Daniel Van Geest <Daniel.VanGeest@isara.com> Fri, 09 March 2018 00:24 UTC

Return-Path: <Daniel.VanGeest@isara.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 60470124B18 for <spasm@ietfa.amsl.com>; Thu, 8 Mar 2018 16:24:40 -0800 (PST)
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 TfXbvWmmhYq9 for <spasm@ietfa.amsl.com>; Thu, 8 Mar 2018 16:24:38 -0800 (PST)
Received: from esa1.isaracorp.com (esa1.isaracorp.com [207.107.152.166]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 66184120727 for <spasm@ietf.org>; Thu, 8 Mar 2018 16:24:38 -0800 (PST)
Received: from 172-1-110-12.lightspeed.sntcca.sbcglobal.net (HELO cas.isaracorp.com) ([172.1.110.12]) by ip1.isaracorp.com with ESMTP; 09 Mar 2018 00:31:18 +0000
Received: from mb.isaracorp.com (2001:470:b1cb:1500:9056:5d62:46d0:fe1f) by mb.isaracorp.com (2001:470:b1cb:1500:9056:5d62:46d0:fe1f) with Microsoft SMTP Server (TLS) id 15.0.1044.25; Thu, 8 Mar 2018 19:24:36 -0500
Received: from mb.isaracorp.com ([fe80::9056:5d62:46d0:fe1f]) by mb.isaracorp.com ([fe80::9056:5d62:46d0:fe1f%12]) with mapi id 15.00.1044.021; Thu, 8 Mar 2018 19:24:36 -0500
From: Daniel Van Geest <Daniel.VanGeest@isara.com>
To: Russ Housley <housley@vigilsec.com>, SPASM <spasm@ietf.org>
Thread-Topic: [lamps] draft-housley-cms-mix-with-psk-03
Thread-Index: AQHTtL/VYSnZFqn2DUqDOvC/89dF56PHZC6A
Date: Fri, 9 Mar 2018 00:24:36 +0000
Message-ID: <B4849071-AFEE-40FC-BDC7-D0DE290E775A@isara.com>
References: <836CB2DA-9A82-4DEC-845A-15A7ED195C8A@vigilsec.com>
In-Reply-To: <836CB2DA-9A82-4DEC-845A-15A7ED195C8A@vigilsec.com>
Accept-Language: en-CA, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.5.17.45]
Content-Type: text/plain; charset="utf-8"
Content-ID: <582F9CEC81E68C429DF795727B5DE46A@isaracorp.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/spasm/yfbM19fbYYXfKCRRU85vYScp2jA>
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: Fri, 09 Mar 2018 00:24:40 -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" <spasm-bounces@ietf.org on behalf of housley@vigilsec.com> wrote:

    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.
    
    _______________________________________________
    Spasm mailing list
    Spasm@ietf.org
    https://www.ietf.org/mailman/listinfo/spasm