<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Dec 17, 2014 at 1:11 PM, Ryan Kelly <span dir="ltr"><<a href="mailto:rfkelly@mozilla.com" target="_blank">rfkelly@mozilla.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="">On 18/12/2014 04:24, jr conlin wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
On face, it looks reasonable. I'd introduce a bit of extra nonce to the<br>
key generation sequence (otherwise it's conceivable that the master<br>
could be derived from enough samples as well as it being possible to<br>
predict keys).<br>
</blockquote>
<br></span>
HKDF *should* be sufficient protection here.<br>
<br>
Importantly, we need the derived keys to be stable - if the same relier does the OAuth dance with the same user, it should get the same kAr and kBr.  So this limits the amount of salting/noncing we can do.<span class=""><br></span></blockquote><div><br>Noncing (in the sense of a random thing generated fresh each interaction) is out, since all clients need to agree on all parameters every time they approach an interaction.  But we can salt (in the sense of a random thing generated once for each user) a little, since the content server and oauth backend have an open channel.  It's not clear why that would be interesting, since the key being fed into HKDF is already supposed to be strong, and the choice of parameter is arbitrary (and all are assumed to be strong).  But we could do it.<br><br>Nick<br></div></div><br></div></div>