Secdir last call review of draft-ietf-ace-cwt-proof-of-possession-08
Yoav Nir via Datatracker <noreply@ietf.org> Sun, 06 October 2019 18:51 UTC
Return-Path: <noreply@ietf.org>
X-Original-To: ietf@ietf.org
Delivered-To: ietf@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D85561200DF; Sun, 6 Oct 2019 11:51:30 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Yoav Nir via Datatracker <noreply@ietf.org>
To: secdir@ietf.org
Cc: draft-ietf-ace-cwt-proof-of-possession.all@ietf.org, ietf@ietf.org, ace@ietf.org
Subject: Secdir last call review of draft-ietf-ace-cwt-proof-of-possession-08
X-Test-IDTracker: no
X-IETF-IDTracker: 6.104.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Yoav Nir <ynir.ietf@gmail.com>
Message-ID: <157038789080.6563.18028321376777169887@ietfa.amsl.com>
Date: Sun, 06 Oct 2019 11:51:30 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/O99IMRfTW1zjboqkUYOzyjnmWk4>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.29
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 06 Oct 2019 18:51:31 -0000
Reviewer: Yoav Nir Review result: Has Nits I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. I think the document shows that security aspects have been considered and handled well. However, the document has issues with clarity and readability: For starters, the Abstract and Introduction are nearly identical. The Introduction could instead be used to explain the domain, who the "players" are and what they are trying to accomplish. Instead, section 2 introduces the terms Issuer, Presenter and Recipient with definitions that sound like the CA, the End Entity and the Relying Party from PKI, with a little OAuth terminology mixed in. There is no explanation about who this issuer is, and what the trust model is. The Security Considerations section also has some problems. Quoting the second paragraph: Applications utilizing proof of possession SHOULD also utilize audience restriction, as described in Section 3.1.3 of [CWT], as it provides additional protections. Audience restriction can be used by recipients to reject messages intended for different recipients. Why? Why is the aud claim needed with a cnf claim (but not in other cases)? Neither this document nor RFC 8392 provides insight as to when aud is appropriate. That they allow recipients to reject messages not intended for them does not sound like a security feature. Paragraph 3 says: "A recipient might not understand the "cnf" claim." This re-affirms that we need an explanation of who the parties to this protocol are. We generally don't send messages to recipients that don't understand them. Is this a closed system with known entities, or is this a protocol where the parties contact random other parties on the Internet? I'd also lose some of the Introduction to Crypto in the second-to-last paragraph.
- Secdir last call review of draft-ietf-ace-cwt-pro… Yoav Nir via Datatracker
- RE: Secdir last call review of draft-ietf-ace-cwt… Mike Jones
- RE: Secdir last call review of draft-ietf-ace-cwt… Mike Jones