Re: [core] New Version Notification for draft-amsuess-core-pd-body-error-position-00.txt

Christian Amsüss <christian@amsuess.com> Mon, 06 February 2023 13:54 UTC

Return-Path: <christian@amsuess.com>
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1B47C1522A4 for <core@ietfa.amsl.com>; Mon, 6 Feb 2023 05:54:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fnv_di0HoxdQ for <core@ietfa.amsl.com>; Mon, 6 Feb 2023 05:54:12 -0800 (PST)
Received: from smtp.akis.at (smtp.akis.at [IPv6:2a02:b18:500:a515::f455]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3C7EEC14CE54 for <core@ietf.org>; Mon, 6 Feb 2023 05:54:10 -0800 (PST)
Received: from poseidon-mailhub.amsuess.com ([IPv6:2a02:b18:c13b:8010:a800:ff:fede:b1bd]) by smtp.akis.at (8.17.1/8.17.1) with ESMTPS id 316Ds5HJ055435 (version=TLSv1.2 cipher=ECDHE-ECDSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 6 Feb 2023 14:54:05 +0100 (CET) (envelope-from christian@amsuess.com)
X-Authentication-Warning: smtp.akis.at: Host [IPv6:2a02:b18:c13b:8010:a800:ff:fede:b1bd] claimed to be poseidon-mailhub.amsuess.com
Received: from poseidon-mailbox.amsuess.com (hermes.amsuess.com [10.13.13.254]) by poseidon-mailhub.amsuess.com (Postfix) with ESMTP id EDD961A703; Mon, 6 Feb 2023 14:53:59 +0100 (CET)
Received: from hephaistos.amsuess.com (hephaistos.amsuess.com [IPv6:2a02:b18:c13b:8010::907]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id C3F111CF91; Mon, 6 Feb 2023 14:53:59 +0100 (CET)
Received: (nullmailer pid 23359 invoked by uid 1000); Mon, 06 Feb 2023 13:53:59 -0000
Date: Mon, 06 Feb 2023 14:53:59 +0100
From: Christian Amsüss <christian@amsuess.com>
To: Michael Richardson <mcr+ietf@sandelman.ca>
Cc: Carsten Bormann <cabo@tzi.org>, Thomas Fossati <thomas.fossati@arm.com>, "core@ietf.org" <core@ietf.org>
Message-ID: <Y+EGd71HyshqNpxd@hephaistos.amsuess.com>
References: <Y97e6dWnME7brk7r@hephaistos.amsuess.com> <DB9PR08MB65244577297F4C3CC1673E469CD59@DB9PR08MB6524.eurprd08.prod.outlook.com> <9374D4B8-6A82-4280-8329-69BB7C0899E3@tzi.org> <2226531.1675604105@dyas>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="X30wJ5dIuC7mo4oa"
Content-Disposition: inline
In-Reply-To: <2226531.1675604105@dyas>
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/JQSRGEy3HaCcxcXIpVusG3Y03IY>
Subject: Re: [core] New Version Notification for draft-amsuess-core-pd-body-error-position-00.txt
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
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: Mon, 06 Feb 2023 13:54:17 -0000

On Sun, Feb 05, 2023 at 02:35:05PM +0100, Michael Richardson wrote:
> Do you think that we will turn this off in production?

No. (It doesn't make much difference in the firmware size). But messages
with this value in would not be part of everyday errors, and thus not
worthy of the 1+0 space.

> Do we need to consider an attacker that if basically doing online fuzzing
> against a live target?

I'd refer to Kerckhoffs's principle here. Sure, there are reasons to
limit leaking implementation details, but when sending Problem Details
responses, we're already way beyond limiting the radar cross-section. In
other words, this remark is valid for most Problem Details items, and
while it's a bit more applicable here than on others, I think that's
only barely so.

BR
c

-- 
To use raw power is to make yourself infinitely vulnerable to greater powers.
  -- Bene Gesserit axiom