RE: Attempting to achieve consensus re. wwwivi issue (#223)

Hello all,

>>Do you mean that the director approved to resolve "<some_fixed_hostname>.w3.org" to 127.0.0.1? 
Sorry I'm a bit confused, if above question is true, do we gain anything by specifying hostname? My understanding was that hostname should be an convenience service for clients using the VIS server, so if the idea is to resolve for example vis.w3.org to localhost then we are actually limiting this service to clients on the same system any other clients residing on other nodes in the local(or external) network needs to use other mean of resolving the server address, or am I missing something here?

Regarding certificates I basically agree with Gunnar's comment, that it will be implementation specific and should be left to the implementers to solve.

Kind regards
Magnus

-----Original Message-----
From: Gunnar Andersson [mailto:gandersson@genivi.org] 
Sent: den 3 november 2017 12:47
To: Mark Nottingham; ju-hashimoto@kddi.com
Cc: ted@w3.org; Gavigan, Kevin; Peter Winzell; Streif, Rudolf; Adam Crofts; Lovene Bhatia; Magnus Gunnarsson; Mike Aro; Shinjiro Urata; public-automotive
Subject: Re: Attempting to achieve consensus re. wwwivi issue (#223)


Hi everyone,

On Fri, 2017-11-03 at 11:54 +1100, Mark Nottingham wrote:
> If HTTPS is a requirement, sharing a single TLS certificate amongst 
> all implementations and deployments is not going to fly. That's not 
> just bad practice, it WILL get exploited and lots of press -- the bad kind.
> 
> You really need a Web API for DNS-SD,

O_o ? :-)

> or you need to bootstrap with DNS-SD outside the Web client. 

Yes.  If I understand what you mean by bootstrap in this case :-)

Either way, keep it outside...  I feel the rest is speculation about doing way too much in the "Web space".  I think we should keep most networking issues should be outside of the VISS specification.  To me, trying to cover all bases here is suboptimal and likely worse than what might come out of a simple solution - even though it may increase complexity somewhat on the server side.

What I mean is that a simple solution in the defined HTTP and Websocket APIs, might cause a little bit of extra work on network setup and local services implementation but I find it likely there are product-specific things needed there that we will miss anyway.

As an extreme scenario, maybe in some systems you even need a local HTTP/Websocket-proxying process which responds on the <staticname> resolved IP address.  It deals with special complexities and acts as intermediary to the actual vehicle signals server.  Even if *THAT* is the case I would say, so be it, rather than putting more complexity in the client-server interface.  (I only bring up the proxy as a scenario, not likely to be the normal case.)

Either way, the interface required from the VISS server is defined, and thus the client knows what to expect.  I feel quite confident that implementations can deal with the special cases.

> That will still leave you with the problem of getting a certificate 
> issued for it, but there are various ways to do that, as long as each 
> device has a unique identity.
> 
> 

Continuing comments on the previous email as well:

> 
> > On 2 Nov 2017, at 6:00 am, ju-hashimoto@kddi.com wrote:
> > 
> > Hi Ted,
> > 
> > Do you mean that the director approved to resolve 
> > "<some_fixed_hostname>.w3.org" to 127.0.0.1? If so, that sounds fine 
> > for now. There are few ways to include https/wss into a local system 
> > without using a self-signed certificate, which may be blocked by TAG.
> > 
> > We need some kind of compromise. If using Let's encrypt, anyone can 
> > obtain an authentic certificate for <some_fixed_hostname>.w3.org.

Hmm... I thought at minimum Let's Encrypt will contact the server's IP through a DNS lookup of the domain as part of the process to ensure that you at least control the server at that IP - and if that is not a possible method I imagined they had other verification methods to ensure ownership of the domain?  Even if this is likely not necessary for the goal of this discussion, if you could elaborate - it would be interesting.

Note, I am not claiming anything about the ultimate security of the Let's Encrypt verification process here - just wondering about how anyone could do it.  I'm also not saying Let's Encrypt has an appropriate solution for this embedded use case - the protocol that contacts the server over the Internet during the setup is hardly appropriate.  I leave that unanswered mostly since I imagine certificate provisioning is not in scope for the completion of the specification anyway.

But I'd like to make this argument:  If the specification is going to cover every aspect of setting up HTTPS securely, it also requires a whole lot more than this discussion.  Just a quick reference to what the GENIVI Security Team has been very good at educating about in their recent training sessions
- about TLS/SSL downgrade attacks and other ways to fall into MITM
territory.   Covering all your bases here is a complete science in and of
itself, so it's probably not a discussion to be had uniquely for VISS.

> > So the certificate for the domain is useless to authenticate the 
> > VISS provider. But it still keeps communication channel secure and 
> > allows us to mix vehicle information with resources from external origins.

I think your arguments are correct, but again I imagine it is implementation dependent whether a particular system requires confidentiality, full authentication, or otherwise.  Some may rely on a public infrastructure and known root certificates, others on OEM-specific roots, etc.

> > 
> > "<some_fixed_hostname>.w3.org" does not support (1)multiple VISS in 
> > a network

Agree, but I don't see that we have discussed *any* solution that has particularly useful solution either (or let me know?)  I think, if you do service discovery, you get multiple answers - and I think that makes it no better in terms how to know which is the actual "<some_fixed_hostname>"
instance you actually want to talk to?

A predefined name also *does* support multiple servers, in some sense - only that those then simply need to have: <some-other-name>, and their own static
mapping.   ;-), but I'm partly serious here...

> > or (2)access from in-car smartphone/tablet from the spec. 

That might also be true but also here I don't see clear alternatives that
*would* support it in a good way.

But taking the bait, would it still be possible as follows?  Assume that your smartphone connects to the network over DHCP and is then informed about the DNS server to use.  That is provided by the network the car is offering here so presumably then lookup of <some_fixed_hostname>.viss.w3.org will yield the right IP address to contact within this network.  (If that was not the use case you intended, please clarify).

Again... I fear it's a giant rabbit hole to start discussing all the aspects of the existing and standard Internet protocols, and that it hampers the release of the specification.  Let's keep the specification at the Application protocol level, and (IMHO) define either a single recommended FQDN for the closest "default" VISS server, and/or possibly define a naming convention for custom made names: e.g.  <choose-anything>.viss.w3.org

If anyone needs more or different, they simply implement that uniquely - it falls outside of the specification scope.

> > However it won't be a obstacle for them as well. I believe other 
> > specs will realize these use cases.

My view as well.  In conclusion I think we might have rough consensus.

Is it time to write down the poll options yet?  We'll then know if there's consensus...

Hope this helps,
- Gunnar

--
Gunnar Andersson <gandersson@genivi.org> Development Lead GENIVI Alliance


> > Regards,
> > Junichi Hashimoto
>

Received on Friday, 3 November 2017 12:28:08 UTC