Re: [lamps] WG Last Call for draft-ietf-lamps-cms-mix-with-psk

"Hammell, Jonathan F" <Jonathan.Hammell@cyber.gc.ca> Mon, 27 May 2019 13:31 UTC

Return-Path: <Jonathan.Hammell@cyber.gc.ca>
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 B5B3312015F for <spasm@ietfa.amsl.com>; Mon, 27 May 2019 06:31:31 -0700 (PDT)
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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, 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 R2lVLVkv_8QS for <spasm@ietfa.amsl.com>; Mon, 27 May 2019 06:31:29 -0700 (PDT)
Received: from beechnut.cse-cst.gc.ca (beechnut.cse-cst.gc.ca [205.193.218.37]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7B27312001A for <spasm@ietf.org>; Mon, 27 May 2019 06:31:29 -0700 (PDT)
From: "Hammell, Jonathan F" <Jonathan.Hammell@cyber.gc.ca>
To: "'spasm@ietf.org'" <spasm@ietf.org>
Thread-Topic: Re: [lamps] WG Last Call for draft-ietf-lamps-cms-mix-with-psk
Thread-Index: AdUUjUhsTWU98srlTk2AlTzaw5oH1A==
Date: Mon, 27 May 2019 13:31:24 +0000
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-classification: UNCLASSIFIED
Content-Type: multipart/mixed; boundary="_002_ba3c46ac49d84bf892c04051f5fea3c5cybergcca_"
MIME-Version: 1.0
Message-Id: <20190527133129.7B27312001A@ietfa.amsl.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/spasm/_6d_4jp3sOprAnbU2fp_yp_-6-k>
Subject: Re: [lamps] WG Last Call for draft-ietf-lamps-cms-mix-with-psk
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: Mon, 27 May 2019 13:31:32 -0000

Classification: UNCLASSIFIED

Sorry for the late comment.  My colleagues and I did review the draft and we have no suggestions for text changes.  We also produced a ProVerif model (attached) in an attempt to verify some of the cryptographic properties.  Details are below.  Let me know if you have any questions or issues.

# Assumptions/limitations
The model is limited to the Key Agreement algorithm and is bounded with two hardwired originators and hardwired recipients. 
 
We assume the DH key exchange is broken using a quantum computer such that the recipient private keys are known at the outset. We have modeled this by revealing the recipient's DH private key on the channel.

All recipients have DH certificates signed by a trusted CA. These are shared with all at beginning of the protocol. 

In an effort to model configuration choices of key encryption and kdf algorithms, we included settings for using strong or weak algorithms (in the quantum perspective). The model allows the attacker to modify the settings to both the originator and the receivers' algorithm configuration to use quantum-vulnerable algorithms.

# Security queries
Our interpretation of the draft is that it is attempting to solve the problem of maintaining the confidentiality of an encrypted cek from an opponent with the ability to break the DH public keys with a quantum computer. Therefore our model is limited to proving confidentiality of the cek in the face of such an attacker.

The model contains two types of queries:

1. Sanity - Whenever a sender s sends an encrypted version of cek to an intended recipient r then recipient r receives the same cek from sender s .

2. Confidentiality-  An attacker cannot learn the cek during a protocol run unless the sender uses weak crypto (in the quantum perspective).

# Running the model
proverif -graph . Using_PSK_in_CMS_Keyagree.pv

ProVerif spits out a lot of info, but the important statements about the queries are prefixed by the string "RESULT".



---
Re: [lamps] WG Last Call for draft-ietf-lamps-cms-mix-with-psk
Russ Housley <housley@vigilsec.com> Fri, 10 May 2019 15:00 UTChttps://mailarchive.ietf.org/arch/browse/spasm/?q=mix-with-psk 
The only comment that I received is to add <CODE BEGINS> at the top of the ASN.1 module and <CODE ENDS> at the bottom of the ASN.1 module.  I will do that now.

Russ


> On May 10, 2019, at 10:52 AM, Tim Hollebeek <mailto:tim.hollebeek@digicert.com&gt; wrote:
> 
> It appears no one has any further comments on this document, and it is ready to proceed.
>  
> -Tim
>  
> From: Spasm <mailto:spasm-bounces@ietf.org <mailto:spasm-bounces@ietf.org>> On Behalf Of Tim Hollebeek
> Sent: Friday, April 19, 2019 10:45 AM
> To: SPASM <mailto:spasm@ietf.org <mailto:spasm@ietf.org>>
> Subject: [lamps] WG Last Call for draft-ietf-lamps-cms-mix-with-psk
>  
> This is the LAMPS WG Last Call for "Using Pre-Shared Key (PSK) in the Cryptographic Message Syntax (CMS)" <draft-ietf-lamps-cms-mix-with-psk>.  Please review the document and send your comments to the list by 6 May 2019.
>  
> The datatracker page for the document is https://datatracker.ietf.org/doc/draft-ietf-lamps-cms-mix-with-psk/ <https://datatracker.ietf.org/doc/draft-ietf-lamps-cms-mix-with-psk/%3E
>  
> Thanks,
>  
> Tim