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

From: Christian Amsüss <[email-masked]>
Date: Fri, 9 Oct 2020 17:44:54 +0200

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

---

From: Daniel Migault <[email-masked]>
Date: Tue, 13 Oct 2020 09:10:41 -0400

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 <[email-masked]>
wrote:

> _______________________________________________
> Ace mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ace
>

-- 
Daniel Migault
Ericsson

---

From: Daniel Migault <[email-masked]>
Date: Thu, 15 Oct 2020 13:22:41 -0400

Hi,

To follow-up this thread, we discussed with Ben and found out that the best
path would be to go through an official WGLC before sending the document
back to the IESG. This should not change much as a careful review of the
document was needed anyway (C), so the WGLC would just consist of these
reviewers to confirm their reviews.

Yours,
Daniel

On Tue, Oct 13, 2020 at 9:10 AM Daniel Migault <[email-masked]> wrote:

> * C) WG member state whether they volunteer to review the updated
> document. I would like to avoid the document re-opened once considered
> updated.
>

-- 
Daniel Migault
Ericsson

---

From: Göran Selander <[email-masked]>
Date: Thu, 15 Oct 2020 18:01:11 +0000

Hi Christian,

The purpose of the update was to clarify that Appendix B.2 of RFC 8613 could be used in conjunction with the ACE OSCORE profile. But as you point out, the use of B.2 would need to be understood between the client and server beforehand. There are slight differences: With B.2 there is no need to transport the access token again. And B.2 can be triggered by the (resource) server, if it understands that it does not have the right context (which can happen even if there is no ID context in the request). Just using the ACE OSCORE profile, the client would need to understand that the context is lost and run the protocol again. So, there is a difference but essentially the same functionality can be obtained.

Would it be sufficient to clarify the differences as above to address your comment?

Thanks,
Göran

On 2020-10-09, 17:45, "Christian Amsüss" <[email-masked]> wrote:

    Kind Regards
    Christian

---

From: Francesca Palombini <[email-masked]>
Date: Mon, 19 Oct 2020 15:52:40 +0000

Hi Christian, Daniel,

Daniel: I agree that what you describe is the best way forward. Once the PR regarding the negotiation of Ids is merged, I can only see a minor addition to the draft, to clarify what Christian has brought up. By the end of this week we should have Christian's comment implemented as well. After that, we're ready for another round of reviews, and I think a WGLC is warranted.

Christian, let us know if there is anything else except some more considerations covering what you are saying. Göran summarized it well, but basically no, there is no particular benefit. The sentence was added as the response from a review comment, but it seems like a good idea to add more context to it. 

Thanks,
Francesca

On 15/10/2020, 20:01, "Göran Selander" <[email-masked]> wrote:

    Hi Christian,

    Thanks,
    Göran

        Kind Regards
        Christian

---

From: Daniel Migault <[email-masked]>
Date: Mon, 19 Oct 2020 16:45:20 -0400

Thanks Francesca for the reply. Other members of the WG, if you have an
opinion, please let the WG know asap. We set October 20 to get comments on
which path to take.

Yours,
Daniel

On Mon, Oct 19, 2020 at 11:52 AM Francesca Palombini <francesca.palombini=
[email-masked]> wrote:

> Hi Christian, Daniel,
>
> Daniel: I agree that what you describe is the best way forward. Once the
> PR regarding the negotiation of Ids is merged, I can only see a minor
> addition to the draft, to clarify what Christian has brought up. By the end
> of this week we should have Christian's comment implemented as well. After
> that, we're ready for another round of reviews, and I think a WGLC is
> warranted.
>
> Christian, let us know if there is anything else except some more
> considerations covering what you are saying. Göran summarized it well, but
> basically no, there is no particular benefit. The sentence was added as the
> response from a review comment, but it seems like a good idea to add more
> context to it.
>
> Thanks,
> Francesca
>
>     The purpose of the update was to clarify that Appendix B.2 of RFC 8613
> could be used in conjunction with the ACE OSCORE profile. But as you point
> out, the use of B.2 would need to be understood between the client and
> server beforehand. There are slight differences: With B.2 there is no need
> to transport the access token again. And B.2 can be triggered by the
> (resource) server, if it understands that it does not have the right
> context (which can happen even if there is no ID context in the request).
> Just using the ACE OSCORE profile, the client would need to understand that
> the context is lost and run the protocol again. So, there is a difference
> but essentially the same functionality can be obtained.
>

-- 
Daniel Migault
Ericsson

---

From: Daniel Migault <[email-masked]>
Date: Fri, 23 Oct 2020 19:58:09 -0400

I am not hearing anyone opposing the proposed way to move forward. Once we
will have the update from Francesca, we will be able to start a WGLC. On
the other hand, we will need reviews to move the document forward, so
please remain committed for the last miles!

Yours,
Daniel

On Mon, Oct 19, 2020 at 4:45 PM Daniel Migault <[email-masked]> wrote:

>>     The purpose of the update was to clarify that Appendix B.2 of RFC
>> 8613 could be used in conjunction with the ACE OSCORE profile. But as you
>> point out, the use of B.2 would need to be understood between the client
>> and server beforehand. There are slight differences: With B.2 there is no
>> need to transport the access token again. And B.2 can be triggered by the

-- 
Daniel Migault
Ericsson