[core] Secdir telechat review of draft-ietf-core-problem-details-05
Yoav Nir via Datatracker <noreply@ietf.org> Tue, 14 June 2022 20:36 UTC
Return-Path: <noreply@ietf.org>
X-Original-To: core@ietf.org
Delivered-To: core@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6617CC14CF01; Tue, 14 Jun 2022 13:36:25 -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: core@ietf.org, draft-ietf-core-problem-details.all@ietf.org, last-call@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 8.3.1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <165523898541.33763.8622699989397959926@ietfa.amsl.com>
Reply-To: Yoav Nir <ynir.ietf@gmail.com>
Date: Tue, 14 Jun 2022 13:36:25 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/4iFZxN5GxIo0QFnoPEC5S4-tSmU>
Subject: [core] Secdir telechat review of draft-ietf-core-problem-details-05
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.39
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <core.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/core>, <mailto:core-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/core/>
List-Post: <mailto:core@ietf.org>
List-Help: <mailto:core-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/core>, <mailto:core-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 14 Jun 2022 20:36:25 -0000
Reviewer: Yoav Nir Review result: Has Nits Greetings The document defines a CBOR-encoded problem details structure, similar to the JSON- or XML-encoded structure defined in RFC 7807. As such, the security considerations for it mostly mirror those of RFC 7807, and that is all that the Security Considerations section says. Following this reference, the Security Considerations section of 7807 urges caution when defining new problem types for fear of leaking sensitive information in the relevant fields of new types. There is, however, a difference between 7807 and this document. In 7807 different problems are identified by "type". In this document, there is no explicit type. Instead, there are basic details that are defined, plus a registry of standard and custom extra attributes that can be defined. The security considerations section in 7807 is phrased in terms of new types. Security considerations text written specifically for this documentation would not mention new types (which don't exist), but new detail entries. Still, the message would be the same. When defining new detail entries, care should be taken that they do not leak sensitive information. Yet because of the difference, I believe that the text should be written specifically for this document, not just referenced from 7807.
- [core] Secdir telechat review of draft-ietf-core-… Yoav Nir via Datatracker
- Re: [core] [Last-Call] Secdir telechat review of … Carsten Bormann