[Ace] WGLC feedback on draft-ietf-ace-cwt-proof-of-possession-02

Roman Danyliw <rdd@cert.org> Wed, 23 May 2018 17:40 UTC

Return-Path: <rdd@cert.org>
X-Original-To: ace@ietfa.amsl.com
Delivered-To: ace@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E2BD12E88B for <ace@ietfa.amsl.com>; Wed, 23 May 2018 10:40:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level:
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cert.org
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 o8cXYEhtM9NW for <ace@ietfa.amsl.com>; Wed, 23 May 2018 10:40:40 -0700 (PDT)
Received: from veto.sei.cmu.edu (veto.sei.cmu.edu [147.72.252.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9927712E886 for <ace@ietf.org>; Wed, 23 May 2018 10:40:40 -0700 (PDT)
Received: from delp.sei.cmu.edu (delp.sei.cmu.edu [10.64.21.31]) by veto.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id w4NHeaHO023487 for <ace@ietf.org>; Wed, 23 May 2018 13:40:36 -0400
DKIM-Filter: OpenDKIM Filter v2.11.0 veto.sei.cmu.edu w4NHeaHO023487
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cert.org; s=yc2bmwvrj62m; t=1527097236; bh=12h77iNO21Kj/GSfiruLxCeoEg066SY7ndSX3br+YS8=; h=From:To:Subject:Date:From; b=Ul7+uCB8QTTnthMRgM01wSMVfi7ifLonGhfzd44KuAXF8pBFKQvFCTk67NERGa6pN 0sGhPSfTnpm4RJnoKMQ5ZUe4OXZx1FWeuoAgE5dhgvZ7tJCtzuLhV7+89qzCxpNMdO pdDUZUxRcPSXUGMnrqCAZtw1cr+I1IKBt6SeNO7c=
Received: from CASCADE.ad.sei.cmu.edu (cascade.ad.sei.cmu.edu [10.64.28.248]) by delp.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id w4NHeWUQ021988 for <ace@ietf.org>; Wed, 23 May 2018 13:40:32 -0400
Received: from MARATHON.ad.sei.cmu.edu ([10.64.28.250]) by CASCADE.ad.sei.cmu.edu ([10.64.28.248]) with mapi id 14.03.0399.000; Wed, 23 May 2018 13:40:31 -0400
From: Roman Danyliw <rdd@cert.org>
To: "ace@ietf.org" <ace@ietf.org>
Thread-Topic: WGLC feedback on draft-ietf-ace-cwt-proof-of-possession-02
Thread-Index: AdPyvMVXIklgjB6pTh+daQsL4hILIw==
Date: Wed, 23 May 2018 17:40:30 +0000
Message-ID: <359EC4B99E040048A7131E0F4E113AFC014C3CA77A@marathon>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.64.22.6]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/ace/YynE9aoqU9fTGaeipJC1QnLLQOs>
Subject: [Ace] WGLC feedback on draft-ietf-ace-cwt-proof-of-possession-02
X-BeenThere: ace@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" <ace.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ace>, <mailto:ace-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ace/>
List-Post: <mailto:ace@ietf.org>
List-Help: <mailto:ace-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ace>, <mailto:ace-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 23 May 2018 17:40:43 -0000

Hello!
(chair hat off)

I reviewed draft-ietf-ace-cwt-proof-of-possession-02 in WGLC and have the following feedback:

(1) (Editorial) Page 3, "The value of the 'cnf' claim is a CBOR map and the ...".  Isn't it more precise to say "The _representation_ of the 'cnf' claim is a CBOR map ..."?

(2) (Editorial) Page 3,  Why is the sentence "(In some applications, the subject identifier ..." in parenthesis?

(3) (Editorial) Page 4, Section 3.0, I read to the end of this section by which point there has been discussion of "sub" or "iss".  I was left wondering about how to interpret the case where both are present and none are.

(4) (Editorial) Page 4, Section 3.1, Per " At most one of the "COSE_Key" and    "Encrypted_COSE_Key" confirmation values defined below may be  present."  Defined below where specifically?  I recommend citing Figure 1 explicitly by s/below/in Figure 1/.

(5) Page 5, Typo in Section 3.2, s/diagonstic/diagnostic/

(6) (Editorial) Page 5, Section 2.3, Per "If the CWT is not encrypted, the symmetric key MUST be encrypted as described below."  Described where below?  I recommend citing Section 3.3 by s/below/In Section 3.3/

(7) Page 6, Section 3.3, The sentence "The COSE_Key could, for instance, be encrypted using a COSE_Encrypt0 representation using the AES-CCM-16-64-128 algorithm" seems out of place.  What is this text explaining relative to the examples?

(8) Page 7, Section 3.4, Per "The proof-of-possession key can also be identified by the use of a Key ID instead of communicating the actual key, provided the recipient is able to obtain the identified key using the Key ID."  How would the sender know whether the recipient can "obtain the key using the Key ID"?  Additionally, I would recommend adding language that states that this retrieval process is out of scope for this draft.

(9) (Editorial) Page 7, Section 3.4, Per "In this case, the issuer of a CWT declares that the presenter possesses a particular key and that the recipient can cryptographically  confirm proof of possession of the key by the presenter by including a "cnf" claim in the CWT whose value is a CBOR map with the CBOR map containing a "kid" member identifying the key."  I recommend s/is a CBOR map with the CBOR map/is a CBOR map/

(10) Page 8, Section 4.  RFC 2119 capitalizations seem more appropriate in these sentences:

(MUST) "Appropriate means *must* be used to ensure that unintended parties do not learn private key or symmetric key values."

(SHOULD) "Applications utilizing proof of possession *should* also utilize audience restriction, as described in Section 4.1.3 of [JWT], as it provides different protections."

(MUST) "Applications that require the proof-of-possession keys communicated with it to be understood and processed *must* ensure that the parts of this specification that they use are implemented."

(11) Page 8, Section 4. Per   "Applications utilizing proof of possession should also utilize audience restriction, as described in Section 4.1.3 of [JWT], as it provides different protections."  I recommend s/different/additional/

(12) (Editorial) Page 8, Section 4, Per 

   Applications utilizing proof of possession should also utilize
   audience restriction, as described in Section 4.1.3 of [JWT], as it
   provides different protections.  Proof of possession can be used by
   recipients to reject messages from unauthorized senders.  Audience
   restriction can be used by recipients to reject messages intended for
   different recipients.

The flow of this sentence is off for me.  Sentence #1 asserts the need for audience restrictions.  Sentence #3 describes the benefit of Sentence #1.  Sentence #2 interjects with something that seems unrelated to this need-benefit pairing.

(13) Page 8, Section 4, Per "Applications that require the proof-of-possession keys communicated with it to be understood and processed must ensure that the parts of this    specification that they use are implemented."  How is this being ensured?  What happens if the needed parts aren't specified?  Also, it seems like the "must" here should be "MUST".

(14) (Editorial)  Page 8, Section 4, Per "Replay can also be avoided if a sub-key is derived from a shared secret that is specific to the instance of the PoP demonstration."  PoP is spelled out everywhere else in this draft but here.  Yes, the acronym is defined, but for readability, I recommend against it using it and consistently spelling it out here too.

(15) Page 8, Section 4, Per "Special care has to be applied when carrying symmetric keys inside the CWT since those not only require integrity protection but also  confidentiality protection."  What is that care?

(16) Page 8, Section 4.  Per "Proof-of-possession signatures made with keys not meeting the application's trust criteria MUST NOT not be relied upon.", remove the double "not" by s/MUST NOT not/MUST NOT/.

Roman