[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.