Hi Paul, Thanks for your detailed reply!
On Mon, Dec 28, 2015 at 4:11 AM, Paul Theriault <ptheria...@mozilla.com> wrote: > 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 ) > - (Ultra)Sonic data encoding ( e.g. > https://github.com/borismus/sonicnet.js) > Can pin codes by themselves provide protection against man-in-the-middle attacks? Or would you have to combine them with some form of asymmetric crypto then? Cheers, Michiel. > > 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
