Fwd: Web socket vs REST security

+  public-autowebplatform@w3.org

<public-autowebplatform@w3.org>[Thanks Kaz for spotting that hadn't
actually cc'd the group :-)]

Regards,

Kev

*Kevin Gavigan BSc, MSc, PhD, MCP, MCTS*
*Software Architect*
*Connected Infotainment*
*Electrical, Electronic and Software Engineering (EESE)*
Jaguar Land Rover


*Mobile: 07990 084866*
*Email:* kgavigan@jaguarlandrover.com

*Office address:*
GO03/057 • Building 523, Gaydon • Maildrop: (G03)
Jaguar Land Rover • Banbury Road • Gaydon • Warwick • CV35 0RR

---------- Forwarded message ----------
From: Gavigan, Kevin <kgavigan@jaguarlandrover.com>
Date: 15 February 2017 at 17:37
Subject: Re: Web socket vs REST security
To: "ted@w3.org" <ted@w3.org>
Cc: Paul Boyes <paul.boyes@inrix.com>, Rudolf Streif <
rstreif@jaguarlandrover.com>, Peter Winzell <peterwinzell.gbg@gmail.com>,
Kazuyuki Ashimura <ashimura@w3.org>, Lovene Bhatia <
lbhatia@jaguarlandrover.com>, 이원석 <wonsuk.lee@etri.re.kr>


Hi Ted,

Thanks very much for the feedback. As suggested have included  public-
autowebplatform@w3.org in the cc list to make discussion public.

*>> There are additional strengths and think a hybrid solution, what we
initially intended to create in the WG, may make sense for a next
generation specification after we finish this one in a few months.*

Completely agree that we (i.e the Automotive BG) should consider this and
work towards creating a new Automotive WG for the 2nd Gen Spec.

My main motivation for arguing for the existing VISS approach,  is that we
are keen that the WG should continue to progress the WebSocket based VISS
spec, primarily for the following reasons:

a) This is what was previously agreed and is in line with the very recently
updated WG charter.
b) The VISS is actually vendor agnostic and reflects the deliberations of a
number of different parties within the Working Group, distilled over the
last couple of years.
c) There isn't a clear benefit of using REST+WebSocket vs simply WebSocket
(both are perfectly valid approaches with their own pros and cons) and it
is better to publish than to delay e.g. for another year?.
d) A number of industry parties are creating reference implementations,
sales demonstrators etc based on VISS.

Although it might not have seemed that way, I'm actually a fan or REST :-)
and would suggest that the 'Representational State Transfer' ideas that Roy
Fielding proposed and are now commonplace in RESTful web services are
really quite elegant.

So imho, it will be great for the BG to discuss how REST could be used
effectively on vehicles and to look at ideas from other participants e.g.
PSA+IBM, AGL etc. It might be that the best overall approach will be to
combine the VW and/or PSA? and/or X?) REST with the ideas that have gone
into the existing VISS WebSocket approach (to support Subscriptions) (or
ideas from other WebSocket approaches) and that this becomes the basis for
the 2nd Generation spec - but it's probably a little early to finally
decide on this :-)

As for the 2nd Gen spec, believe we need also to encourage:

i) Discussion with other W3C groups e.g. TV tuner, Web Payments, WoT,
Sensors to see try to achieve consensus on accessing media content,
payments and including vehicle seamlessly in WoT via the 2nd Gen spec.
ii) Other OEMs and industry participants e.g. HERE to engage and to
consolidate the best ideas across the industry (to maximise uptake for a
future 2G standard)

Hope this is helpful, look forward to hearing other member thoughts and
comments

Kind Regards,

Kev



*Kevin Gavigan BSc, MSc, PhD, MCP, MCTS*
*Software Architect*
*Connected Infotainment*
*Electrical, Electronic and Software Engineering (EESE)*
Jaguar Land Rover


*Mobile: 07990 084866*
*Email:* kgavigan@jaguarlandrover.com

*Office address:*
GO03/057 • Building 523, Gaydon • Maildrop: (G03)
Jaguar Land Rover • Banbury Road • Gaydon • Warwick • CV35 0RR

On 15 February 2017 at 14:02, Ted Guild <ted@w3.org> wrote:

> I started this as a heads up that I might make some counter arguments
> to the conversation. As we have some substance to this discussion, with
> your permission I would like to share it with the group. If you agree
> you can simply add public-autowebplatform@w3.org to the cc in a reply
> or I can forward.
>
> On Tue, 2017-02-14 at 18:17 +0000, Gavigan, Kevin wrote:
> > Hi Ted,
> > I'm sure you will continue to remain neutral and I very much welcome
> > you adding your hard won experience re. securing REST.>
> >
> > >>  I do not think we can simply declare either more secure but
> > attack types and mitigation techniques are more known for one.
> >
> > I completely agree that this is a true statement, but logically it is
> > also true that the attack surface for REST + WebSocket may be larger
> > than just WebSocket (appreciate it might come down to how big is the
> > contribution from Set:-).
>
> I agree there are two attack surfaces from two protocols. HTTP2's
> socket capabilities (which I am not convinced yet serves our needs)
> would bring the number of protocols down to one.
>
> A core question though regarding the use of Websockets is whether it is
> best for allowing writes. My impression is their need is more for being
> able to send a steady stream of information to applications including
> potentially the dashboard. It really shines over HTTP1.1 in this
> regard, but I seriously doubt writes from applications to the
> underlying vehicle would be anywhere near the same volume. A rigidly
> read-only socket goes pretty far to secure that attack surface and
> would be free from overloading, escape characters and other games
> attackers might try. HTTP servers have a number of hardening techniques
> to closely examine requests and can give extra scrutiny to write
> requests (PUT, POST, DELETE). They had to as they are directly
> available on the web. There are various Web Application Firewalls (WAF)
> very capable of adding protection there, Apache's mod_security is one
> such example.
>
> > I updated the WiVi site to try to balance up the REST=good /
> > WebSockets='not so good' messages - as it started to seem a bit one
> > sided...
>
> Sockets are the clear winner in my opinion at being able to send large
> amounts of timely data as mentioned. There are additional strengths and
> think a hybrid solution, what we initially intended to create in the
> WG, may make sense for a next generation specification after we finish
> this one in a few months.
>
> > When you get into the details REST vs WebSockets can include some
> > quite  complex and subtle arguments, especially when you consider it
> > from a code development and maintenance perspective.
>
> Valid point.
>
> > For example, what if two vehicles from same or different
> > manufacturers have different object graph structures. WebSockets spec
> > doesn't care, and a WebSocket system could recover e.g by requesting
> > an object graph for something that exists e.g. 'body', and then
> > client searches the VOM e.g. for class=doors.
> >
> > In contrast, a truly RESTful approach would need different URLs to
> > navigate down through the different levels of the tree (collections
> > containing items, that may contain collections, that contain items
> > etc).
>
> There should be some way to solve some signal discovery provisions,
> which may be oversimplifying the problem, in REST. Alternately in a
> hybrid solution we leverage sockets strength here.
>
> > What if the model on one vehicle contains the desired item three
> > levels down and on another vehicle the structure is different and the
> > desired item is two levels down. How does the client code know to
> > keep going and/or when to stop? Or is the RESTful approach not really
> > RESTful (its really just a web service that returns an object graph
> > like WebSocket approach)?
>
> For what its worth I like the VSS data tree and having it be able to
> evolve separately from the specs. We are going to see many additional
> sensors and other data being exposed by vehicles.
>
> > Main point is, we don't really understand why we are still focusing
> > so much time on REST+WebSocket vs WebSockets?
>
> This is the primary difference between them. If we can reach a high
> level agreement that a next gen should incorporate both then I agree we
> can be more efficient with our time. We can then shift on leveraging
> strengths from one or the other. The comparison work would not be
> wasted in designing the next solution.
>
> > Suggest the main focus could be:
> >
> > i) Look for areas of consensus between new approaches (WiVi, PSA etc)
> > and VISS (e.g. WebSocket implementations could be identical)
> >
> > ii) Progress VISS to Recommendation (as agreed by group and in line
> > with WG Charter) including timelines for creating Reference and Test
> > implementation (as encouraged by Hira-san)
>
> That is still the plan. VISS should proceed unhindered by these
> discussions. We are looking beyond that.
>
> > iii) Business Group and 2G-VIS: Has opportunity to try to get
> > agreement between WiVi and other domain groups e.g. TV Group, looking
> > at areas of commonality with PSA+IBM, and/or AGL and others.
> >
> > I'm sure we can spend the next weeks making some very valid points
> > for and against REST+WebSocket vs pure WebSocket approaches, but also
> > pretty sure that it's unlikely that any of us think it's the very
> > best use of our time :-)
> >
> > Keen to hear your views and those of the other Chairs and W3C reps
> > re. the above.
> >
> > Cheers,
> >
> > Kev
> >
> > Kevin Gavigan BSc, MSc, PhD, MCP, MCTS
> > Software Architect
> > Connected Infotainment
> > Electrical, Electronic and Software Engineering (EESE)
> > Jaguar Land Rover
> >
> > Mobile: 07990 084866
> > Email: kgavigan@jaguarlandrover.com
> >
> > Office address:
> > GO03/057 • Building 523, Gaydon • Maildrop: (G03)
> > Jaguar Land Rover • Banbury Road • Gaydon • Warwick • CV35 0RR
> >
> > On 14 February 2017 at 14:19, Ted Guild <ted@w3.org> wrote:
> > > Hi Kevin,
> > >
> > > I noticed you added some security considerations on the web sockets
> > > versus REST approach to the wiki, perhaps after reading that we
> > > touched
> > > briefly on that topic during the last call.
> > >
> > > You make some valid points and as someone who has been protecting
> > > HTTP
> > > servers for nearly two decades will prepare some counter arguments.
> > > Web
> > > servers have been publicly accessible and under attack all this
> > > time,
> > > quite a bit has been learned about securing them better whereas not
> > > as
> > > much is known about protecting web sockets in a hostile
> > > environment.
> > >
> > > For instance I am less concerned about a read only socket
> > > connection's
> > > security. Write methods (PUT, POST, DELETE) in HTTP can be
> > > scrutinized
> > > far more by a web server before being passed on to the underlying
> > > application layer. We have a custom protocol for setting attributes
> > > in
> > > web sockets and it has not been thoroughly vetted for possible
> > > games
> > > people may try to play with it.
> > >
> > > I am telling you this because I want to be clear I am remaining
> > > objective but have a wealth of experience in web server security,
> > > learned the hard way. I did make some counter arguments on security
> > > in
> > > Burlingame when this first came up. I do not think we can simply
> > > declare either more secure but attack types and mitigation
> > > techniques
> > > are more known for one.
> > >
> > > Cheers,
> > >
> > > --
> > > Ted Guild <ted@w3.org>
> > > W3C Systems Team
> > > http://www.w3.org
> > >
> > >
> --
> Ted Guild <ted@w3.org>
> W3C Systems Team
> http://www.w3.org
>
>