This is an extremely important discussion! We’ve actually been struggling with this exact issue for the remote control on the TV. TLS doesn’t suit because the TV has an internal network address only (no public DNS name). We’ve been discussing how to implement the trust relationship between the remote control web page running on an arbitrary device/browser and the TV. I’m not sure that this is a good solution (I’m all ears if anyone has a suggestion)
Some (not very well structured) thoughts on your questions in line below. > On 24 Dec 2015, at 12:31 am, Michiel de Jong <mbdej...@mozilla.com> wrote: > > Connecting from a web browser to a web site is just a special case of using > "Device A", to connect to "Device B". Looking at the generic case where > Device A and Device B can both be anyThing ;) brings up a few interesting > questions: > > 1) How can a certificate authority vouch for the identity of Device B, if it > does not have a URL? Unless we replace CA's with Web-of-Trust, this might be > something to think about as more devices come into play that have no URL. Even with a URL, on an internal network CAs are of limited use (works for enterprise when you can pre-install a CA, but not in the general case). But how this “web-of-trust’ would work, I’m not sure. Exchange of CA via some side-channel? Or maybe exchange WebRTC SDP and then you can use dataConnection to securely communicate - but that doesn’t doesn’t solve the problem of secure code delivery in the first place. Another option might be to leverage an external trusted source to broker the initial communication (https://trustedapp.marketplace.firefox.com) but then both devices need access to the internet. > > 2) The user might have Device B in their eye sight. Does that help? > > If Device B can be many more things than just a web server in a data center, > then you may be able to connect to it with more accuracy. For instance, by > sticking a USB cable in it, touching it with your NFC reader, or pointing a > camera at it. Definitely! There is much prior art for local-area identification and authentication. Of the top of my head (and a quick search on the web) I can think of: - exchange of pin codes (e.g. bluetooth pairing) - physical proximity (NFC, or use physical sensors, e.g. bluetooth signal strength, or physical “bumps”) - Visual data encoding (e.g QR codes, or https://www.youtube.com/watch?v=sVWlQNzU4Ak <https://www.youtube.com/watch?v=sVWlQNzU4Ak> ) - (Ultra)Sonic data encoding ( e.g. https://github.com/borismus/sonicnet.js <https://github.com/borismus/sonicnet.js>) It might be interesting to consider a standard approach for exchanging authentication information (i’d be surprised if there wasn’t any standards in this space actually) > 3) How can you accurately connect to a device if you have no URL, and also no > physical proximity? > > I'm not talking about how to protect Device B from unauthorized access (WPS > buttons on WiFi routers etc.). What interests me is how you as a user can > accurately identify the device you are connecting *to*. I don’t think you can, at least automatically unless there is some prior web-of-trust. It depends what you mean by ‘no physical proximity’ too. Do you mean too far to use a side-channel like bluetooth, but still on the same LAN. Or something else? Are we even talking TCP/IP here or something completely seperate? > > Curious if anyone has more thoughts on this! :) Me too! Im afraid I’ve not seen any good solutions in this space as yet but I’ve only just started digging. > > > Cheers, > Michiel. > _______________________________________________ > dev-fxos mailing list > dev-fxos@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-fxos
_______________________________________________ dev-fxos mailing list dev-fxos@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-fxos
