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

Daniel Migault <mglt.ietf@gmail.com> Tue, 13 October 2020 13:10 UTC

Return-Path: <mglt.ietf@gmail.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 DFBFD3A0FBD; Tue, 13 Oct 2020 06:10:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 cePj5RdUX_VT; Tue, 13 Oct 2020 06:10:53 -0700 (PDT)
Received: from mail-ua1-x92f.google.com (mail-ua1-x92f.google.com [IPv6:2607:f8b0:4864:20::92f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0DE213A0FA6; Tue, 13 Oct 2020 06:10:53 -0700 (PDT)
Received: by mail-ua1-x92f.google.com with SMTP id x26so6442938uan.11; Tue, 13 Oct 2020 06:10:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=cEHX+fBdlPpg3iVhJulD3uk8brvHID6oHbcWqAN3HCg=; b=l0C3Lb0v6iW3Va+gY7kb/NfnQQh1W0j7n7VXoh7CvLd6mQD5UHsSbFCI4KNerZtsqu ObbH84KTOOkqoS3gPEoMC4gWZK/zm6hUpCv5Uc/1mmvg7qEhIVBd6ezQay5+rxb/Q7XU B0zoOdaz/wFMGpu7AI9Bc6UfDfq0eOudKAOsSCxIOCtjzxpRAirpXkPTgctvmoH/vSFh iWuLYAl/JxeR/mB/33YeUvGbY1C5YFbISjvusFIN1t+PTQa5++84Y+ycjJ0AFJILkqDp EitQfa+352ab0CEeCeQPw+IrRb9Vpm+eGJMdziZm8nxeSFSVNrKGnQNT0yAI2PPxjacx B/DQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=cEHX+fBdlPpg3iVhJulD3uk8brvHID6oHbcWqAN3HCg=; b=JKHTmhbdbSzLSkNXzHqNWVOSTFpdGv1crxJF21TOwZ9sZk3NmSr4VBneop3V46Z8Ja /iwA0D5Fyknx1mU7OASbGN5gqWH+f1lApxMAAY04FG/Jz3cKXRt0fIqk5bU2p2H7vMHH XHJZqkDYKJuERp3dU6ET+hBaLMOACJAsS0206DI00obp8g7+p3hAEQWBFB2MM3rpKyaP s33fA++MbG99UMlkTfJttAkacTFV4EUofD9fRhjbvnF6hzEmHFCVbPdZ9CC0nO9xYU4t XI5fsGnaU7viTfd71zJ8WX0EkglYg+3McWxydHwqftlwp54ne1aPQ3Yo205TRmhXjP04 WAOg==
X-Gm-Message-State: AOAM532th4yIPygo7lG7i+oA3SctaOP2NmUQNrq7gItxUM+MbuRC8LqF mTLbLLO4es5cGhqBd9++T7K9pqM2RrUVqGQvpDF9w+xgCjE=
X-Google-Smtp-Source: ABdhPJxNJSi8ELARmn+u0N93g58qyvEzXw7oGFyp2Ijb0p6uF1PFJ7/sSszYmGpZ7Au8tk0RwzQKPVVN9hjqwmtk4Wk=
X-Received: by 2002:a9f:3f4f:: with SMTP id i15mr2077131uaj.7.1602594651900; Tue, 13 Oct 2020 06:10:51 -0700 (PDT)
MIME-Version: 1.0
References: <2D021116-D240-4EE8-9223-83E9F9D4A4EB@ericsson.com> <20201009154454.GA1050533@hephaistos.amsuess.com>
In-Reply-To: <20201009154454.GA1050533@hephaistos.amsuess.com>
From: Daniel Migault <mglt.ietf@gmail.com>
Date: Tue, 13 Oct 2020 09:10:41 -0400
Message-ID: <CADZyTkkJm8bnVTT0igZk2YpbPypQRufGruG9evty2SONRyob_A@mail.gmail.com>
To: =?UTF-8?Q?Christian_Ams=C3=BCss?= <christian@amsuess.com>
Cc: Francesca Palombini <francesca.palombini=40ericsson.com@dmarc.ietf.org>, "draft-ietf-ace-oscore-profile@ietf.org" <draft-ietf-ace-oscore-profile@ietf.org>, Ace Wg <ace@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000f20f1305b18d24cb"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ace/ciODGrpFrRbMHeqWnAPNuezJn3E>
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: Tue, 13 Oct 2020 13:10:56 -0000

Dear WG,

If I attempt to balance the different 3 proposals, my perception is we may
address a specific scenario into the core profile with no additional
complexity versus via extensions. This leaves working on a profile v2
(option 2) or updating the to-become soon profile v1 (option 3). I prefer
to avoid specifications being deprecated before they are even published and
would prefer to consider updating the current version.

I suspect that multiple versions of a profile can co-exist and that the
problem of having a profile v2 that interoperate with a profile v1 - which
does not seem mandatory.

In order to move forward, I propose that by October 20:
* A)  WG member state their opinion regarding that we revise the oscore
profile document
* B) Francesca refines the proposed changes, so the document is ready for
review
* C) WG member state whether they volunteer to review the updated document.
I would like to avoid the document re-opened once considered updated.

With A, B and C I will be able to discuss with Ben how to move forward the
document. I am happy to get your feed backs or suggestions.

Yours,
Daniel





On Fri, Oct 9, 2020 at 11:45 AM Christian Amsüss <christian@amsuess.com>
wrote:

> 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
> _______________________________________________
> Ace mailing list
> Ace@ietf.org
> https://www.ietf.org/mailman/listinfo/ace
>


-- 
Daniel Migault
Ericsson