Add note for implementers about counting q using SSN

[rikard-sics]

Add note for implementers saying that q can be counted in a possibly more efficient way. This is by keeping the count of replies sent without partial IV in count_q and then adding to that the Sender Sequence Number to get the full count_q value.

[rikard-sics]

Consider waiting for resolution of issue "Each client can count q up to half(?) the q limit as an optimization"

[rikard-sics]

• Original issues
  • https://gitlab.com/rikard-sics/draft-hoeglund-oscore-rekeying-limits/-/issues/1
  • https://gitlab.com/rikard-sics/draft-hoeglund-oscore-rekeying-limits/-/issues/13

Goal: avoid keeping an explicit count_q, while still ensuring by construction to not exceed count_q encryptions.

Both client and server

• no explicit count_q to store and maintain, just rely on the Sender Sequence Number (SSN); still count_q represents the amount of performed encryptions
• check if the SSN exceeds q_limit; if yes, stop and rekey

It works on the client

• because every request has PIV, hence SSN coincides with the theoretical count_q

It works on the server

• because every notification and other responses with PIV make SSN count such responses. That is, the server knows it has performed at least SSN encryptions.
• in addition the server trusts the client to stop transmitting and start a rekeying, and especially to never send a request that would make the server perform more than q_limit encryptions

[rikard-sics]

Example

c->s PIV: 0, Observe (1 encryption C) s->c PIV: Notification (1 encryption S) s->c PIV: Notification (1 encryption S) s->c PIV: Notification (1 encryption S)

c: 1 encryption / SSN = 1 s: 3 encryption / SSN = 3

q_limit = 4

c->s PIV: 1 - (1 encryption C) s->c PIV: - (1 encryption S)

c: 2 encryption / SSN = 2 s: 4 encryption / SSN = 3

c->s PIV: 2 - (1 encryption C) s->c PIV: - (1 encryption S) // The server is already acting wrong here

c: 3 encryption / SSN = 3 s: 5 encryption / SSN = 3

c->s PIV: 3 - (1 encryption C) // The client would stop after this s->c PIV: - (1 encryption S)

c: 4 encryption / SSN = 4 s: 6 encryption / SSN = 3

---

A possible optimization can work as follows.

Pro: no need to keep an explicit count_q. Con: pessimistic overestimation, staling the keys earlier than needed

At any point in time, an endpoint has made at most ENC = (SSN + SSN*) encryptions, where:

• SSN is its own Sender Sequence Number.

• SSN is the other endpoint's Sender Sequence Number. That is, SSN is an overestimation of the responses without Partial IV that this endpoint has sent.

• Before performing an encryption, an endpoint stops and invalidates the Security Context if (SSN + X) > limit_q , where SSN is the Sender Sequence Number of this endpoint, and X is determined as follows:

• if this endpoint is producing an outgoing response, X is the Partial IV in the request it is responding to.

  • Note that X < SSN* always holds.

• if this endpoint is producing an outgoing request, X is the highest Partial IV value marked as received in its Replay Window, or (REPLAY_WINDOW_SIZE - 1) if it has received no messages yet from the other endpoint.

  • That is, X is the highest Partial IV seen from the other point, i.e. its highest seen Sender Sequence Number, and again X < SSN* always holds.

[rikard-sics]

This should be what is covered in _Appendix B. Estimation of 'countq'