On Monday, October 17, 2016 at 8:33:37 PM UTC+1, David Baron wrote: > The W3C is proposing a new charter for: > > Automotive Working Group > https://lists.w3.org/Archives/Public/public-new-work/2016Oct/0003.html > https://www.w3.org/2014/automotive/charter-2016.html > > Mozilla has the opportunity to send comments or objections through > Monday, November 7. However, I hope to be able to complete the > comments by Tuesday, October 25. > > Please reply to this thread if you think there's something we should > say as part of this charter review, or if you think we should > support or oppose it. > > Note that this is a new working group. I don't know of anyone from > Mozilla being involved in the discussions that led to this charter. > > -David > > -- > đ L. David Baron http://dbaron.org/ đ > đ˘ Mozilla https://www.mozilla.org/ đ > Before I built a wall I'd ask to know > What I was walling in or walling out, > And to whom I was like to give offense. > - Robert Frost, Mending Wall (1914)
Hi, Apologies that this is a long post, but please see below for responses to questions raised on this thread. These responses (see comments within [W3C Auto] tags) have been circulated and agreed by the editors and chairs of W3C Automotive group, thanks Kev G. This seems to be a more specific instance of WoT. As such, the goals are much clearer here. While some of the concerns with the WoT charter apply (security in particular!), here are a few additional observations: [W3C Auto] Completely agree: The Automotive Group exists because there is benefit in creating an abstraction at the âvehicleâ level in order to make it easier to programme against attributes and behaviours that are common to vehicles (compared with e.g. heart rate monitors or power stations) [W3C Auto] Exposing the level of information that they claim to want to expose needs more privacy treatment than just a casual mention of the PIG. [W3C Auto] The primary purpose of the specification is to expose vehicle signals in a secure way to authenticated clients. Itâs true that a sub-set of the information could be considered to be personal (e.g. GPS location history). The specification includes an extensible access control mechanism to ensure that implementers can restrict access to suitable clients (users and/or devices and/or applications). Because the IP address of a vehicle is not known to the wider internet until after the vehicle has connected to an offboard server, only clients running on the vehicle can directly access the WebSocket server that implements the specification. As clarified by the modifications to the documents abstract, this data is intended only for local clients, such as web applications and web agents to interface e.g. to the OEMs offboard infrastructure. We have added some advice and guidance, but agree references to best practice re. personal data should be added to help ensure implementers are aware of this. [W3C Auto] Websockets? Protocol? Both of these are red flags. Protocol development is an entirely different game to APIs and the choice of websockets makes me question the judgment of the people involved. Of particular concern is how the group intends to manage interactions with SOP. Do they intend to allow the web at large to connect to parts of the car? The security architecture is worrying in its lack of detail. [W3C Auto] Could you please clarify why the use of WebSockets is a red flag. In practice, OEMs will control which signals are exposed and what access control policies are applied for specific signals. The WebSocket server is not open to direct access from the wider web (but of course agents running on the vehicle could pass data off the vehicle to any agreed endpoint) â but these agents would be subject to access control policies enforced by the implementer (OEM). [W3C Auto] If this proceeds, the naming choice (wwwivi) will have to change. It is not OK to register a new GTLD (see https://tools.ietf.org/html/rfc6761). A similar mistake was made recently in the IETF, and it was ugly. For people interested in the gory details, I can provide more details offline. [W3C Auto] The choice of the wwwivi hostname was to allow the local infrastructure to map their in-vehicle local server to a consistent end point allowing application compatibility (as an alternative to âhardcodingâ âlocalhostâ or 127.0.0.1). This allows the local network to have its own configuration whilst remaining compatible for all W3C compliant web applications and agents. We would be interested and keen to hear alternate proposals. [W3C Auto] There's fairly extensive evidence of security vulnerabilities in vehicular systems that can lead to serious safety issues (see: http://www.autosec.org/publications.html), so more than usual attention needs to be paid to security in this context. In fairness, a lot of these are implementation security issues: i.e., how to properly firewall off any network access from the CAN bus. You really need to ensure that there's no way to influence the CAN bus, which probably means some kind of very strong one-way communications guarantee. At some level these are out of scope for this group, but it's predictable that if this technology is built, people will also implement it in insecure ways, so in that respect it's very much in-scope. [W3C Auto] The Automotive Group has had a number of discussions with respect to ensuring that access to CAN signals is carefully controlled. We have previously published Architecture diagrams showing a âSecure Gatewayâ that controls all access to CAN and the group is very keen to promote security best practice. It is true that there is a risk that implementers may expose signals in an insecure way, but OEMs are already exposing an increasing number of signals and this trend is likely to continue whether or not a standard specification is created. We are keen though to keep re-iterating that CAN (and other vehicle signals) should only be accessible to suitably authorised clients and so there is an opportunity for the specification to encourage and promote best practice. This could include, for example, that if setting a safety related signal cannot be implemented in a very highly secure way, that the implementer does not allow this signal to be set. [W3C Auto] The commuications security story also seems to be not well fleshed out. The examples shown all seem to have fixed hostnames (wwwivi/localhost) which don't really seem like the basis for strong identity. It's not just enough to say, as in S 6, that the server has to have a certificate; what are the properties of that certificate? What identity does it have? [W3C Auto] The vehicle does not necessarily have to have a certificate in order to prove its identity to the offboard server. It could for example, prove knowledge of a shared symmetric vehicle-specific key. This step could occur over an encrypted SSL/TLS channel that is established based on the serverâs certificate. The specification doesnât want to force implementers [W3C Auto] This is particularly concerning: At this point, internet based clients and servers do not know the dynamic IP address that was assigned to a specific vehicle. So normally, a vehicle has to connect to a well known endpoint, generally using a URL to connect to a V2X Server. The vehicle and the internet server typically mutually authenticate and the vehicle 'registers' with the server over an encrypted channel passing it a unique identifier e.g. its Vehicle Identification Number (VIN). From that point on, the server has the IP address that is currently assigned to a vehicle with a particular VIN, and can share this information with other internet based clients and servers, which are then able to send messages to the vehicle. How does the V2X server know that this is actually my VIN? Just because I claim it over an encrypted channel. [W3C Auto] The vehicle can connect to a security authority e.g. a vehicle authentication server at a well-known endpoint, verify the serverâs identity e.g. using the serverâs certificate, set up an encrypted SSL/TLS tunnel and the vehicle can then prove its identity to the security authority e.g. using a certificate or knowledge of a shared secret (by communicating with the server over the encrypted SSL/TLS channel). Once the vehicle has confirmed its identity to the Vehicle Authentication Server, the server issues an authentication token for the vehicle to use on requests to the V2X server. The client e.g. Agent on the vehicle passes the vehicle authentication token with the VIN on any requests to the V2X server (over an encrypted channel) and the V2X server can verify that the token is valid by checking with the Security Authority (Vehicle Auth. Server) [W3C Auto] In IETF we often ask at the WG-forming stage whether we feel that the community has the expertise to take on this work. The current proposal seems to call that into question and absent some evidence that that expertise does in fact exist, I believe we shoud oppose formation. [W3C Auto] A number of Automotive Manufacturers and Tier 1 suppliers have contributed to the ideas in the specification which focusses on exposing vehicle signals and data to clients in a controlled and secure manner. W3C Automotive Group members have a very good understanding of vehicle architectures and signals and this expertise is being supplemented by security specialists within the Group, but the Group is open to contributions on how security best practice can best be incorporated and/or referenced from the spec. [W3C Auto] ________________________________________________________________________________ This sounds to me like there are sufficient reasons to formally object to this charter, and as Martin points out, a special case of IoT/WoT (with additional concerns!). [W3C Auto] Before you formally object, could we suggest having a conference call to discuss your concerns. This would also give us the opportunity to try to answer or clarify any additional questions. [W3C Auto] David, Thus I too think we should formally object, link to our previous formal objection of the WoT charter (since nearly all the same reasons apply), and list the new items that Martin and Ekr provided. I suggest we cc this response to www-archive as well. It's not clear to me that there are any changes one could plausibly adopt that would make this acceptable to us. The complaints MT and I had are just the ones of first impression. [X] opposes this Charter and requests that this group not be created [Formal Objection] (your details below). [W3C Auto] The W3C Automotive Working Group was established approx. two years ago and has published a First Public Working Draft of the Vehicle Signal Server Specification. [W3C Auto] We're concerned enough about the security and privacy aspects of this charter and the associated work that we believe this effort is not currently ready to begin development on the Recommendation track. We have a number of concerns about the security aspects of this work. It's not clear how exposing vehicle information through WebSockets will work in a secure way. Will connections to parts of the car be exposed to the Internet? If not, how will access be limited to allowed clients? How will integration with the DNS-based CA system and with the same origin policy be handled? The proposals to use fixed hostnames don't appear workable, since they don't establish unique identities for which certificates can be issued. Similarly, it's not clear how the V2X server described verifies that the connection it receives is from a vehicle with the VIN that the client claims to have. Security is critical, as security vulnerabilities in systems within cars have already led to serious safety problems; see http://www.autosec.org/publications.html . It seems that privacy needs to be a core aspect of this working group, given the level of private data involved in this space, and given deeper consideration from the beginning than a note that the working group will secure reviews from the Privacy Interest Group. It's also not OK to use a new GTLD (as this proposes using wwwivi); see https://tools.ietf.org/html/rfc6761 . These concerns are apparent after only a brief review. Given that, we believe that the best path forward in this area is for the community to take some time to consider security and privacy more carefully, and come back later with a charter that reflects that consideration. [W3C Auto] We would be very happy to understand specific criticisms of the security model and approach and to understand contributions from Mozilla (and of course others) on how this should be improved. [W3C Auto] _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
