information leaked through size/freq of client to server queries.

[Matioupi]

If i understand correctly there are 3 types of request from client to server: -registration -possible infection status query -voluntary infection status update

I may have missed it, but without special care about the frequency / size of those request, i believe that simple analysis of request size/frequency may leak information that could be captured (or maybe must be captured by some legal logs). E.g. voluntary infection status will carry much more information and size will be larger. It will also be one unique 'asynch' message. I'm not sure that the considered adversal assumptions adress this. If not I believe they are too weak.

[Matioupi]

the PEPP-PT document : https://github.com/pepp-pt/pepp-pt-documentation/blob/master/PEPP-PT-data-protection-information-security-architecture.pdf

somehow mention this (page 6/25) :

We assume all channels used in the system, e.g., those between backend subsystems, and any Health Authority devices, or between the backend and the users, is integrity- and confidentiality-protected, e.g., with TLS with appropriate key pinning. However, our assumption is limited to what current protections TLS 1.2 provides (e.g., we include in our analysis that an eavesdropper can see packet destinations, timings and volumes, which are not protected in TLS 1.2).

[Matioupi]

https://github.com/DP-3T/documents/blob/master/DP3T%20-%20Data%20Protection%20and%20Security.pdf also address this concern (p 9/11) :

To combat traffic analysis, apps periodically upload data to the server at predetermined intervals (e.g., every 6 hours). If they are uploading the seed after being diagnosed, it uploads the real EphID-representation and the authorization code. Otherwise, the app transmits a dummy message formed by random bytes of the same size.

one consequence of this approach is that it may add up to 6h delay in advertising the server (with doc exemple 6h value). The fixed message size may also not fit the ROBERT protocol, or may have to be very large to handle special cases with lots of contacts.

This also generates overhead in terms of traffic. Maybe a randomized size (with minimal value) randomized frequency broadcast would cover some of those issues.

[kaythxbye]

The parallel development of the German implementation uses a push service and mentions that they randomly send out garbage notifications to generate cover traffic:

https://github.com/pepp-pt/pepp-pt-documentation

(Unfortunately it's also a PDF so no line numbers)

[Matioupi]

from the pepp-pt (p24/25) :

In the current concept, a determined A5 adversary can learn from network traffic observations that a user is uploading her proximity history and might thus be Covid-19 infected. While we consider this attack to impose a low risk, as only ISPs could carry it out at a larger basis

I understand that the approach is in the Future mitigation chapter, so not yet implemented. Also, I quite disagree with the idea that only ISP can carry this out at a large basis. In many enterprises, the WiFi network is used to carry network data while at work. And will network traffic will go through enterprise router first where this information can easily be retrieved. This cover a lot of easily identifiable users.