**Session Date/Time:** 21 Mar 2022 12:00

# pearg

## Summary

The pearg session at IETF 113 featured three presentations: one on the effectiveness of QUIC padding against website fingerprinting, another on GDPR and its relationship with IP addresses, and a progress update on the "Survey of Worldwide Censorship Techniques" draft. Discussions covered the technical challenges and overheads of privacy defenses, legal interpretations of personal data in network contexts, and the ongoing effort to document censorship methods in a rapidly evolving landscape.

## Key Discussion Points

### 1. Effectiveness of QUIC Padding Against Website Fingerprinting (Sandra Sidney)

*   **Website Fingerprinting (WF)**: Adversaries can identify visited webpages over encrypted QUIC connections using traffic metadata (packet sizes, directionality), even with measures like ECH/encrypted DNS. Prior work showed WF on QUIC is as effective as on TCP.
*   **QUIC RFC Padding**: The QUIC RFC suggests padding frames for traffic analysis protection. This presentation explored its effectiveness.
*   **Adversarial Model**: A distributed adversary (multiple vantage points, centralized AS analysis) aims to identify web pages hosted on a single IP.
*   **Experimental Setup**: Used a dataset of 150 QUIC-dominant web pages (70% QUIC traffic average). An undefended baseline achieved a 96% F-score in identifying pages.
*   **Key Features for WF**: Initial attacks relied heavily on size-based features (packet counts of specific sizes, total incoming/outgoing bytes). Once these were hidden, directionality-based features became primary.
*   **Network Layer Defenses**:
    *   **Padding individual packets / Hiding total traffic size**: Showed only minor F-score reduction (e.g., 2% for individual packets, still 92% after hiding total size).
    *   **Injecting random dummies (to hide directionality)**: Reduced F-score by ~16% (worst case) but incurred 100% overhead, not including other padding.
    *   **Conclusion**: Network layer defenses offer low protection with high cost (>50% overhead for a 10% F-score reduction). This is largely due to the lack of application layer information for efficient padding strategies.
*   **Constrained Adversaries**:
    *   **Limited View**: Only a few large ASes can observe a significant proportion of traffic. Google resources (present on >80% of pages) provided a strong, low-cost fingerprint (up to 77.9% F-score just from timing to Google resources).
    *   **Limited Processing (e.g., sampled NetFlow)**: Lower sampling rates significantly reduced WF performance, with more gains from sampling itself than from padding.
*   **Application Layer Defenses**:
    *   **Page Structure**: High prevalence of third-party resources (especially Google, >50% on 24% of pages) complicates application-layer defenses due to the need for multi-party cooperation.
    *   **Effectiveness**: Packet/size padding remained ineffective (adversary used ordering). Injecting 5 dummies at the application layer reduced F-score by 39% with relatively lower cost than network layer dummies.
    *   **Complexity**: Application-layer dummy injection (sending requests for dummy resources) introduces deployment challenges and potential client experience impacts.
*   **Overall Conclusion**: Efficient network layer defenses require application layer information. Application layer defenses introduce complexity in coordination, development, and client experience.
*   **Q&A**:
    *   Discussion on malware detection: Network traffic analysis is effective; malware would need high-cost dummy injection to evade.
    *   Threat model clarification: The study used clean traces (single webpage load, no caching). Future work will explore subpages, cached resources, and background traffic for a more realistic assessment.

### 2. GDPR and Network Privacy (Luigi)

*   **Context**: GDPR (EU General Data Protection Regulation) came into effect in 2018, replacing older data protection laws. It defines strict rules for personal data.
*   **Key Terminology**:
    *   **Personal Data**: Any information relating to an identified or identifiable natural person. This explicitly includes "online identifiers," with IP addresses specifically ruled as personal identification data by the European Court of Justice.
    *   **Controller**: The entity that determines the purposes and means of processing personal data (e.g., an ISP).
    *   **Processor**: The entity that processes personal data on behalf of the controller.
    *   **Processing**: Any operation performed on personal data.
*   **Seven Principles of GDPR (with network layer implications)**:
    1.  **Lawfulness, Fairness, Transparency**: Data must be processed lawfully, fairly, and transparently, usually requiring explicit consent.
    2.  **Purpose Limitation**: Data collected for specified, explicit, and legitimate purposes (e.g., ISP uses IP for billing, not for tracking shopping).
    3.  **Data Minimization**: Collect only data necessary for the service (e.g., ISP access to IP/transport headers, but not packet content).
    4.  **Accuracy**: Data must be accurate and up to date.
    5.  **Storage Limitation**: Data should not be kept longer than necessary, with a "right to be forgotten" (must be balanced with law enforcement logging requirements).
    6.  **Security, Integrity, Confidentiality**: Data must be protected against unauthorized or unlawful processing and accidental loss, destruction, or damage.
    7.  **Accountability**: The controller is responsible for compliance, even if processing is outsourced to a third-party processor.
*   **Global Context**: Many other countries (e.g., Brazil, Japan, Canada) have similar privacy laws, though with legal nuances (e.g., Japan covers anonymized data, Canada allows passive consent). GDPR emphasizes *explicit* consent.
*   **IETF Relevance**: Noted that principles in RFC 6973 on privacy considerations align with GDPR principles.
*   **Q&A**:
    *   Discussion on new protocols (e.g., MASQUE, Oblivious DNS): While these enhance privacy, GDPR compliance still requires considering data flow, processing location, and logging for accountability.

### 3. Update on Survey of Worldwide Censorship Techniques Draft (Mallory)

*   **Context**: This long-standing research group document (started Nov 2014) aims to survey global censorship techniques. Mallory is now stewarding the document.
*   **Challenges**: Censorship is a contentious and rapidly evolving topic. The goal is to publish a "good enough" snapshot and then consider how to maintain it as a living document.
*   **Current Status**: The draft (now v5) has undergone one research group last call. The aim is to move to another last call soon.
*   **Recent Changes**: Scaled back the self-censorship section, added more on domain seizure, and included blocking of TLS 1.3 extensions as an example of evolving techniques.
*   **Draft Structure**: Organized into four main parts: defining what to block, detecting what to block, actions to block, and network layering.
*   **Open GitHub Issues**:
    *   Issue 81 (TLS identification): Feedback received, needs incorporation.
    *   An issue for incorporating a relevant report.
    *   Issue 64 (TLS): Requires review from the original opener on current changes.
*   **Proposed Dropped Issues**: Mallory recommended dropping two issues:
    *   Introducing "sensor maturity": Deemed not to add significant value and potentially subject to frequent changes.
    *   Changing "trade-off" terminology to "cost to implement": Considered redundant and unnecessary word-smithing.
*   **Related Work**: A new "IP blocking" (ietf-113, 00) draft is being presented at IETF 113, which has some overlap and new content relevant to this area, particularly in response to recent geopolitical events. Mallory encouraged its authors to share it with the pearg list.

## Decisions and Action Items

*   **Decision**: Mallory proposed dropping two open GitHub issues from the "Survey of Worldwide Censorship Techniques" draft: "sensor maturity" and changing "trade-off" to "cost to implement." No objections were raised.
*   **Action Item (Mallory)**: Incorporate feedback for Issue 81, a relevant report, and obtain review for Issue 64 into the "Survey of Worldwide Censorship Techniques" draft.
*   **Action Item (Mallory & Chairs)**: Discuss offline a provisional date for the next research group last call for the "Survey of Worldwide Censorship Techniques" draft.
*   **Action Item (Mallory)**: Encourage the authors of the new "IP blocking" draft (ietf-113, 00) to send it to the pearg mailing list for wider awareness and input.

## Next Steps

*   The "Survey of Worldwide Censorship Techniques" draft will be updated based on the remaining open issues and will proceed towards a second Research Group Last Call.
*   Further research on website fingerprinting defenses will broaden its scope to include more realistic scenarios such as subpages, cached resources, and background traffic.
*   Ongoing discussions within the IETF are expected regarding the privacy implications of new protocols like MASQUE and Oblivious DNS, particularly in light of regulations like GDPR.