Re: [Ace] OSCORE Profile status update and way forward

Christian Amsüss <christian@amsuess.com> Fri, 09 October 2020 15:45 UTC

Return-Path: <christian@amsuess.com>
X-Original-To: ace@ietfa.amsl.com
Delivered-To: ace@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96F5F3A09E1; Fri, 9 Oct 2020 08:45:02 -0700 (PDT)
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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] 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 sHuaJWL1kVFG; Fri, 9 Oct 2020 08:45:00 -0700 (PDT)
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 B6BA43A08C5; Fri, 9 Oct 2020 08:44:58 -0700 (PDT)
Received: from poseidon-mailhub.amsuess.com (095129206250.cust.akis.net [95.129.206.250]) by prometheus.amsuess.com (Postfix) with ESMTPS id B36B140039; Fri, 9 Oct 2020 17:44:56 +0200 (CEST)
Received: from poseidon-mailbox.amsuess.com (poseidon-mailbox.amsuess.com [IPv6:2a02:b18:c13b:8010:a800:ff:fede:b1bf]) by poseidon-mailhub.amsuess.com (Postfix) with ESMTP id 75F5E74; Fri, 9 Oct 2020 17:44:55 +0200 (CEST)
Received: from hephaistos.amsuess.com (unknown [IPv6:2a02:b18:c13b:8010:10a3:89db:f76:e611]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id AF27064; Fri, 9 Oct 2020 17:44:54 +0200 (CEST)
Received: (nullmailer pid 1057477 invoked by uid 1000); Fri, 09 Oct 2020 15:44:54 -0000
Date: Fri, 9 Oct 2020 17:44:54 +0200
From: Christian =?iso-8859-1?Q?Ams=FCss?= <christian@amsuess.com>
To: Francesca Palombini <francesca.palombini=40ericsson.com@dmarc.ietf.org>
Cc: Ace Wg <ace@ietf.org>, "draft-ietf-ace-oscore-profile@ietf.org" <draft-ietf-ace-oscore-profile@ietf.org>
Message-ID: <20201009154454.GA1050533@hephaistos.amsuess.com>
References: <2D021116-D240-4EE8-9223-83E9F9D4A4EB@ericsson.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="d6Gm4EdcadzBjdND"
Content-Disposition: inline
In-Reply-To: <2D021116-D240-4EE8-9223-83E9F9D4A4EB@ericsson.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/ace/km796mYSTzzhYXlYrutuQczOOBQ>
Subject: Re: [Ace] OSCORE Profile status update and way forward
X-BeenThere: ace@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" <ace.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ace>, <mailto:ace-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ace/>
List-Post: <mailto:ace@ietf.org>
List-Help: <mailto:ace-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ace>, <mailto:ace-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 09 Oct 2020 15:45:03 -0000

Hello Francesca, hello ACE group,

On Mon, Sep 21, 2020 at 01:48:33PM +0000, Francesca Palombini wrote:
> - clarified that Appendix B.2 of OSCORE can be used with this profile,
> and what implementers need to think about if they do.

I understand B.2 to be something that the involved parties need to agree
on beforehand; after all, the ID context may be something the server
relies on (at least for the initial attempt) to find the right key,
especially when multiple AS are involved. (For example, the RS could
have an agreement that the AS may issue any KID as long as they use a
particular ID context). If the server expects B.2 to happen (which, as
it is put now, it can as long as it supports it in general), it needs to
shard its KID space for the ASs it uses. (Generally, B.2 is mutually
exclusive with ID contexts's use of namespacing KIDs).

Is the expectation that clients that do not anticipate B.2 by the time
they are configured with their AS just don't offer B.2 to their peers?

Given B.2 is in its current form client-initiated only (AFAIR we had
versions where ID1 could be empty in draft versions, but currently it
reads as client-initialized), does B.2 have any benefits for ACE-OSCORE
clients? After all, they could just as well post the token with a new
nonce1 to the same effect.

Kind Regards
Christian

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