document considerations for rak rotation

[scottleibrand]

It's my understanding that we wish to periodically rotate rak, in order to break linkability across the tck ratchet chain. If I'm understanding correctly, if you didn’t rotate rak, that means that you can link all the subsequent tcks and therefore tcns, correct? If we instead rotate rak on a daily or even hourly basis, send one report with each rvk, and make sure the reports are batched up so it’s not obvious that they go together, your linkability ends when rak rotates, right?

In the Apple/Google protocol, the analogous key to the rak is the daily tracing key, which has a fixed rotation period of 1 day, right?

Can we document the considerations around when we should be rotating rak?

[zssz]

Reading the spec and Rust implementations, the rak is only changed when it can not generate any more tcks (2^16) and whenever the user reports sick. The tcks provide the protection agains linkability.

[brian-peter-dickson]

The first step in TCN generation is the hash(rak) to get the tck_0. In a report, tck{j1-1} is provided to allow forward enumerations of TCNs starting with j1.

Since linkage would only be forward from that point, the only time rak needs to rotate is when a report is issued.

If the core TCN protocol (including notifications) is altered, there's a good chance that rak/rvk pairs could need to be kept for a period of time (e.g. 2 weeks), so only rotating rak when actually required is probably better than doing it periodically.

[hdevalence]

@scottleibrand Yes, you're correct, the rak is the analogue of the daily tracing key in the AG protocol.

Each report authorization key can be used to publish one report (= group of linkable TCNs), so the report authorization key should be rotated at least as frequently as once per day, maybe more frequently.

[scottleibrand]

(Posted prior to seeing @hdevalence's note) I'm unclear on how tck's would provide any protection against linkability for the time period covered by a report. If you report tck_j1 and rvk, and I can use those to generate every TCN up to j2, can't I link all the TCNs I observed that were generated by the user submitting that report? And if so, doesn't that force linkability over the entire duration you were contagious? If we assume that starts 2 days before symptoms, and people on average report symptoms after 1 day, that means we'd be providing a report with j1 to j2 covering a 3 day window, and allowing full linkability over that timeframe. Wouldn't that provide worse linkability protection than the A/G proposal with daily tracing keys?

[scottleibrand]

Ok, given @hdevalence's response, I think the original request in this issue (document the considerations around when we should be rotating rak). Is there any more to it than adding this to the readme?

Each report authorization key can be used to publish one report (= group of linkable TCNs), so the report authorization key should be rotated at least as frequently as once per day, maybe more frequently.

If not I can go ahead and PR it.

[hdevalence]

@scottleibrand I think that there is some rough text about rotation considerations further down in the document (maybe the first subheading in the rough notes section), so a PR adding this language could also remove that rough text and work it into the body text.

[degregat]

I made an interactive notebook that runs online, where you can explore the bandwidth requirements of different rotation schemes here: https://github.com/degregat/tcn-calculation-notebooks

If someone creates a repo in this org I could push it there too. (Binder needs to have its own repo to run it online.)

[hdevalence]

@scottleibrand do you have in-flight work on this already? if not i'm happy to make these changes now, just don't want to clobber anything.

[scottleibrand]

I haven't gotten to it yet. Please go ahead.

[hdevalence]

Created #73.

[hdevalence]

Merged #73 but open to revisions of its contents.