PING @ IETF 92 - informal chairs summary

PING – informal chairs summary – 27 March 2015 – f-2-f @ IETF 92

Special thanks to Juan-Carlos Zuniga, Mark Nottingham, Gigi Mandyam and Kepeng Li for taking the time out of their busy IETF schedules to lead our discussion on link-layer privacy, securing the Web, Geolocation and privacy requirements for a mobile app health service.

* Brief overview of the IEEE 802 Executive Committee Privacy Recommendation Study Group and the WiFi Privacy Experiment @ IETF 92 (Juan-Carlos Zuniga)

The IEEE 802 Executive Committee Privacy Recommendation Study Group has been continuing the work post-STRINT on improving privacy in the link layer. The objective is to produce recommended practices. There are some clear privacy issues such as tracking based on WiFi enabled devices broadcasting MAC addresses. The SG has had some discussion on how to solve this issue (e.g. local addresses vs. globally unique addresses, randomizing MAC addresses). This led to the idea of the experiment that was conducted at IETF 91 in Hawaii. In that trial, there was only a small number of participants so they did not observe any address collisions. The SG ran another experiment two weeks ago at the IEEE plenary. At IETF 92, the experiment is being run again, but this time, not as a separate network. If all goes well, the plan is to run this at every IETF. No major issues were detected by there are some interesting findings in draft-huitema-dhc-anonymity-profile-01.txt regarding DHCP and MAC addresses that are worth examining more closely. IEEE is considering refering to and/or endorsing recent documents from the IAB Privacy and Security Program, such as the IAB Statement on Internet Confidentiality and the new document - Confidentiality in the Face of Pervasive Surveillance: A Threat Model and Problem Statement draft-iab-privsec-confidentiality-threat-04, which is currently being drafted.

For more information see IETF Journal March 2015 [1]. There may be a further article in an upcoming edition of the Internet Protocol Journal with more detailed technical results.

Christian Huitema raised two WiFi use cases that might prove problematic for MAC address randomisation – paid hotel WiFi access and enterprises.

* W3C TAG finding “Securing the Web” [2] and Requirements for Powerful Features [3] (Mark Nottingham)

The W3C TAG has published “Securing the Web”. This is intended to be a corresponding statement for the Web to the Internet Architecture Board (IAB) statement on Internet Confidentiality [4], essentially how to transition from HTTP to HTTPS. The document identifies further areas for work or research. It is also a vehicle for the W3C to say that specifications should actively prefer secure mode. As to end-to-end encryption, the finding also states “The end-to-end nature of TLS encryption must not be compromised on the Web, in order to preserve trust”.

“Powerful features” was pre-existing work – there has been a lot of pushback in the Web Applications Security Working Group on the basis that securing powerful features is a good objective, but the way the draft approaches the issue is not very helpful. We now use the term “privileged context” rather than “powerful features” and set out the requirements. However, it is up to each Working Group to identify when there is a need for a secure context.

Wendy Seltzer highlighted that HTTPS does not solve all privacy considerations associated with privileged contexts, but that HTTPS provides some assurance that the site is the source.

Mark observed that the Web platform is getting more powerful over time with deeper access to user data and data about the user’s interactions on the Web. It is, therefore, even more important that the user knows the site they are interacting with -> the reason for strong authentication, acknowledging all the flaws of TLS and the certificate ecosystem.

There is no guidance in the draft on persisting permissions, but there is a work item on permissions in the Web Applications Security Working Group. This topic will also be discussed at an Extensible Web Summit [5] on 20 April 2015.

Wendy Seltzer noted that the WebRTC WG had a discussion yesterday about persistent permissions, and decided to leave it up to the browser vendor.

She also noted that a Trust and Permissions Community Group [6] has been created.

* Deprecating support for insecure origins for Geolocation and Proposed Edited Recommendation Geolocation API Specification [7] (Giri Mandyam)

There are several APIs developed by W3C that could be privacy compromising. For example, some of the media capture task force APIs could supposedly be used for tracking. There are also claims about the potential abuse of powerful APIs. However, there are also people who are advocating for allowing non-trusted origins, saying “Geolocation did it”. 

Giri was not involved when the Geolocation API was developed. He was appointed chair of the WG in 2014. When he took on the role, he looked at whether the W3C could sunset support for unauthenticated origins for geolocation (i.e. web pages not delivered over a trusted connection (e.g. TLS)). As chair, he issued open call in November [8], after discussion at the W3C TPAC asking whether browser vendors would be interested in “sun-setting” unauthenticated origins. He also asked those who do recommend sun-setting to provide a little more substantive support.

The Geolocation WG received some thoughtful comments from Martin Thompson advising that the W3C should not use normative specifications to force trusted origins [9]. Then the Chromium team sent a note that they were going to sunset (including geolocation) [10], but the other vendors have not responded to the call. Overarching guidance from the TAG would be helpful.

Current status – It is difficult to get official positions out of the browser vendors: can’t say consensus has been achieved re sunset. The result is this issue will not be able to be addressed in normative specifications.

=> A intro to a privacy issue/requirement from Alibaba (Kepeng Li)

Kepeng was looking for some guidance [11] on requirements for “using an application (web or native) running on the mobile device, user reports his personal health information to the hospital through mobile health platform, and wants to get advice from the doctor in the hospital” [12].

PING does not produce specifications so Kepeng was pointed to other WGs within W3C and other groups outside that may be able to offer some guidance.

There was some discussion about the proposed use of SMS for verification, and other solutions that would be available.

Wendy also mentioned that the W3C is working with FIDO on secure authentication – the discussion is happening in the Web Security Interest Group, chartering for a new WG.

* Local IP address disclosure – WebRTC

Joe Hall reported a discussion with Ekr – apparently, there is nothing they can really do because that is the way it works – if the local IP addresses are eliminated, the peer-to-peer protocol will not work. Query whether something could be added to “gate” the protocol unless there is a “door-hanger”, but the problem seems to be that the Javascript knows before the UI is activated

Christian queried whether the exchange could be done among peers without disclosure to the server (as was done in SIP).

Wendy added that there is the additional concern that the local IP addresses would be disclosed even when a user wasn’t trying to engage in a WebRTC conversation.

Joe noted that there are two current implementations. In Chrome, the user can set hidden preference to turn off WebRTC, but not in Firefox. 

Christine and Tara

[1] http://www.internetsociety.org/publications/ietf-journal-march-2015/wifi-privacy-trials-ietf-91-and-ietf-92 
[2] http://www.w3.org/2001/tag/doc/web-https

[3] http://www.w3.org/TR/powerful-features/

[4] https://www.iab.org/2014/11/14/iab-statement-on-internet-confidentiality/ 
[5] http://lanyrd.com/2015/extwebsummit/ 
[6] https://www.w3.org/community/trustperms/ 
[7] http://www.w3.org/2008/geolocation/PER-geolocation-API/

[8] https://lists.w3.org/Archives/Public/public-geolocation/2014Nov/0007.html 
[9] https://lists.w3.org/Archives/Public/public-geolocation/2014Nov/0008.html 
[10] https://lists.w3.org/Archives/Public/public-geolocation/2015Feb/0001.html 
[11] https://lists.w3.org/Archives/Public/public-privacy/2015JanMar/0127.html 
[12] https://www.w3.org/wiki/Privacy/Privacy_and_verification_use_case

Received on Saturday, 11 April 2015 09:03:53 UTC