IETF Logo Mail Archive

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

Jim Schaad <ietf@augustcellars.com> Wed, 28 November 2018 18:32 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 92D94128A6E for <spasm@ietfa.amsl.com>; Wed, 28 Nov 2018 10:32:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=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 DOBbdjgzoDjU for <spasm@ietfa.amsl.com>; Wed, 28 Nov 2018 10:32:19 -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 38461130E6E for <spasm@ietf.org>; Wed, 28 Nov 2018 10:32:19 -0800 (PST)
Received: from Jude (192.168.1.160) by mail2.augustcellars.com (192.168.1.201) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Wed, 28 Nov 2018 10:27:14 -0800
From: Jim Schaad <ietf@augustcellars.com>
To: 'Russ Housley' <housley@vigilsec.com>
CC: 'SPASM' <spasm@ietf.org>
References: <018d01d477fa$97522760$c5f67620$@augustcellars.com> <14A5DD8E-15E3-4009-961C-2E33011E0C44@vigilsec.com> <02fc01d48059$7bd665c0$73833140$@augustcellars.com> <840DC27B-3F3A-4D2D-9944-67007F88DAA7@vigilsec.com>
In-Reply-To: <840DC27B-3F3A-4D2D-9944-67007F88DAA7@vigilsec.com>
Date: Wed, 28 Nov 2018 10:32:08 -0800
Message-ID: <044a01d48748$acbd9e10$0638da30$@augustcellars.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_044B_01D48705.9E9AFA50"
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQEOA98DAf8amIgef52BMEtUzAscOAKFtv3nAjx3WgwA3KCLK6bFkq2Q
Content-Language: en-us
X-Originating-IP: [192.168.1.160]
Archived-At: <https://mailarchive.ietf.org/arch/msg/spasm/YJfPNLYN-qcpx1nUpbfyjKgmIao>
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: Wed, 28 Nov 2018 18:32:22 -0000

I don't know if this is more clear or not.

 

I am not sure that I agree that this demonstrates why KEK1 and KEK2 ought to
be the same length, to me it only shows why len(KEK1) >= len(KEK2) is a
required factor.  

 

I don't care enough to say you should change things however.

 

Jim

 

 

From: Russ Housley <housley@vigilsec.com> 
Sent: Tuesday, November 27, 2018 12:22 PM
To: Jim Schaad <ietf@augustcellars.com>
Cc: SPASM <spasm@ietf.org>
Subject: Re: Review draft-ietf-lamps-cms-mix-with-psk-00 

 

Jim:

 

* I am missing the discussion about what the KDK length is going to be for a

key agreement algorithm.   Am I just blind?

 

I have been playing with a toy implementation to make sure that I have
sorted out all of the issues, and I think that the key agreement needs some
fine tuning, not so much in what is actually going on, but more in the way
that it is explained.

 

I think this processing description will make more sense, and it will
encourage the intended code reuse...

 

   1. The content-encryption key is generated at random.

 

   2. The pairwise key-encryption key is established for each recipient.

        The recipient's public key and the sender's private key are used

        to produce a pairwise symmetric key-encryption key, called KEK1.

 

   3.  The key derivation function (KDF) is used to mix the pre-shared

         key (PSK) and KEK1, and the result is called KEK2.

 

   4. The KEK2 is used to encrypt the content-encryption key.

 

KEK1 is not actually used to encrypt anything, but it allows existing DH and
ECDH implementations to used without any modification.

 

I think this also makes it very clear why KEK1 and KEK2 ought to be the same
size.

 

Russ

v2.23.0 | Report a Bug | By Email