[HT-rt] HR-RT Review of draft-iab-marnew-report-01
Shivan <shivankaul.1993@gmail.com> Wed, 02 May 2018 17:12 UTC
Return-Path: <shivankaul.1993@gmail.com>
X-Original-To: hr-rt@ietfa.amsl.com
Delivered-To: hr-rt@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F088D124B17 for <hr-rt@ietfa.amsl.com>; Wed, 2 May 2018 10:12:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.449
X-Spam-Level:
X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nHZaSOza1LdQ for <hr-rt@ietfa.amsl.com>; Wed, 2 May 2018 10:12:13 -0700 (PDT)
Received: from mail-lf0-x233.google.com (mail-lf0-x233.google.com [IPv6:2a00:1450:4010:c07::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9875F126B7E for <hr-rt@irtf.org>; Wed, 2 May 2018 10:12:09 -0700 (PDT)
Received: by mail-lf0-x233.google.com with SMTP id b23-v6so21951782lfg.4 for <hr-rt@irtf.org>; Wed, 02 May 2018 10:12:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=TtF8/WrXYcXH3//tNlrx5j7gK2AGXTgY/XuIepungOY=; b=efOB2lO1s6NWG4UI4OybIzaUhzk1lEJDDSKSw+//W0hjGErNlE2Lxuia53SyiIO3nf XoJ9fghUqywWN3CbnGbyrbvp3x5WDJKFqorYRjJkbeLrwbud/YfpcSUXF9A6ZXW9fD6h kv1YvYMNMqqQ2piqZFia5yu/ltfptlWE0nZyI/vfgByZi/ioB/t0+8MythgBiar1WPJB mvOv/cktNIULX5xsm5sPkEXpJsCHXvU3dAKcS8qS4yswbGtAt40BryC4WXreihyc7/nK ILvDD6L05wPDPT6p3U/3DtLFmrObGyD2HR8fR2IVgGI+oEvUoTY2zlQU/p4WPnZS9dvw TrrA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=TtF8/WrXYcXH3//tNlrx5j7gK2AGXTgY/XuIepungOY=; b=toVhaWHtsKEGtHtSCUIpQ1OfK0BhtwxkBUd4/g/cjJ25MQTK+/IaXvCWQvhStxmcoF 9JU76rXwduLtb2YTu9k+HclWBHevz/mDfEfSd1rW1iENSlyrLtDBpBzAhQUOoHQ/5kWb 0m1lqND3I3RcfzDE2cpQ2ZYdYFeOpbvyw2hsv1Zl1zvFHb+BDd7/9CXmuWqHmCufSpzx 7LcaAAMZ4YlESNRAsrQ7HPqlTMue9mjpzJx6YpJWNr1pa3AlUb6bgS7tWuJU0EAuueGS ++APNft8KM7p92e7eWNa9GzNoqCuPuCNPOoIxsi92rHPTC5wKJX2QIdxI4LL1i5zKzb0 f76g==
X-Gm-Message-State: ALQs6tCDwtf6z9b+VjRFnxg7wN1VICHYhFE+4taclKbUPXgi/HLcuBQr hcLaDhx3OzT3GalU4V5Btf+csH/ZsCL2tItfq0iFJw==
X-Google-Smtp-Source: AB8JxZq0aIB0AT1nJJ3iqQYcqWEh25DUMukr8cVWeTpfKxXIFhG3npcD5EOJY5sdeZB0Ddtfn9G2E2qxT9macUCC0cw=
X-Received: by 2002:a2e:9c44:: with SMTP id t4-v6mr1716414ljj.86.1525281127053; Wed, 02 May 2018 10:12:07 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.46.144.3 with HTTP; Wed, 2 May 2018 10:11:26 -0700 (PDT)
From: Shivan <shivankaul.1993@gmail.com>
Date: Wed, 02 May 2018 13:11:26 -0400
Message-ID: <CAG3f7Mgd3yArxLsGdMS6-Ki2GqemtKhTLeHXrD8mqEMnV7CXLg@mail.gmail.com>
To: hr-rt@irtf.org, architecture-discuss@ietf.org, iab@iab.org
Content-Type: multipart/alternative; boundary="000000000000c2c064056b3c2f77"
Archived-At: <https://mailarchive.ietf.org/arch/msg/hr-rt/byJOPkEXzGlHcYISVEQfk_zkbug>
Subject: [HT-rt] HR-RT Review of draft-iab-marnew-report-01
X-BeenThere: hr-rt@irtf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Human Rights Protocol Considerations Review Team <hr-rt.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/hr-rt>, <mailto:hr-rt-request@irtf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/hr-rt/>
List-Post: <mailto:hr-rt@irtf.org>
List-Help: <mailto:hr-rt-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/hr-rt>, <mailto:hr-rt-request@irtf.org?subject=subscribe>
X-List-Received-Date: Wed, 02 May 2018 17:12:17 -0000
This is a review done within the framework of the Human Rights Review Team. It was done by Amelia Andersdotter and Shivan Kaul Sahib. The Human Rights Review Team aims to implement and improve the guidelines for human rights considerations provided in RFC8280, and seek to mitigate potentially adverse human rights impacts that IETF and IRTF documents might have. We find the topics addressed during the workshop interesting and look forward to following future developments. --- Document: draft-iab-marnew-report-01 <https://datatracker.ietf.org/doc/draft-iab-marnew-report/> https://datatracker.ietf.org/doc/draft-iab-marnew-report/ Review: The Human Rights in Protocols Research Group welcomes the draft report from the MaRNEW workshop. In particular, we welcome the efforts to continue advancing an encrypted, secure and human rights enabling environment, as well as solid assessments of the potential impacts of considered remedies to mobile network operator difficulties on the right to privacy of an individual. In this regard, we wish to remind the drafters and the IAB of the inherent connection between privacy and freedom of expression. The right to privacy, or to one's own personhood, reinforces the freedom of expression and freedom of opinion. Semantic Suggestions =========================== The following sections addresses a few semantic problems in the draft report, that were they solved the draft report would be easier to parse from both a human rights perspective, and from a business, legal or technical perspective. 1. Abstract, para 2: Problem: Draft text contains value judgements on participants' presentations that could be avoided. Solution: Remove the word "honest" in relation to CDN presentations, since it may cause readers to assume that other presenters were less forthcoming. The new paragraph would read The group discussed the current Internet encryption trends and deployment issues identified within the IETF, and the privacy needs of users which should be adhered. Solutions designed around sharing data from the network to the endpoints and vice versa were then discussed as well as analysing whether the current issues experienced on the transport layer are also playing a role here. Content providers and CDNs gave their views of delivering content with mobile network operators. Finally, technical responses to regulation was discussed to help the regulated industries relay the issues of impossible to implement or bad-for-privacy technologies back to regulators. 2. Section 1, Introduction: Problem: It is unclear whether the "requirements" referred to imply regulatory requirements enforceable by government authorities, or technical requirements. Because of the nature of issues discussed during the workshop, understanding what sorts of "requirements" are being referred to is imperative. Solution: Specify the nature of the requirements being referred to, or remove the reference to requirements. The new Introduction would read Mobile networks have a set of properties which places a large emphasis on sophisticated bandwidth optimization. Encryption is increasing on the Internet which is positive for consumer and business privacy and security. Many existing mobile bandwidth optimization solutions primarily operate on non-encrypted communications; this can lead to performance issues being amplified on mobile networks. Encryption on networks will continue to increase; and with this understanding the workshop aimed to understand how we can solve the issues of bandwidth optimization and performance on radio networks in this encrypted world. 3. Section 1.1: Problem: The first paragraph mixes business models with technical necessities. The last paragraph in the section Understanding "Bandwidth Optimization" refers to regulatory requirements (within the meaning of government enforced requirements or legal requirements, cf above) on mobile network operators to perform traffic filtering and monitoring. Solution: It may facilitate understanding of human rights impacts to separate technical considerations from business considerations and legal considerations. Paragraph 3 ("Many of these functions can continue...") could be put as the last paragraph, while Paragraph 1 could be split into a technical section and a business model section, followed by a legal section. For the purposes of this workshop, bandwidth optimization encompasses a variety of technical topics related to traffic engineering, prioritisation, optimisation and efficiency enhancements. It also encompasses user-related topics such as specific subscription or billing models, and may touch upon regulatory aspects or other issues relating to regulatory, within the meaning of government initiated, concerns. The first category of bandwidth optimization includes: o Caching o Prioritisation of interactive traffic over background traffic o Per-user bandwidth limit The second category of bandwidth optimization may depend on either of the first category optimization strategies, but may, in particular, also encompass: o Business-related topics such as content delivery arrangements with specific content providers. Finally, while not strictly speaking traffic management, some networks employ policy-based filtering (e.g., requested parental controls) and many networks support some form of legal interception functionality per applicable laws. Many of these functions can continue as they're performed today, even with more encryption. Others are using methods which inspect parts of the communication that are encrypted, and these will have to be done differently in an encrypted Internet. 4. Section 4: Problem: QUIC is an active area of work for the IETF in the transport layer - this section barely mentions it, and even then does so vaguely. What problems are solved by QUIC that are general problems rather than TCP problems? What was the nature of the disagreement around this? Solution: More detail about how QUIC fits into transport-layer work would make this section more relevant. In addition, there has been discussion involving network operators around technical details that have potential privacy impacts within the QUIC working group (SPIN bit); this section would benefit greatly from an examination of that. Human Rights Considerations =========================== Upon consideration of the draft report, no implications for internationalization ([RFC8280], sec. 6.2.5), heterogeneity support ([RFC8280], sec. 6.2.8), accessibility ([RFC8280], sec. 6.2.11) or localization ([RFC8280], sec. 6.2.12) have been found. We will further suppose that issues relating to Anonymity ([RFC8280], sec. 6.2.9), Pseudonymity ([RFC8280], sec. 6.2.10) and Confidentiality ([RFC8280], sec. 6.2.16) have been sufficiently addressed in the draft as is. In the below text, Security ([RFC8280], sec. 6.2.4), Integrity ([RFC8280], sec. 6.2.16) and Authenticity ([RFC8280], sec. 6.2.17) are further considered to have been addressed, or as in progress of being addressed by the specific endeavours pointed out in the report. As such, this assessment hopes to serve as a complement to remaining Human Rights Considerations Guidelines which were not addressed by the MaRNEW draft. ## Privacy ([RFC8280], sec. 6.2.2) We laud the general emphasis on considering user privacy concerns paramount [Section 2.1.1, 2.3 etc]. In Section 3.1.1, para 1, it would be useful to emphasize that middleboxes that are "authenticated and invoked explicitly" might not be very effective at conserving user privacy if they lead to auto-click through. In practice, "opted-in" middleboxes might not be much better than transparent middleboxes. Additionally, this poses the danger of making matters worse if users assume that because they haven't been asked for middlebox permission, they are not going through a middlebox. For users accessing the Internet on a browser client: if the connection is MITMed by a middlebox, the browser would somehow need to convey this effectively and actionably to the user. Whatever effort is expended on this should involve browser vendors. ## Connectivity ([RFC8280], sec. 6.2.1) It is a priori obvious that a discussion with mobile network operators would touch upon connectivity. As a general comment, the HRPC RG is not concerned that encrypted internet traffic could create topological problems in network deployment with respect to density of base stations. It is more sensible to imagine that the density of base stations is kept low by deployers to save money on infrastructure roll-out. In the MarNEW draft report, middleboxes are brought up frequently as an example of infrastructure rendered less useful by the ubiquitous adoption of encryption. Middleboxes may enhance access to content for individuals, and may also interfere with their ability to enjoy content free of surveillance, censorship or content manipulation. The focus of the workshop of exploring ways in which encrypted materials can benefit from the same speed of deliverance as un-encrypted materials is therefore welcome. ## Content Agnosticism Traffic prioritisation, whether based on technical or commercial grounds, risks interfering with an individual's right to freedom of expression or opinion, by restricting access or enjoy content of their own choosing. As such, prioritisation should be made explicit and obvious, and subject to consent from the individual, whether the motivations for deployment are commercial or technical. It is clear that internet filtering and blocking of content of specific types, whether motivated by network management or regulatory concerns, does not fulfill a content agnosticism criterion. It is the observation of HRPC that [RFC7725] (An HTTP Status Code to Report Legal Obstacles) may assist communication of specific filtering and blocking operations in action. It the the impetus of the Human Rights Guidelines in RFC8280 that content agnosticism be respected by protocols developed in the IETF, and in general an accepted view in the global human rights community that content agnosticism is desirable at all levels of technical infrastructure. As such, the HRPC RG is concerned about ideas that traffic be classified through additional headers or metadata, identifying traffic via 5-tuples, trust models and frameworks, or heuristics.
- [HT-rt] HR-RT Review of draft-iab-marnew-report-01 Shivan
- Re: [HT-rt] [arch-d] HR-RT Review of draft-iab-ma… Spencer Dawkins at IETF
- Re: [HT-rt] [arch-d] HR-RT Review of draft-iab-ma… Shivan
- Re: [HT-rt] [arch-d] HR-RT Review of draft-iab-ma… Spencer Dawkins at IETF