[core] Proxies and observations: "All options MUST be identical"

Christian Amsüss <c.amsuess@energyharvesting.at> Mon, 13 November 2017 16:54 UTC

Return-Path: <c.amsuess@energyharvesting.at>
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 EB19E129B0E; Mon, 13 Nov 2017 08:54:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no
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 QQqKejpded90; Mon, 13 Nov 2017 08:54:25 -0800 (PST)
Received: from prometheus.amsuess.com (prometheus.amsuess.com [5.9.147.112]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C399312945A; Mon, 13 Nov 2017 08:54:25 -0800 (PST)
Received: from poseidon-mailhub.amsuess.com (unknown [IPv6:2a02:b18:c13b:8010:a800:ff:fede:b1bd]) by prometheus.amsuess.com (Postfix) with ESMTPS id 5058B488EF; Mon, 13 Nov 2017 17:54:24 +0100 (CET)
Received: from poseidon-mailbox.amsuess.com (poseidon-mailbox.amsuess.com [10.13.13.231]) by poseidon-mailhub.amsuess.com (Postfix) with ESMTP id D510344; Mon, 13 Nov 2017 17:54:22 +0100 (CET)
Received: from hephaistos.amsuess.com (hermes.amsuess.com [10.13.13.254]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id A48B331; Mon, 13 Nov 2017 17:54:22 +0100 (CET)
Received: (nullmailer pid 2216 invoked by uid 1000); Mon, 13 Nov 2017 16:54:21 -0000
Date: Mon, 13 Nov 2017 17:54:21 +0100
From: Christian Amsüss <c.amsuess@energyharvesting.at>
To: core@ietf.org, lwip@ietf.org
Message-ID: <20171113165421.d23nmwklwjfwxaem@hephaistos.amsuess.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="5frdpjs4xkbpdak5"
Content-Disposition: inline
User-Agent: NeoMutt/20170609 (1.8.3)
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/bdIQyrGH4DroFt37bXbal0LKXBc>
Subject: [core] Proxies and observations: "All options MUST be identical"
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.22
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, 13 Nov 2017 16:54:27 -0000

Hello CoRE and LWIG groups,

when discussing re-registration of observations in the context of
OSCORE with Jim and the OSCORE authors, we stumbled upon the sentence
"All options MUST be identical to those in the original request except
for the set of ETag Options." about this in RFC7641.

This is something that servers, especially proxies, should not try to
enforce, because every case of a request with differing options (or
FETCH payload) could just as well be a new observation from the client
on the token whose observation cancellation got lost, or the client
simply rebooted.

I'd like to take that recommendation down somewhere (or have it
challenged before it's relied on by OSCORE). Where would that fit?
RFC7641 errata? draft-ietf-lwig-coap? 

Best regards
Christian


PS. if you're interested in the context: ETag is an encrypted option in
OSCORE. Changing the ETag means re-encrypting the message, which
requires a new nonce and thus also changes the Content-Security option
-- and thus we'll allow that there. I think it's OK to do that because
the underlying rule is unenforcable anyway.

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