IETF Logo Mail Archive

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

Russ Housley <housley@vigilsec.com> Fri, 30 November 2018 20:31 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 41143130FE9 for <spasm@ietfa.amsl.com>; Fri, 30 Nov 2018 12:31:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 XiEZwBqVYFqe for <spasm@ietfa.amsl.com>; Fri, 30 Nov 2018 12:31:11 -0800 (PST)
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 458CE130FDC for <spasm@ietf.org>; Fri, 30 Nov 2018 12:31:11 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id ABD8D300AA4 for <spasm@ietf.org>; Fri, 30 Nov 2018 15:31:08 -0500 (EST)
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 h6XAU60TPmbX for <spasm@ietf.org>; Fri, 30 Nov 2018 15:31:07 -0500 (EST)
Received: from [192.168.1.161] (pool-71-178-45-35.washdc.fios.verizon.net [71.178.45.35]) by mail.smeinc.net (Postfix) with ESMTPSA id 5CE953005B6; Fri, 30 Nov 2018 15:31:07 -0500 (EST)
From: Russ Housley <housley@vigilsec.com>
Message-Id: <4FED6A22-08B5-47C3-9B9D-0971B5A8E480@vigilsec.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_A9A5DC90-C386-4B2C-94F0-EE5F459ABFBC"
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
Date: Fri, 30 Nov 2018 15:31:07 -0500
In-Reply-To: <051001d4881f$e7251d80$b56f5880$@augustcellars.com>
Cc: SPASM <spasm@ietf.org>
To: Jim Schaad <ietf@augustcellars.com>
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> <044a01d48748$acbd9e10$0638da30$@augustcellars.com> <EB3BA34B-F9B8-42BD-9C57-A3FF89B75B80@vigilsec.com> <046a01d48751$2684dfd0$738e9f70$@augustcellars.com> <E9467D3D-2FA2-4528-ADA8-89FCD7ABB566@vigilsec.com> <051001d4881f$e7251d80$b56f5880$@augustcellars.com>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/spasm/N6KLd3SugNs06chvg_lyieLdoFw>
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: Fri, 30 Nov 2018 20:31:13 -0000


> On Nov 29, 2018, at 3:12 PM, Jim Schaad <ietf@augustcellars.com> wrote:
> 
> While my position is the “more correct” position, I can understand why the library being used might influence your choice here.  In any event which one is being used needs to be stated especially if you are going to re-use the KEK algorithm at this point.

I agree, and that is why my original text follows that path.  However, I think we want to embrace the use of existing implementations.  I think this is especially true since this is a short-term solution, where the long term solution is to support the quantum-resistant key management algorithm that comes out of the NIST competition.

> Given that KEK1 is an ephemeral value that is known only to the sender and the specific recipient, I cannot come up to any way that a third party (potentially another mail recipient) can remove or insert the PSK KDF step.  This would be the major issue that I would have with re-using the same algorithm identifier in both KDF steps.

Right, KEK1 only gets used in the key derivation of KEK2, and it is only known to the originator and one recipient.

Russ

v2.23.0 | Report a Bug | By Email