--- IETF 108: PEARG Date: Monday, 27 July 2020 Time: 11:00 -- 12:40 (UTC) Session: 1 Location: Meetecho (Room 2) --- # PEARG 108 meeting minutes Chairs: Sara Dickinson, Shivan Sahib, Chris Wood Agenda and slides: https://datatracker.ietf.org/meeting/108/session/pearg ## Administrivia (5 minutes) - Blue sheets / scribe selection / NOTE WELL - Jabber scribe: Shivan Sahib - Note taker: Kris Shrishak - Agenda revision ## New Work / Presentations (60 mins) - Testing Apps for COVID-19 Tracing (TACT) - Stephen Farrell (15 mins) - Joint work with Doug Leith - Background: A March 2020 paper that claimed that a mobile application can make contact tracing instantaneous. - Take the results as a snapshot as this is a fast moving field - Description of Google/Apple Exposure Notification (GAEN) system - Health authorities give a threshold to the app and the app compares the attenuation values to this threshold - Replay attacks are possible in GAEN and Singapore system. - However, replay attacks have not been mitigated and have not yet happened - Measurements of deployments underway for many of the apps used in European countries - Does Bluetooth proximity work? Pairwise tests for different handsets 1m apart produce false negatives if there is noise due to orientation. - Tests on Android by capturing traffic, performing Man-in-the-middle and unpinning - Apps do not work without Google Play services - Germany and switzerland and good while Ireland is somewhere in the middle - Google Play services sends persistent identifiers to a checkin API. Ip-address can be used to geo-locate - No DPIA for GAEN API - Google Play services is closed-source - QUESTIONS - Q:Geoffrey: Was a bug report filed with Google? A: Contacted people at Google but not sure whether they consider it to be a bug. - Trust Token architecture and the private metadata bit - Steven Valdez (15 mins) - Trying to protect against DOS, Bots and Spam - Old way: Use a Trust provider for a CAPTCHA challenge - New way: Trust attestation instead of generalized third-party state - Token properties: Unforgeable, non-malleable, unlinkable, efficient and verifiable (these properties are already part of privacy pass) - An additional new property with 1-bit private metadata - Attempt 1: Using Zero-Knowledge proofs (DLEQOR proofs) - Attempt 2: Using PMBTokens + DLEQOR proofs with P-384 + batching - Redemption records - Key management using a proxy to fetch all the issuer key commitments and sends them to clients - Next steps: Privacy pass IETF standardization (first session on Friday 31 July 2020) - QUESTIONS: - Q: Christopher Wood: Is Google's key system a candidate for registry? A: Steven: A good candidate. Looking into whether it might work. Key transparency systems could be something that might work. - Deanonymizing Internet Traffic with Website Fingerprinting - Nate Matthews (15 mins) - TOR: circuit where no single node has complete path information - Website fingerprinting in closed-world (for benchmarking) and open-world scenarios (more realistic but difficult) - Techniques: - Handcrafted features using ML classifiers - Deep learning - New directions: - improve performance in open-world - improve attacker assumptions (lower data requirements and webpage vs. website fingerprinting) - Triplet fingerprinting 1. Pre-training step (uses a large dataset with a triplet network to extract features) 2. Training set (Collected targeted data and processes into features) 3. Attack step (captures unknown sample and predicts with trained classifier) - Website fingerprinting defenses - Hide patterns to confuse classifier using fake packets and adding delays - Stuff trace with fake traffic - Create traffic pattern collisions (lower overhead with mathematical guarantees; hard to implement) - Adversarial patches - Using a new style (bursts) to represent traffic sequences - Ongoing work: robust patching training scheme - So far this technique is effective - Open questions on WF defense - How much defense is enough? Overhead vs. effectiveness. - Difficult to defend against future, unknown attack types - No questions - Randomized Response Mechanisms in RTT Measurements for QUIC - Amelia Andersdotter (15 mins) - Draft: draft-andersdotter-rrm-for-rtt-in-quic-00 - Differential Privacy: mathematical way to ascertain a level of privacy while preserving the utility of the data - Randomized Response Mechanisms (RRM) does not remedy the privacy concerns raised in QUIC WG - It could provide a mechanism to allow for a large degree of client control over RTT measurements; requires more precise specification - RRM gives more outcomes than is possible without RRM; RRM was created to ensure individual privacy in surveys - How do you estimate the number of yes and no while only knowing the total number of yes/no responses and the assumed proportion of truth/false sayers. - Sec. 7.1: RRM makes the spin bit end in a loop. This is not necessarily bad. - Three parameters: probability that the server lies, the client lies and the random variable that re-sets the spin bit after it ended in a loop - Reviews are sought. - Sara: Would like to see additional reviews on the list. It is useful to the research group. There will be a call for adoption. ## RG draft updates (30 minutes) - A Survey of Worldwide Censorship Techniques, Joe Hall (10 mins) - Good feedback. Thanks especially to Amelia. - Summary of the draft - Remaining issues: - Can we get by with a restricted definition of censorship? - "Network censorship technique" or "techniques employed for censorship" instead of "censorship techniques" - Censor maturity - In the next version: Inclusion of Oakland SOK on censorship techniques - Sara: Clarification question about including the remaining issues. - Joe: Expect another update to the draft before asking for another LC. - Joe: We also need to discuss how we talk about censorship techniques. - Amelia: Carsten Borrmann proposed to use "techniques employed for censorship" instead of "censorship techniques" and I will be in favour of this change. Does anyone have a reservation on this? - Joe: There are three instances where we mention this. So, we can make the change. It is also mentioned on the title though. - Amelia: In the past, in other standards meetings there have been long discussions on what networks mean and we may not want to have such philosophical discussions on this topic in this group. - Sara: Clarification - The changes will be discussed on the mailing list (not in the github issues)? - Joe: Yes - Peter Koch: is the 'censorship' draft a new playing field to establish (or not) DNS as a content control plane, i.e., more of a policy issue? - Joe: No - Personal Information Tagging for Logs, Sandeep Rao (10 mins) - Log and privacy - Challenges: subjective and there are no standard/guidelines - We are looking to provide a reference model to enable tagging of personal information at source and illustrate ways to tag it with log data - Privacy tagging at field level and log level; privacy tagging using redaction action - Future work: Privacy preservation across log transformations, change of privacy marking policy (how to enforce these changes) and out-of-band mechanism to notify privacy scheme - Stephen Farrell: One of things I have noticed is that any field that uses human input contains a password. Consider tagging not only the data type but also the source. - Sandeep Rao: Good input - teirdes: but why example from RFC3164 given that this RFC was obsoleted by RFC5424? - Sandeep Roa: Yes, I will update it - Sara: There will be a call on the list to adopt the draft - Guidelines for Performing Safe Measurement on the Internet, Gurshabad Grover (10 mins) - This is draft aimed at researchers running network measurements. - When performing research on a platform, it is safe only if users are safe from the dangers - Open issues: - Safety != ethics (this draft is only documenting a subset of issue: safety. An update will add research on ethical aspects.) - Add recent research to discuss IP address - Sara: This draft has been adopted and a new author has come on board.