[Cfrg] Review of draft-selander-ace-cose-ecdhe-12
"Stanislav V. Smyshlyaev" <smyshsv@gmail.com> Fri, 01 March 2019 20:29 UTC
Return-Path: <smyshsv@gmail.com>
X-Original-To: cfrg@ietfa.amsl.com
Delivered-To: cfrg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2286A130EBE for <cfrg@ietfa.amsl.com>; Fri, 1 Mar 2019 12:29:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 mWUJwO13WcyM for <cfrg@ietfa.amsl.com>; Fri, 1 Mar 2019 12:29:53 -0800 (PST)
Received: from mail-qk1-x735.google.com (mail-qk1-x735.google.com [IPv6:2607:f8b0:4864:20::735]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D2187130EB4 for <cfrg@irtf.org>; Fri, 1 Mar 2019 12:29:52 -0800 (PST)
Received: by mail-qk1-x735.google.com with SMTP id c2so14378998qkb.3 for <cfrg@irtf.org>; Fri, 01 Mar 2019 12:29:52 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=fIFwSxgK4LeiJKQGZ4eu3c2rfXg7E/5eAVezeyScW+M=; b=db6uNGQea2ZxAvjwBGgRcbq6plRvLpPjHSrGoLkSywWvYshu9FHAmhufhb7RIhdKB2 eyhWTLyZhhDG2zK0AgFFLRB1W8AUGLoza/70NdaLbcIFjJZNIUMBZaLNav6Vr6+pZAig lGJtP0XtFWSv4qqRDljCqilE6SQzUpUv97Zz3VGiyF4XISc8Us14rpjN5eIam6xnJPq4 j/qYvzHYg06Km8k3AUrcQE4zDBiqTEQj5QdjcDdOOv/e1GupDktiskb+CMoWKUpZQIuI ifT0HNocwE5ialIIbr9YzNufE8h810Zrx4uO4tdjpH/uu7htYy+efXUUCOQcqThOofUx O2Tw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=fIFwSxgK4LeiJKQGZ4eu3c2rfXg7E/5eAVezeyScW+M=; b=aOAeFNR7bMUOKBVV0vYuHn/TedNdKLasraHO4uPoELrnjn/7SZkzQrzlx2azHhGKzQ orBT9XzPDsQweya4TSlWuGs96aH6do+qs3UCFg4eOb4zWz5fKrncDhUEIOp78cbL9TJW MdkXBVVZ7m+6mSkzouavVd/ejVOyvjHIvffPsjwVd0R7SMYHR76R1As+bzayLD6Rz10k 6sdI6gsIdHYbKcDQrGPJhId9e+UastPJogEJWnADYGrOdcL9B4Aaz1PuE3y63mhO6MbI bE4HQCOQi3O8h+PBLqoZgR7ynuBh4sdiionTENuGSa3wmvSMdXrPFRXSGhvAQp9LgFSi bV8A==
X-Gm-Message-State: APjAAAXSzdJ7HHiXWUoDVnhU/L77FA8S95DNyBQjigqtEVhtx9/CwSkI MQIsbzrAPWVhR/h0auppQww3isiuqJ+X7eKJ1YRiZGDC
X-Google-Smtp-Source: APXvYqxyuudkK7dPWkVkrPvCW/K3vOdoaK758k8/DB3QYqwYaXcC0wePwROVfj433AKg61TY0OH8oHrJDAUCltdfhek=
X-Received: by 2002:a37:5786:: with SMTP id l128mr5277726qkb.263.1551472191317; Fri, 01 Mar 2019 12:29:51 -0800 (PST)
MIME-Version: 1.0
From: "Stanislav V. Smyshlyaev" <smyshsv@gmail.com>
Date: Fri, 01 Mar 2019 23:29:41 +0300
Message-ID: <CAMr0u6=V+wwaGA=08a5=XTerXJ6k=etzPbpMAf6YME8ERynEog@mail.gmail.com>
To: CFRG <cfrg@irtf.org>, John Mattsson <john.mattsson@ericsson.com>
Content-Type: multipart/alternative; boundary="000000000000d7ade305830e44e8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/cfrg/2OY2om1FjhNNBmUzwYJroHv7eWQ>
Subject: [Cfrg] Review of draft-selander-ace-cose-ecdhe-12
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Crypto Forum Research Group <cfrg.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/cfrg>, <mailto:cfrg-request@irtf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/cfrg/>
List-Post: <mailto:cfrg@irtf.org>
List-Help: <mailto:cfrg-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/cfrg>, <mailto:cfrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Fri, 01 Mar 2019 20:29:56 -0000
Dear colleagues, The Crypto Review Panel members were asked to provide two reviews of this document - sending the second one. Document: draft-selander-ace-cose-ecdhe-12 Reviewer: Stanislav Smyshlyaev Review Date: 2019-03-01 Summary: Minor revision needed EDHOC is an authenticated key exchange protocol intended for usage in constrained scenarios, based on deeply analyzed SIGMA-I protocol. A formal verification of (a slightly different version of) the EDHOC protocol was conducted in [1] using automatic protocol verifier ProVerif. The formal verification paper [1] contains not only the technique and the results of the verification, but also a number of recommendations (for the version -08 of the draft). Those recommendations mostly include concerns about unprotected (or, better to say, not fully protected) data that is sent in the protocol messages during mutual authentication and key exchange. According to the formal analysis conducted in [1], EDHOC provides the declared security properties. In general, additional security analysis of a protocol should be conducted (not only with automatic tools, but also with security proofs by reduction, with a survey of countermeasures against typical attacks on AKE protocols, etc.), but the reviewer believes that for EDHOC, being a particular case of SIGMA-I (with additional messages and with AEAD instead of MAC-then-Encrypt), it is not critical. While the choice of the ciphersuites seems to be acceptable, it will inevitably be a discussion point (e.g., should we include a GCM suite or even a suite with an internal re-keying mechanism as a countermeasure against side-channel attacks? should we include a suite with P224 as a lightweight alternative? etc.). The EDHOC protocol looks well-designed. Particularly, the reviewer would like to mention such solutions as CRED_x under signature, which is good to prevent DSKS-type attacks; a downgrade protection based on sending both a list of supported suites and a selected one with aad2 and aad3 messages being hashes from all previous messages (binding the communications together); KCI-attacks are inapplicable due to SIGMA-like ephemeral keys usage. The concerns of [1] (namely, section 2.3 of [1]) has been addressed. Application data in the second message (UAD_2) is no longer encrypted, which seems to be better for overall security. Indeed, while it weakens the security properties achieved for UAD_2, they become much clearer: the problem is that the encryption of UAD_2 in -08 took place with no guarantees of confidentiality before successfully finishing the protocol - and this issue is a very subtle one, potentially leading to incorrect security assumptions from the application side and vulnerabilities of the applications relying on confidentiality of that data. Therefore, -12 completely addresses the concern outlined by [1] for -08. Section 9.4 of the draft contains a brief outline of security considerations regarding UAD_1, UAD_2 and PAD_3, which reflects considerations given in [1]. It is important that in 4.4.3 there are explicit instructions to pass PAD_3 to an application only if (and after) verification step succeeds. The draft looks complete except for several minor concerns listed below. Minor concerns: A2.3 "where salt = 0x in the asymmetric case" - a specific value of salt here seems to be forgotten In 4.4.3 there are explicit instructions to pass PAD_3 to an application only after verification step succeeds – but it seems also reasonable to add corresponding recommendations (to finish the verification step before sending PAD_3 to the application) to 9.6 ("Implementation Considerations"). This doesn't seem to be crucial for the security, but I believe that it would be helpful to provide a comment in Section 3.3 about the reasons why PSK is used as a 'salt', not as a "secret" in HKDF. "KID does not need to uniquely identify the PSK ..." - is this possibility really needed for applications of the protocol? Absence of unique identification of the PSK possibly leaves some potential attack surface - the reviewer thinks that marking this as "NOT RECOMMENDED" will be better. Nits: 1.1: "Constrained IoT systems often deals" -> "Constrained IoT systems often deal" "Requirements on network formation time can in constrained environments" -> "Requirements on network formation time in constrained environments can " 3: "All EDHOC messages consists" -> "All EDHOC messages consist" 3.1: "EDHOC cipher suites consists" -> "EDHOC cipher suites consist" 3.3: "in the in the selected" -> "in the selected" 4.1: "ID_CRED_U and ID_CRED_V contains" -> "ID_CRED_U and ID_CRED_V contain" "Party U and Party V MAY use different type of credentials" -> "Party U and Party V MAY use different types of credentials" 4.3.2: "Note that protected and signature" -> "Note that 'protected' and 'signature'" 4.4.2: "Note that protected and signature" -> "Note that 'protected' and 'signature'" [1] https://link.springer.com/content/pdf/10.1007%2F978-3-030-04762-7_2.pdf
- [Cfrg] Review of draft-selander-ace-cose-ecdhe-12 Stanislav V. Smyshlyaev
- Re: [Cfrg] Review of draft-selander-ace-cose-ecdh… Russ Housley
- Re: [Cfrg] Review of draft-selander-ace-cose-ecdh… John Mattsson
- Re: [Cfrg] Review of draft-selander-ace-cose-ecdh… Stanislav V. Smyshlyaev