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 11:47:29 UTC