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

Christian Amsüss <c.amsuess@energyharvesting.at> Mon, 13 November 2017 17:43 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 802C012946B; Mon, 13 Nov 2017 09:43:20 -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 9I5MEwUgeWRE; Mon, 13 Nov 2017 09:43:18 -0800 (PST)
Received: from prometheus.amsuess.com (alt.prometheus.amsuess.com [IPv6:2a01:4f8:190:3064::3]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AAE121200F3; Mon, 13 Nov 2017 09:43:18 -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 5FB5C488EF; Mon, 13 Nov 2017 18:43:16 +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 9931744; Mon, 13 Nov 2017 18:43:15 +0100 (CET)
Received: from hephaistos.amsuess.com (hermes.amsuess.com [10.13.13.254]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id 6345531; Mon, 13 Nov 2017 18:43:15 +0100 (CET)
Received: (nullmailer pid 5334 invoked by uid 1000); Mon, 13 Nov 2017 17:43:14 -0000
Date: Mon, 13 Nov 2017 18:43:14 +0100
From: Christian Amsüss <c.amsuess@energyharvesting.at>
To: Klaus Hartke <hartke@projectcool.de>
Cc: lwip@ietf.org, "core@ietf.org WG" <core@ietf.org>
Message-ID: <20171113174314.7ohihr724xaxrp7l@hephaistos.amsuess.com>
References: <20171113165421.d23nmwklwjfwxaem@hephaistos.amsuess.com> <CAAzbHvaNvodqVfu+cD3K2JijSn=4nQB2mZRnRSV81bq+r0AFsw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="7arkkdv2cdxc2sfe"
Content-Disposition: inline
In-Reply-To: <CAAzbHvaNvodqVfu+cD3K2JijSn=4nQB2mZRnRSV81bq+r0AFsw@mail.gmail.com>
User-Agent: NeoMutt/20170609 (1.8.3)
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/E-FBAVZU_-0Js7Ombrvcl73UDKs>
Subject: Re: [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 17:43:20 -0000

Hello Klaus,

thanks for your reply.

On Mon, Nov 13, 2017 at 06:23:59PM +0100, Klaus Hartke wrote:
> If it's a new observation, then the client should not use a token that
> is still in use. RFC 7252 Section 5.3.1:
> 
>    The client SHOULD generate tokens in such a way that tokens currently
>    in use for a given source/destination endpoint pair are unique.

My hypothetical client was using the "but I already cancelled, it's not
in use any more, didn't you get the NON?" defense -- but fair point.

> In case a server (or proxy in the role of a server) receives an
> observation request with a token that is still in use, it must kill
> the existing observation. RFC 7641 Section 4.1:
> 
> [...]
> 
> So the server already doesn't enforce the client requirement.

Hmpf, that would mean that a correct proxy would treat an OSCORE
re-registration with new (encrypted) ETag set as a new observation. It
would determine that the old observation is over, cancel its observation
to the origin server and start a new one, presumably (under the
abovementioned) using a new token. Should work, but it's a new
observation at the origin.

A very smart proxy might even notice that rather than cancelling the
observation, it can start the new one on the same token and thus do both
cancellation and new registration in a single packet (making things
magically smoother), but that might be considered smart to the extent of
specification abusal.

A less smart proxy might even decide to let the old observation cancel
itself by forgetting it and open the new one, resulting in two
simultaenous registrations at the origin -- not ideal, but maybe
tolerable.


Do you think there is a practical way around this that is not "OSCORE
observations can never be renewed (can never have a bit different, thus
no new nonce, no new freshness and no new ETags), and to renew an OSCORE
observation you have to cancel the old one and register a new one"?

Best regards
Christian

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