Re: [core] 🔔 Confirming adoption of draft-hoeglund-core-oscore-key-limits-02 as a CoRE WG document

[Jaime Jiménez <[e-mail]>]

Dear all,

we are a week past the confirmation deadline, hearing no-one against the adoption and given the existing support I think it is time to adopt this document.

The authors are recommended to create a repository "oscore-key-limits" in the core-wg GitHub. 

Thank you!
-- 
Jaime Jiménez

On Mon, Nov 15, 2021, at 4:30 PM, Christian Amsüss wrote:
> Hello John, KUDOS authors,
>
> On Mon, Nov 15, 2021 at 10:22:46AM +0000, John Mattsson wrote:
>> I think it would be good to discuss if the KUDOS rekeying mechanism
>> should/could be used to also update the identifiers. KUDOS resets the
>> sequence numbers. I have not thought about this in any detail or that
>> it is something we should do, I just suggest that we discuss it.
>
> The two are related but at different layers; any solution combining them
> would need to operate on both. (KUDOS sending unprotected nonces, new
> KIDs would need to be negotiated in encrypted data).
>
> It may help to see them independent initially:
>
> * KUDOS allows using new key material from a preexisting context, with
>   sequence numbers starting at 0 again, but keeps the same KIDs.
>
> * KID switchovers could be announced using inner options -- "Please
>   address me as ${my_new_sender_ID} henceforth".
>
>   Keeping the master key, whoever changes their KID needs to be aware of
>   all KIDs previously used on that shared context. In particular, the ID
>   needs to stay unused until the peer has acknowledged (eg. by using the
>   new ID) that it didn't try to switch to that ID at the same time.
>
> The requirement to know history (lest a sender key get drived a second
> time) is what makes KID changes convenient to do at KUDOS time (when the
> list of previously used KIDs is empty again).
>
> BR
> c
>
> -- 
> To use raw power is to make yourself infinitely vulnerable to greater powers.
>   -- Bene Gesserit axiom
>
> Attachments:
> * signature.asc