<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Wed, Mar 25, 2015 at 1:24 PM, Trevor Perrin <span dir="ltr"><<a href="mailto:trevp@trevp.net" target="_blank">trevp@trevp.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">> Well, Alice can only introduce nodes she's still connected to, so the<br>
> ephemerals couldn't have been destroyed yet.<br>
<br>
</span>In general protocols destroy ephemeral DH private keys immmediately<br>
after a handshake, e.g. Noise envisioned that the parties might do<br>
one-way updating of their cipher keys as they exchange messages, so<br>
that a compromise doesn't reveal old data, but that means you have to<br>
throw the ephemeral DHs away.<br></blockquote><div><br></div><div>Ah! Right. I'm not sure why I didn't realize that. I guess this invalidates a lot of my thinking.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">> Bootstrapping trust from long-lived keys will happen at a different level.<br>
> For example, it could be that a DNS-like system returns not only an address<br>
> but also the current process key, signed by a long-term key. (Incidentally,<br>
> this means that the live process never needs to see the long-term key which<br>
> helps reduce the damage from heartbleed-type attacks.)<br>
<br>
</span>OK, I'd been assuming the "static" keys *were* the long-lived keys,<br>
but I guess things are different.  You mentioned earlier you would<br>
encourage "process lifetimes to be limited to a day or less".<br></blockquote><div><br></div><div>I'm probably being confusing because I seem to have three levels of keys (per-connection, per-process, and permanent) whereas most protocols expect only two. "Per-process" can map to "static" in the sense that it is used for multiple sessions but "ephemeral" in that it has a limited lifetime.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">It's hard to make suggestions about keys/protocols without<br>
understanding all the key management, there's just a lot of ways to<br>
slice these problems, and everything interacts.<br>
<br>
But if it's true that processes have "static" keys of a day or less,<br>
you could possibly get by with just Nacl-style boxes (BoxSS), where<br>
you encrypt directly based on static-static DH keys, and live with<br>
forward-secrecy windows of < day (due to static key replacement).<br></blockquote><div><br></div><div>Thanks, that was my feeling.</div><div><br></div><div>Though now I am thinking of some other ideas...</div><div><br></div><div>When Alice introduces Bob to Carol, Alice could generate a random symmetric key sent to both parties. Bob and Carol would use this key as an additional seed for their PRF chains.</div><div><br></div><div>Now, to decrypt a recorded conversation between Bob and Carol, you would need not only to compromise one of their private keys, but also to compromise this introduction key, which requires compromising the conversation with Alice. In fact, it seems like you don't necessarily even need a DH exchange here at all, because as stated earlier if Alice is the only introducer between Bob and Carol, we actually consider it acceptable for Alice to MITM the session. Once there is a second introducer, the second introduction key will be factored in, and now the two introducers would have to be in collusion to decrypt the conversation (which, again, we don't consider a threat).</div><div><br></div><div>But this seems entirely too simple and obvious to actually work. :) I must be missing something.</div><div><br></div><div>Even if it does work, I would probably keep DH on top of this for defense in depth, but the addition of the introduction key seems to mean that merely compromising a process's private key gets you nothing on its own.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Forward-secrecy, and particularly "perfect" forward secrecy, is sort<br>
of a misnomer.  There's not a binary property here, there's just a<br>
relationship between key lifetimes and how much data is exposed if the<br>
key is compromised.<br>
<br>
So the more-quickly you destroy keys for old data the better, but that<br>
has to be balanced against other concerns.<br></blockquote><div><br></div><div>Yeah, I think I'm more looking for opinions than facts here. :)</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Anyways, one factor I haven't brought up - and that dkg did a good job<br>
bringing up on TLS list recently - is that 0-RTT depends on recipients<br>
maintaining state (whitelists or blacklists) to prevent replays of<br>
initial messages.<br>
<br>
I don't know how big an issue that would be in your system.  If you<br>
don't want to deal with that state-management, and the risks it brings<br>
(performance, DoS, losing the state) then accepting a 1-RTT protocol<br>
may be easier.<br></blockquote><div><br></div><div>Indeed. State management is relatively easy in my case because we're talking about processes, so state can be kept in RAM. If the state table gets too large, kill the process and start a new one.</div><div><br></div><div>Then again, the introduction key thing might help here too. If the process somehow lost its state while keeping its private key, a replay attack would not work because it would be using an introduction key that the receiver doesn't recognize. (But again, this seems too easy so I must be missing something.)</div><div><br></div><div>-Kenton</div></div></div></div>