So, first, it's not clear to me which option to check in the review. I think the basis of these comments is somewhere between:
[X] suggests changes to this Charter, and only supports the
proposal if the changes are adopted [Formal Objection] (your
details below).
and:
[ ] opposes this Charter and requests that this group not be
created [Formal Objection] (your details below).
I'm inclined to check the first one given that I think our objection
is not about whether the group should be created at all, but whether
it's ready to be created right now given the current charter and
preparation.
(Martin, it might help if you elaborate a little bit about your
concern about Websockets, since I'm not particularly familiar with
their security model. Is your concern about something specific to
the security model in websockets, or to the other things it ties
into?)
In any case, here's an attempt to coalesce mt's and ekr's feedback
into comments on the charter (though I suspect it may be useful to
quote that feedback as well to provide further detail).
(Sorry for taking longer to get to this than I had hoped; at this
point the deadline for comments is end of Monday, US Eastern Time.)
-David
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 .
On Friday 2016-10-21 15:16 -0700, Tantek รelik wrote:
> Ekr,
>
> 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!).
>
> 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.
>
> Thanks,
>
> Tantek
>
>
>
> On Tue, Oct 18, 2016 at 3:10 AM, Eric Rescorla <e...@rtfm.com> wrote:
> > I share Martin's concerns here...
> >
> > 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.
> >
> > 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?
> >
> > 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.
> >
> > 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.
> >
> > -Ekr
> >
> >
> > On Mon, Oct 17, 2016 at 5:11 PM, Martin Thomson <m...@mozilla.com> wrote:
> >
> >> 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:
> >>
> >> Exposing the level of information that they claim to want to expose
> >> needs more privacy treatment than just a casual mention of the PIG.
> >>
> >> 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.
> >>
> >> 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.
> >>
> >> On Tue, Oct 18, 2016 at 6:32 AM, L. David Baron <dba...@dbaron.org> 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)
signature.asc
Description: PGP signature
_______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
