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

From: Jaime Jiménez <[email-masked]>
Date: Tue, 09 Nov 2021 09:48:42 +0200

Dear CoRE,

In yesterday's CoRE meeting, we had good in-room consensus to
adopt draft-hoeglund-core-oscore-key-limits as a WG draft (Adoption call: +9, one "not raise hand" ).

As usual, we need to confirm consensus on the list. If you are opposed to adopting this document, please speak up on this
list. The WGA call will last until November 22 to give time to process things after IETF 112.

If you were in the meeting, you don't have to confirm consensus again.

Ciao!
-- 
Jaime Jiménez

---

From: Christian Amsüss <[email-masked]>
Date: Tue, 9 Nov 2021 17:24:56 +0100

Hello Jaime,

> call: +9, one "not raise hand" ).

I was one of the 9, and just want to reiterate here that I consider both
parts of the document important for the WG. I do not understand all the
pieces that come together on the IA and CA limits part, but can offer
reviews of KUDOS part as this will progress.

Thank you Rikard and Marco for working on this
Christian

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

---

From: John Mattsson <[email-masked]>
Date: Mon, 15 Nov 2021 10:22:46 +0000

Hi,

There has recently been discussion about connection ID privcacy in LAKE WG and the corresponding identifiers in the application protocol. I.e. Sender ID and Recipient ID in OSCORE. Christian wrote that ability to correlate connection beteen two points in time or between paths is also related to sequence numbers.

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.

https://github.com/core-wg/oscore/issues/263
https://github.com/lake-wg/edhoc/issues/202

Background info on connection ID update in QUIC and DTLS 1.3:
https://datatracker.ietf.org/doc/html/rfc9000#section-5.1
https://datatracker.ietf.org/doc/html/draft-ietf-tls-dtls13-43#section-9

Cheers,
John

From: core <[email-masked]> on behalf of Christian Amsüss <[email-masked]>
Date: Tuesday, 9 November 2021 at 17:25
To: Jaime Jiménez <[email-masked]>
Cc: [email-masked] <[email-masked]>
Subject: Re: [core] 🔔 Confirming adoption of draft-hoeglund-core-oscore-key-limits-02 as a CoRE WG document
Hello Jaime,

---

From: Christian Amsüss <[email-masked]>
Date: Mon, 15 Nov 2021 15:30:58 +0100

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

---

From: Jaime Jiménez <[email-masked]>
Date: Tue, 30 Nov 2021 11:11:56 +0200

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:
> Attachments:
> * signature.asc