Re: [MLS] Use Cases for avoiding Forward Secrecy

[Nadim Kobeissi <[e-mail]>]

(Small correction: my reference to the NAXOS AKE was off, I was misremembering its contributions and should have rechecked the paper before citing it.)

Nadim Kobeissi • Symbolic Software
https://symbolic.software
Sent from my iPad

> On 2 Mar 2018, at 7:14 PM, Nadim Kobeissi <[e-mail]> wrote:
> 
> There is a small body of contributions I have regarding this discussion thus far. They are organized below in a set of more general comments, followed by specific responses to Phillip Hallam-Baker.
> 
> A1. Moving forward, it's likely just better for us to refer to forward secrecy as forward secrecy. The "perfect" suffix, historically, largely exists for anecdotal reasons and has little to do with the actual concrete meaning to the term in reference to its security goals. "Forward secrecy" and "future secrecy" are confusing terms anyway: for one thing, they seem to refer to the same property, although they are diametrically opposed with regards to the chronological direction in which confidentiality and key freshness hold, post-compromise.
> 
> A2. As alluded to by Denis Jackson, asynchronous forward secrecy is documented by the Signal protocol. As far as I know, the earliest existing design that does this asynchronously is NAXOS [0], which I believe was cited in earlier drafts of the Signal protocol specification anyway.
> 
> A3. With regards to retention, I think EKR makes the best point in saying that these are use cases best addressed by features implemented by the client application itself. This rhymes with Dave Cridland's original mention that business users are those who most require this: business users are also those with the most tailored client applications, usually, providing ample room for archiving features that do not necessarily affect protocol security goals or expose MLS to a riskier threat model.
> 
> A4. With regards to compliance with, for example, MIKEY-SAKKE, it is worth thinking about whether the entire MLS effort remains as worthwhile were it boiled down to that common denominator. MIKEY-SAKKE (and company) are by design allergic to strong security guarantees. Phillip Hallam-Baker is correct to note that strong security guarantees are not our explicit goal here, but rather a tangential goal to securing MLS use cases to the fullest possible extent. That said, as noted by Jon Millican, any run-of-the-mill secure messaging application today, be it WhatsApp, Signal, iMessage, Facebook Messenger, Google Allo, Viber, Wire, or Threema shows an obvious preference for ephemerality and resistance to scenarios where the mobile phone, an increasingly disposable device, gets lost, stolen or traded away.
> 
> A5. As someone who's been involved in secure messaging for some  time, I can say that it's by no coincidence that Signal was designed to focus so strongly on both forward and future secrecy. The designers clearly went to great length to keep these properties, and, in implementation, modulate their resilience against an unreliable (choppy, weak) network by keeping a certain number of pre-key hash chains locally. The more hash chains are kept, the more out-of-order messages are tolerated by the wider the post-compromise window. To my knowledge, WhatsApp keeps a larger local set of hash chains than, say, Signal or Cryptocat, in order to account for its larger user base who may have a smaller tolerance for failure. As a matter of fact, Signal as an application evolved away from using pure OTR into designing and using the Signal protocol largely in order to improve upon forward secrecy specifically, adopting an asynchronous forward-secure AKE and a ratcheting scheme that handles two-party key contributivity much more quickly than OTR.
> 
> A6. I think it's doubly more important to consider adopting EKR's suggestion, discussed in (A3), to its fullest possible extent because of the negative impact that accommodating against forward secrecy may have towards enabling downgrade attacks that chip away at forward secrecy. Once this is ingrained into the protocol, we may end up having to give an active attacker much stronger  grip over when, and even if, forward secrecy ever kicks in.
> 
> Some responses to specific claims made by Phillip Hallam-Baker:
> 
> PHB Statement 1: "Alice works in a team with Bob and Carol. At some point Doug joins the team. At that point, Doug needs access to all documents and discussions related to the project."
> 
> Response 1: Especially given that this seems to potentially require expanding the MLS problem space to document access, it is definitely best to follow EKR's recommendation, as mentioned above in (A3). Not only does this provide appropriate document access irrelevant of forward secrecy guarantees of MLS, but it also segregates key retention to involve only documents that merit such retention, and from a software engineering standpoint is likely the most elegant solution anyway.
> 
> PHB Statement 2: "If Alice creates a message for Bob using only her knowledge of Bob's public key then it is not going to be PFS because a compromise of Bob's private key is a breach."
> 
> Response 2:   The consequences of the secrecy of the very first message in a Signal session, given a long-term identity compromise, are not as you describe. That is because you would also need to compromise Bob's one-time pre-key, which is erased after the AKE concludes. The consequences of both these kinds of compromise are modeled and documented by Katriel's Signal paper, as well as a contemporary paper published by our team at INRIA.
> 
> PHB Statement 3: "In general, I like to see what the requirements are before jumping to implementation."
> 
> Response 3: It is quite likely that any current implementation of MLS isn't very fruitful. Better to discuss more first, especially at the upcoming meeting at IETF 101.
> 
> PHB Statement 4: "This is a different problem to TLS because we have more than two parties and it changes matters."
> 
> Response 4: The manifestation of the problem is what is different. Not the problem itself. The problem is layer security. TLS had to implement forward secrecy in order to have a meaningful answer to that problem. In messaging, the problem of layer security is the same, but manifests itself in a different medium. Forward secrecy is in all likelihood still necessary to offer those affected by this problem the level of security they require given a reasonable threat model.
> 
> PHB Statement 5: "One of the things I only just realized is that PFS is not even a property of the protocol, it is a property of a key in the exchange and not of the exchange itself."
> 
> Response 5: Either this statement is incorrect, or all peer-reviewed publications that exist on secure messaging must be rewritten in order to formalize, model and prove forward secrecy on the level of the lifetime of a symmetric key rather than as a global property encompassing all messages of a protocol. Of course, there are different methods in which to reason about the same thing: you can see a finite field as a weird squiggly line or as a set of numbers, etc.
> 
> PHB Statement 6: "Let us say that we want FS with respect to each of the keys of Alice, Bob, Carol and Doug but ​they don't all want to inject fresh FS information at the exact same time. Let us say Alice has her key in a HSM while Bob is using a soft key, Alice is sitting in a SOC and Bob is a field agent on Moscow Rules. Bob probably wants for FS their key every ten minutes. Alice might be good for a week."
> 
> Response 6: In a protocol such as, for example, Signal, such a discrepancy can be managed by the participants without affecting the protocol's implementation logic in any way, further supporting EKR's suggestion described in (A3) and touched upon previously in the response to PHB Statement 2.
> 
> References:
> [0] https://www.microsoft.com/en-us/research/publication/stronger-security-of-authenticated-key-exchange/
> 
> Nadim Kobeissi
> Symbolic Software • https://symbolic.software
> Sent from office
> 
>> On Fri, Mar 2, 2018, at 3:51 PM, Eric Rescorla wrote:
>>> On Fri, Mar 2, 2018 at 1:51 AM, Dave Cridland <[e-mail]> wrote:
>>> 
>>>> On 1 March 2018 at 15:11, Russ Housley <[e-mail]> wrote:
>>>> This is similar to the approach used in some email environments.  The
>>> email
>>>> message is decrypted for reading, and then encrypted in a separate
>>> archive
>>>> key for storage.
>>> 
>>> Sure, but that explicitly means that messages within the archive can
>>> no longer be authenticated, doesn't it?
>>> 
>> 
>> Not if they are digitally signed, which is an explicit option in the
>> current drafts.
>> 
>> -Ekr
>> 
>> 
>> 
>> That, in turn, is a clear downgrade from the NCSC's SAKKE dictat. For
>>> all its faults, that is providing a secure archive that the enterprise
>>> has access to via an offline key escrow.
>>> 
>>> If I'm wrong here please don't hesitate to correct me.
>>> 
>>> Dave.
>>> 
>>> _______________________________________________
>>> MLS mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/mls
>>> 
>> _______________________________________________
>> MLS mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/mls