<div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div class="gmail_default" style="font-size:small">I have been rethinking the notion of perfect forward secrecy and not just because it is never actually perfect. In fact I think we ended up confusing ourselves because of how we came on the problem.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">The first time I saw PFS being discussed was in the design of IPSEC and we ended up with the idea that to make the connection PFS, we periodically generate a new DH key, authenticate it under the primary shared secret and perform a new key exchange which is then used to key the channel.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">So what is the problem? Well first off as the Signal folk pointed out, throwing away the shared context from the primary key exchange when we rekey is a doofus move. And especially so when our cipher suites are RSA2048 and DH512. Instead of strengthening the key exchange, the ephemeral weakened it massively (thanks BULLRUN)</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">So whenever we rekey, we are always going to make sure that we at least preserve the security of the primary context, if appropriate, we may also chain from one ephemeral output to the next.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Thus if we have a primary shared secret P and ephemerals E1, E2, we are either going to use</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">s1 = KDF(P+E1), s2 = KDF(P+E2) ... sn = KDF(P+En)</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">or </div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">s1 = KDF(P+E1), s2 = KDF(P + s1+E2) ... sn = KDF(P+ sn-1 + En)<br></div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">The other subtler problem is that we are looking at perfect forward secrecy as a property of the channel rather than being relative to a credential. And the reason I think this matters is that the IETF MLS working group might well be solving the wrong problem.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">So lets take the case where Alice and Bob decide they want to have a mutually authenticated, bilateral conversation. If we want mutual authentication, each is going to have to issue a challenge to the other. Simplest way to do that is in the form of an ephemeral keypair.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Let Alice, Bob credentials be {A, a}, {B, b}, ephemerals be {EA, ea} , {EB, eb}</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">P= KDF (  a.EB + ea.B } = KDF (  eb.A + b.EA }</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">And this will give us forward secrecy if and only if Alice throws away ea AND Bob throws away eb.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">It is the throwing away of the credential that gives us the forward secrecy. If Alice or Bob keeps track of either their ephemerals or P,, the session can be decrypted.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">So what ea is actually doing for Alice is to protect against the risk that Bob's secret b is disclosed. And eb is protecting against disclosure of a.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Forward secrecy is a property relative to a credential and not to a channel.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Reason I got into this was that I was looking at the problem of a client establishing a connection to a host with the possibility of a DoS attack. I want to minimize the number of round trips. But I also want to turn on crypto as fast as possible.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">So that got me thinking, what if the host were to use the same ephemeral for multiple inbound connections? My initial idea was to then do an immediate rekey. But as I come to implement, that seems unnecessary.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">So lets imagine that the host generates a new ephemeral keypair every hour. This is used for an hour and thrown away at the end. This does open up a window of possible compromise of the host ephemeral but this is irrelevant if the host is maintaining the session. </div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Getting back to the problem of encrypted chat groups. The big problem I have with MLS and their trees is that there are two problems in a group chat, confidentiality and authentication. I don't see MLS helping with either.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Yes, decentralized, peer to peer, yadda yadda. Problem is that every decentralized system I have ever seen deployed successfully in the real world has ended up relying on central brokers (MIT key server, Mt Gox, Quadriga, ICANN, Tether...) And what ends up happening is that instead of accepting the fact that there is a coordination point and mitigating the risks with controls, the issue is swept under the carpet and we get security by ARGUMENT IN ALL CAPS.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Confidentiality is a break once run anywhere problem no matter how you dice it. If any participant in the channel keeps a record or discloses, the channel is breached.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">I can't see any value in Alice or Bob knowing that the shared secret they are using was constructed using data they helped provide because the only thing they ultimately care about is that P might be disclosed to a third party. There is no point in controlling against Alice constructing a malicious input into the derivation of P if she can publish P on her Twitter feed.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">The only possible way MLS could help is if it reduced the probability of an implementation error leading to disclosure. I can't really comment on that because MLS is a bit too complicated for me to tell if that is the case or not.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Authentication is the problem of telling if the @alice in the channel run by @carol is the real @alice. And that has two parts:</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">1) How does @carol know it is the real @alice speaking?</div><div class="gmail_default" style="font-size:small">2) How does @bob and everyone else know this?</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">The first is fairly easy because @alice has to be let into the group at some point and they will be authenticated by whoever let them into the group. </div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">The second requires a bit of mechanism. One very simple mechanism would be @alice periodically signs what she is presenting to the channel. Possibly signing a challenge value is enough.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Problem here is that we have exactly two authentication primitives, MAC and signature. MAC is fast but relies on a shared secret and so anyone who can verify the data can forge it. Signature is slow so we can't be signing every packet but we could sign every n frames of video, maybe every frame. And the bigger problem with signature is that it lacks deniability.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">What I want to build eventually is a video chat environment in which Alice is buying a house from Bob and they are doing the closing with Carol, Doug, Edward etc. Who are realtors and the banks involved.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">I want the person who is working for Fidelity Investments to have the TTP certified Fidelity Investments logo in their window, same for all the other trusted parties. And the reason I want that is so I don't have to worry about sending a wire for half a million bucks over the telephone. </div><div class="gmail_default" style="font-size:small"><br></div></div></div></div></div></div></div>