Re: [lamps] Review draft-ietf-lamps-cms-mix-with-psk-00

Jim Schaad <ietf@augustcellars.com> Thu, 15 November 2018 12:44 UTC

Return-Path: <ietf@augustcellars.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 CEAA8126DBF for <spasm@ietfa.amsl.com>; Thu, 15 Nov 2018 04:44:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] 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 S49HkGWg8vk8 for <spasm@ietfa.amsl.com>; Thu, 15 Nov 2018 04:44:48 -0800 (PST)
Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B3BB1128D0C for <spasm@ietf.org>; Thu, 15 Nov 2018 04:44:47 -0800 (PST)
Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Thu, 15 Nov 2018 04:39:49 -0800
From: Jim Schaad <ietf@augustcellars.com>
To: 'Russ Housley' <housley@vigilsec.com>
CC: 'SPASM' <spasm@ietf.org>
References: <018d01d477fa$97522760$c5f67620$@augustcellars.com> <AE8CC8C9-20BA-4E38-BF11-E617A153500E@vigilsec.com>
In-Reply-To: <AE8CC8C9-20BA-4E38-BF11-E617A153500E@vigilsec.com>
Date: Thu, 15 Nov 2018 04:44:36 -0800
Message-ID: <005001d47ce0$f91553b0$eb3ffb10$@augustcellars.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQEOA98DAf8amIgef52BMEtUzAscOAIjRw5DpsyX6SA=
Content-Language: en-us
X-Originating-IP: [73.180.8.170]
Archived-At: <https://mailarchive.ietf.org/arch/msg/spasm/mcVjcCAIiQan7Xfp6zES-lSMY9Q>
Subject: Re: [lamps] Review draft-ietf-lamps-cms-mix-with-psk-00
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.29
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: Thu, 15 Nov 2018 12:44:51 -0000


> -----Original Message-----
> From: Russ Housley <housley@vigilsec.com>
> Sent: Thursday, November 15, 2018 3:24 AM
> To: Jim Schaad <ietf@augustcellars.com>
> Cc: SPASM <spasm@ietf.org>
> Subject: Re: Review draft-ietf-lamps-cms-mix-with-psk-00
> 
> Jim:
> 
> Thanks for the careful review.
> 
> > Abstract:  Needs to be re-worded " if existing syntax the does not
> > accommodated them."
> 
> I suggest:
> 
>    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 the new algorithms, if the existing syntax the
>    does not accommodate 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.

Yeah - no

s/if the existing syntax the does not/if the existing syntax does not/

> 
> > Section 1: Needs to be re-worded "if current syntax the does not
> > accommodated them."
> 
> I suggest:
> 
>    Once quantum-secure key management algorithms are available, the CMS
>    will be extended to support them, if the existing syntax the does not
>    already accommodate the new algorithms.

Ok

> 
> > Section 1: Needs to be re-worded: " by mixing with a strong PSK with
> > the output"
> 
> In suggest:
> 
>    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 existing key transport and
>    key agreement algorithms with a pre-shared key (PSK). ...

Ok

> 
> > Section 2 -  Which key? "generates the key"  Pushing something from
> > the next two sentences forward would be useful.  Not talking about
> > generating the ephemeral DH key.
> 
> I suggest:
> 
>    The CMS enveloped-data content type [RFC5652] and the CMS
>    authenticated-enveloped-data content type [RFC5083] support both key
>    transport and key agreement public-key algorithms to establish the
>    key used to encrypt the content.  In both cases, the sender randomly
>    generates the content-encryption key, and then all recipients obtain
>    that key.  All recipients use the sender-generated symmetric key for
>    decryption.

Ok

> 
> > Section 2 - you have not introduced the KDK yet and now I am creating
> one.
> > Perhaps a simple discussion on how what happens is that an additional
> > key wrap is inserted using ...
> 
> I suggest:
> 
>    This specification defines two quantum-resistant ways to establish a
>    symmetric key-derivation key.  In both cases, the PSK is mixed with
>    the key-derivation key to create a quantum-resistant key-encryption
>    key.  The PSK MUST be distributed to the sender and all of the
>    recipients by some out-of-band means that does not make it vulnerable
>    to the future invention of a large-scale quantum computer, and an
>    identifier MUST be assigned to the PSK.
> 
>    The content-encryption key or content-authenticated-encryption key is
>    quantum-resistant, and it is established using these steps:

Ok

> 
> > Section 2 - It would be nice to add a sentence where you say that you
> > are introducing two new management techniques to say that they are
> > agnostic towards the underlying key management technique.
> 
> I am not sure whether the above suggestion resolves this comment or not.

No it does not.  I was referring to the fact that there are no restrictions
being placed on the KT or KA algorithm.  Specifically that any currently
defined or future defined algorithm can be used with this process.

> 
> > Section 3 - I am wondering if it would make more sense to use the
> > KEKIdentifier structure instead of just having an octet string for the
> > PreSharedKeyIdentifier type?
> 
>       KEKIdentifier ::= SEQUENCE {
>         keyIdentifier OCTET STRING,
>         date GeneralizedTime OPTIONAL,
>         other OtherKeyAttribute OPTIONAL }
> 
> I think you are suggesting that the PreSharedKeyIdentifier would represent
a
> set of keys and that the date and other fields would be used to select
among
> the keys in the set.  I cannot see how that makes it easier to deploy.

It does not make it any easier to deploy here than it did in the case of
distributing a KEK key already.  I have the vaguest of feelings that this
specific set of properties was originally requested by the US military so
they had some type of infrastructure that was in place for this purpose.  It
may have been some type of KDF that was being run but I don't think that was
ever defined.  Such a thing may also be useful I this case as well.  However
I was looking more a consistency than having a way to do this type of
deployment.

> 
> > Section 4 - This is twice that I have read this and am unclear what we
> > are doing.  The sentence "private key and recipient's public key to
> > generate a pairwise key"  From this and from information in my mind I
> > am not completely clear that this is the DH pairwise key or something
else.
> 
> I suggest:
> 
>       originator is a CHOICE with three alternatives specifying the
>       sender's key agreement public key.  Implementations MUST support
>       all three alternatives for specifying the sender's public key.
>       The sender uses their own private key and the recipient's public
>       key to generate a pairwise symmetric secret value.  A key
>       derivation function (KDF) is used to mix the PSK and the pairwise
>       symmetric secret value to produce a key-encryption key.  The
>       OriginatorIdentifierOrKey type is described in Section 6.2.2 of
>       [RFC5652].

The ender uses their own private key, the recipient's public key and a KDF
to produce the key derivation key.
A second key KDF is then used to mix the PSK and the key derivation key to
produce the KEK.

How long is the key derivation key supposed to be?  In the case of key
transport that key can be of any size, although it should have a minimum
length (size of the CEK?), the maximum value can be up to the size of the
key minus the padding structure being used.

I don't believe that we currently have anything that says how long the key
derivation key is going to be.  Does this need to be parametrized or should
it be "fixed".  The size of the CEK is not a good answer as my code will not
have looked at the content encoding algorithm when processing this and thus
would not know the value.  The size of the key wrap algorithm might be
reasonable length to default to.

> 
> > Summary:  Is it your thought that I should be able to implement this
> > document as written?  A the moment I do not believe that this is
possible.
> > Do we need to define how the KDF function operates?
> 
> I needs to add text.  In short, I see the secret input the the KDF simply
being
> the concatenation of the PSK and the key-derivation key.  In addition, the
> context string should be either "KeyTransPSKRecipientInfo" or
> "KeyAgreePSKRecipientInfo".

I am not sure that I am seeing a reason to have the context string be
included here.   I don't have any feelings either way.

 I would not want to just concatenate the two secret values together without
some type of length/separation existing just due to paranoia. 

Jim


> 
> Russ