<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Adding Francois.<br>
<br>
<div class="moz-cite-prefix">On 8/22/16 2:43 PM, Richard Newman
wrote:<br>
</div>
<blockquote
cite="mid:CAOjG3JD7K2FXuXjEhc-FWA9qJkOpeqYU_B0rmRJQ9PxVXpj3OQ@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">
<div style="word-wrap:break-word">
<div>
<ul>
<li>Can Sync encryption be re-engineered so that
data survives a reset?</li>
<li>If yes, what UX changes would be required
besides copy changes?</li>
</ul>
</div>
</div>
</blockquote>
<div><br>
</div>
<div>In theory, yes, in two ways.</div>
<div><br>
</div>
<div>To clarify: the issue with Sync is not that data is
lost, it's that without kB it's inaccessible.</div>
<div><br>
</div>
<div>FxA exposes two encryption keys: kA and kB. kA is
preserved across password resets. kB is not.</div>
<div><br>
</div>
<div>The obvious option is to use kA instead of kB. We
decided not to do this for Sync 1.5, because it was a big
change.</div>
<div>
<div><br class="">
Simply using kA is probably not a good idea: IIRC it
means Mozilla or an attacker would transparently have
the ongoing ability to decrypt your data, no matter what
you did. It cuts in some painful ways across the
assumptions users have about passwords — that changing
their password preserves their data, yes, but also that
it will exclude an attacker in some way. That's only
true in some respects if we used kA.</div>
<div><br>
</div>
<div>Using kA would be a relatively small change to each
deployed Sync client, but it would be a breaking change,
locking out older clients.</div>
</div>
<div><br>
</div>
<div>Another option is to build a key escrow service,
similar to the one Apple hosts for FileVault encryption
keys.</div>
<div><br>
</div>
<div>A key escrow service would instead wrap a copy of kB
with additional crypto — print-and-save keys, a long
series of questions:</div>
<div><br>
</div>
<div>
<div class="" title="Page 9">
<div class=""> </div>
</div>
<img src="cid:part1.37413605.3DA70454@mozilla.com"
height="480" width="562"></div>
<div><br>
</div>
<div>This makes the process explicit, and doesn't touch core
crypto; this is an addition with a hook into recovery.</div>
<div><br>
</div>
<div>FileVault is a great example: it's exactly the same as
Sync. Crypto wrapping a pile of data that might or might
not be valuable, might or might not be sensitive, and
users care about a lot.<br>
<br>
</div>
<div> </div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">
<div style="word-wrap:break-word">
<div>
<ul>
<li>If it can’t be, is their consensus among users
about which datatypes should be by default
encrypted (e.g. passwords) and unencypted (e.g.
bookmarks)?</li>
</ul>
</div>
</div>
</blockquote>
<div><br>
</div>
<div>There's risk here.</div>
<div><br>
</div>
<div>For instance, if I can write to your add-ons but not
read your passwords, I can remotely execute code on your
machine. If you're a doctor, your browsing history is
likely HIPAA-sensitive. Your bookmarks might contain
credentials.</div>
<div><br>
</div>
<div>Similarly, from a value perspective, some users don't
care at all about saving passwords, but their history or
bookmarks or form history is very important.</div>
<div><br>
</div>
<div>That it's difficult to say "this data is sensitive" or
"this data is not" is one reason why we didn't use kA in
the end.</div>
<div><br>
</div>
<div>I suspect it's impossible to make generalizations here…</div>
<div> </div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">
<div style="word-wrap:break-word">
<div>
<ul>
<li>If there’s not consensus, would users prefer to
choose what’s encrypted?</li>
</ul>
</div>
</div>
</blockquote>
<div><br>
</div>
<div>… and, furthermore, I think it's not a good choice for
users to make potentially months or years before the
decision affects them. Do you want safety or freedom?
Both!</div>
<div><br>
</div>
<div>My personal feeling is that if we approach data
recovery, we'll have the best chance of meeting varying
user needs if we do it through FileVault-esque key escrow,
not by using a more stable key.</div>
</div>
</div>
</div>
</blockquote>
<br>
</body>
</html>