<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, Apr 15, 2014 at 7:51 PM, Richard Newman <span dir="ltr"><<a href="mailto:rnewman@mozilla.com" target="_blank">rnewman@mozilla.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><div><div><blockquote type="cite"><div dir="ltr"><div><div><div>
<div><div><div>The challenge with this is that we want the data to be encrypted in transit from computer to device, and we also need to authenticate the computer and device to each other to protect against MitM attackers.<br>
</div></div></div></div><blockquote type="cite"><div dir="ltr"><div>1. Does this seem like a reasonable use case for Firefox Accounts?<br></div></div></blockquote></div></div></div></blockquote></div><div>To a point. It would provide you with a key that you could use for encryption and other purposes, certainly. There are some open questions, though:</div>
<div><br></div><div>1. It's the same key you'd use to protect your valuable sync data. That's not an area we've really explored (that I know of) — does it make sense to use a permanent high-value key to protect transient data? Unless you're permanently attaching a device to your identity-attached services, an account seems like the wrong model. If you <b>do</b> plan to have basically a developer portal, where devices keep themselves linked in and reachable, then maybe it would be a fit, but it seems heavyweight for what's basically a crypto layer on top of Zeroconf.</div>
</div></div></div></blockquote><div><br></div><div>Okay, that's good to know. I don't want to be the one that risks exposing a "permanent high-value key" for this use case. Also, there are no plans to build a portal to manage devices, so this suggests to me that FxA is not a good fit for this problem.<br>
</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><div><div>2. There's a service discovery problem. We don't have a discovery mechanism in place yet — your Sync server is hard-coded into the client — so this would basically require a similar fixed magic URL and Mozilla hosting for some intermediary tied to the FxA infrastructure.</div>
</div></div></div></blockquote><div><br></div><div>That does sounds like a extra level of complication, so again probably a reason to go a different route.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div style="word-wrap:break-word"><div><div><div>Two alternatives:</div><div><br></div><div>Simple: type in a PIN on both devices. This is probably an acceptable level of security for a local wifi network, no?</div></div>
</div></div></blockquote><div><br></div><div>Well, that was actually my first idea... :) I think it's harder than that though because we'd also like to support remembering the computer that connected to the device, so that on the second connection, you'd only need to press connect and don't have to copy PINs around or anything like that.<br>
<br></div><div>So, for that to work, we need to have an authentication system that provides some ID from the laptop to the devices that is not easily spoofed, so that it can be presented the second time around in a way that you can trust it's the same machine.<br>
<br></div><div>Potentially we could use a longer PIN to derive a key that can be used to sign messages... I only know enough crypto to know that designing my own system is likely a bad idea. ;) Since we do need both authentication and encryption, I was hoping to map this problem to an existing system, though surely we could do something custom here if that's the best path.<br>
<br>I may ping you outside of this thread for further thoughts. It's challenging to balance engineering effort required vs. acceptable level of trust here.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div style="word-wrap:break-word">
<div><div><div>Less simple: use the KeyExchange (J-PAKE) system that Old Sync uses. Desktop generates 12 characters, you type them on the phone, and they get a one-shot encrypted channel, via a lightweight Mozilla server, to exchange an arbitrary bundle of stuff. That seems like a perfect solution for this: it's like Bluetooth pairing, and you can send port numbers, credentials, pure-random keys, etc. over the channel.</div>
</div></div></div></blockquote></div><br></div><div class="gmail_extra">Yes, this could be helpful! I looked into this earlier on, and I was trying to understand the status of this system. Since you're moving a new Sync system based on FxA, is there infrastructure or code here that you were expecting to decommission that I might need to keep alive if I make use of this approach? (Obviously the actual Sync system is not needed, just this "lightweight" server you mentioned.)<br>
<br></div><div class="gmail_extra">Thanks,<br></div><div class="gmail_extra">Ryan<br></div></div>