Subject: Re: [MLS] Use Cases for avoiding Forward Secrecy

From: Dave Cridland <[email-masked]>
Date: Thu, 1 Mar 2018 09:28:38 +0000

On 1 March 2018 at 00:06, Stephen Farrell <[email-masked]> wrote:
>
> Hiya,
>
> On 28/02/18 22:56, Dave Cridland wrote:
>> On 28 February 2018 at 21:16, Stephen Farrell <[email-masked]> wrote:
>>>
>>> Hiya,
>>>
>>> On 28/02/18 17:14, Dave Cridland wrote:
>>>> Given the latter, for example, I could not use an MLS-based system to
>>>> discuss a tax problem with the authority, and since I'm unlikely to
>>>> have a SAKKE-based messaging client, I'm unlikely to have encrypted
>>>> messaging to my tax authority at all - which seems signficantly worse
>>>> than merely having no Forward Secrecy.
>>>
>>> Sorry, why is transport layer security not sufficient between you
>>> and your tax authority?
>>>
>>
>> Because it's not a single hop.
>>
>> Supposing my tax authority uses XMPP, for example, and so has (in my
>> case) hmrc.gov.uk as an XMPP domain. I use some commercialish XMPP
>> provider. I don't want my provider to be able to read my tax messages,
>> nor do I want them archived in plaintext on the server (although I
>> probably do want a verifiable record). Meanwhile, HMRC wants to keep
>> an archived, but secured, copy at their end, viewable by their
>> organisation.
>
> I see no evidence that revenue.ie would ever prefer to handle
> tax information via any intermediary when they have the option
> to provide a URL to a tax payer or their agent.

In the specific case of tax, no - or at least not yet. But the notion
of saying that we want to encourage a plethora of random messaging
tools delivered over the web while preventing a single interoperable
platform doesn't appeal to me at all.

Currently, however, there is the Secure Chorus consortium who are
looking at SAKKE-based IBE over XMPP (they already do this for voice
via MIKEY SAKKE) for offline-escrow based text messaging along
government supply chains and within blue light. That's very much a
real concept.

SAKKE is absolutely useless for consumer-grade communications, of
course - just as FS is entirely incompatible with the security goals
for these markets.

What I'd like to explore - rather than discard out of hand - is
whether a framework can be used to negotiate between consumer-grade
and government/enterprise/etc.

> But perhaps you
> do have a convincing use-case along those lines. If so, then I'd
> say describing that, rather than asking to back off from forward
> secrecy, might be a better approach at this stage (even if your
> concern is really with the FS aspects of current MLS proposals).
>
>>
>>> I'm unclear as to why the security guarantees (aimed for) between
>>> groups of people ought be reduced in order to meet the goals of
>>> securing communications between a person and a service provider.
>>>
>>
>> I'm not suggesting they should be.
>
> FWIW, that's how I read your message. Apologies if I misread it.
>
>>
>> I am suggesting that it might be nice if my options were not simply FS or FO.
>
> FO?
>

The O stands for Off, if that helps. Perhaps "FS or FA" might be more
apropos? :-)

>>
>> (Besides which, the archives in a non-FS situation gain some security
>> guarantees, too).
>
> Again, specifics there would be useful. I can't evaluate the
> sentence above.
>

Archives in a non-FS situation can maintain integrity and
authentication. In principle, archived FS messages provide this, but
since they cannot be decrypted, the value of these properties is
questionable at best.

>>
>>> I do agree that it'd be good if a user of some application could
>>> add a new device and still see old messages, but I'm not at all
>>> clear that's that significant (for the crypto) since people will
>>> always need to have some kind of fallback to handle cases where
>>> they've lost state.
>>
>> Assume a FS-only message transfer. In that case, how do we recover
>> missing messages?
>
> I've no idea. But MLS isn't aiming to provide interoperable messaging
> (sadly but understandably IMO), so that seem a tad out of scope, as
> ekr pointed out.
>

That's lovely, but I am intending on writing a specification on MLS
over XMPP, and so have some actual practical concerns (and no freedom
to just write a complete IM protocol from scratch even if I wanted
to).

>> We have to transport those from another device that
>> has them. That's a perfectly reasonable concept, and one that has been
>> tried before in Skype. Unfortunately, as mobile devices replaced
>> desktop/laptop combinations as the dominant device, they switched away
>> from the design back to centrally-held archives since the clever
>> synchronisation options simply didn't work.
>
> I'm fine if MLS is only usable by some subset of interpersonal
> messaging applications myself, even if the precise delineation of
> the set of applications that can use MLS isn't precisely known.
> (So long as there are a useful set of applications that can use
> MLS.)
>

So you're happy for the protocol to be useful only in theory.

I'm rather more concerned with practise.

I have an existing, widely-deployed, messaging protocol. It's used by
consumers, government, military, finance, and so on. I would love to
be able to provide the best security I can to the widest possible
subset of those markets.

I'm not fine if MLS is only usable by consumers. It will annoy me if
MLS also degrades user experience to the point where users just turn
it off, too.

>>
>> Of course, there are users who prefer the trade-off of higher security
>> and no (or limited) archives. Such users would, one hopes, be warned
>> about the change in security should they enter into a conversation
>> with someone who cannot (or will not) support FS.
>
> I don't think such subtle differences are at all desirable myself.
>
> Cheers,
> S.
>
>>
>> Dave.
>>

---

From: Dave Cridland <[email-masked]>
Date: Thu, 1 Mar 2018 09:35:33 +0000

On 28 February 2018 at 23:41, Dennis Jackson <[email-masked]> wrote:
> The discussion on PFS has been done to death, both on the TLS mailing
> list and in numerous other places and I would hate to see us repeat it
> for little gain. In the end, TLS 1.3 mandates that PFS be used in
> every connection. I find it hard to imagine that MLS will aspire
> to a weaker security goal than TLS, but as you say, it is for the
> group to decide.

FWIW, I'm assuming that communication security will always have FS.
That's highly desirable in all the markets I work in, although some
don't use TLS to provide it.

So I assume that MLS operates over links secured by TLS (or equivalent).

However, when your protocol is being used to, for example, coordinate
blue light, or MEDEVAC, or whatever, then the integrity of the
archived communications turns out to be quite important.

Dave.

---

From: Russ Housley <[email-masked]>
Date: Thu, 1 Mar 2018 10:11:23 -0500

> Generally, I think the right answer to these, however, isn't to modify the messaging protocol but rather to add that functionality on the messaging app over the top. That also is a much easier way to do new device history sync

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.

Russ

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 1 Mar 2018 11:34:31 -0500

On Thu, Mar 1, 2018 at 10:11 AM, Russ Housley <[email-masked]> wrote:

>
> Generally, I think the right answer to these, however, isn't to modify the
> messaging protocol but rather to add that functionality on the messaging
> app over the top. That also is a much easier way to do new device history
> sync
>
>
> 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.
>
> Russ
>

​It is a valid approach and it might be the right approach.
​
​But what we have right now is a rather complex proposal that may or may
not be correct and may or may not be addressing the real requirements and
may or may not be addressing them in the most straightforward fashion.

So far I have seen a lot of defensive responses and one individual whose
behavior was bullying. Now the fact that I cannot be bullied out of my
opinions does not make ​the experience of people making personal attacks
any more pleasant for me.

More importantly, I am concerned that what has been more or less explicitly
stated is 'we have our proposal and if you don't like it then bog off'.

I don't think that language encourages honest debate about the limitations
of the proposal or identifying the flaws.

I would much rather the IETF endorse no proposal than one that only
navigates the process because a group of bullies shouted down anyone who
was critical of it. We saw that happen with DANE we saw it happen with
CBOR. CBOR does work but the consequence of shutting down the voices saying
that we needed a binary format that precisely matches the semantics of JSON
is that we had to spin up a separate COSE working group to repeat the work
of JOSE rather than simply apply the encoding.

The assumption of most here is that the requirements are easy and the
cryptography is hard. That is precisely the wrong way round. If we really
understand what the requirements are, the cryptography follows almost
directly. It is getting to the understanding of the requirements that is
the hard part.

---

From: Jon Millican <[email-masked]>
Date: Thu, 1 Mar 2018 16:59:57 +0000

If the question is about whether MLS should support forward secrecy in the first place, I think consumer E2E messaging applications provide a good use case for this. The threat model that we tend to take here is that the user has limited trust in the service provider. In this situation, the security properties provided by TLS are almost moot, as TLS only protects you as far as the service provider anyway.

Ephemerality is a very common property in such apps, with the explicit goal that messages not be accessible after a certain period. Even without ephemerality, I believe that most messaging support message deletion. In such situations, forward secrecy is very desirable, as it ensures that if keys or any device state do leak at any moment (be it from an exploit, somebody imaging a device, or a temporary bug in the app itself), users’ old messages can at least remain secret, even if the provider had retained all of their ciphertexts. This also leads to a similar case for Post-Compromise Security, in that secrecy can be recovered even after any sort of key leakage: although in this case the argument applies even when no messages are ever deleted.

On 01/03/2018, 16:35, "MLS on behalf of Phillip Hallam-Baker" <[email-masked]<mailto:[email-masked]> on behalf of [email-masked]<mailto:[email-masked]>> wrote:

On Thu, Mar 1, 2018 at 10:11 AM, Russ Housley <[email-masked]<mailto:[email-masked]>> wrote:

Russ

​It is a valid approach and it might be the right approach.
​
​But what we have right now is a rather complex proposal that may or may not be correct and may or may not be addressing the real requirements and may or may not be addressing them in the most straightforward fashion.

So far I have seen a lot of defensive responses and one individual whose behavior was bullying. Now the fact that I cannot be bullied out of my opinions does not make ​the experience of people making personal attacks any more pleasant for me.

More importantly, I am concerned that what has been more or less explicitly stated is 'we have our proposal and if you don't like it then bog off'.

I don't think that language encourages honest debate about the limitations of the proposal or identifying the flaws.

I would much rather the IETF endorse no proposal than one that only navigates the process because a group of bullies shouted down anyone who was critical of it. We saw that happen with DANE we saw it happen with CBOR. CBOR does work but the consequence of shutting down the voices saying that we needed a binary format that precisely matches the semantics of JSON is that we had to spin up a separate COSE working group to repeat the work of JOSE rather than simply apply the encoding.

The assumption of most here is that the requirements are easy and the cryptography is hard. That is precisely the wrong way round. If we really understand what the requirements are, the cryptography follows almost directly. It is getting to the understanding of the requirements that is the hard part.

---

From: Sean Turner <[email-masked]>
Date: Thu, 1 Mar 2018 12:06:08 -0500

Jon thanks for bringing us back on topic.

spt

> On Mar 1, 2018, at 11:59, Jon Millican <[email-masked]> wrote:
> 
> On 01/03/2018, 16:35, "MLS on behalf of Phillip Hallam-Baker" <[email-masked] on behalf [email-masked]> wrote:
>  
> _______________________________________________
> MLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mls

---

From: Dave Cridland <[email-masked]>
Date: Fri, 2 Mar 2018 09:45:57 +0000

On 1 March 2018 at 16:59, Jon Millican <[email-masked]> wrote:
> If the question is about whether MLS should support forward secrecy in the
> first place, I think consumer E2E messaging applications provide a good use
> case for this. The threat model that we tend to take here is that the user
> has limited trust in the service provider. In this situation, the security
> properties provided by TLS are almost moot, as TLS only protects you as far
> as the service provider anyway.

Well, I think TLS is important too - it's usually protecting metadata
from third parties to a reasonable degree.

> Ephemerality is a very common property in such apps, with the explicit goal
> that messages not be accessible after a certain period. Even without
> ephemerality, I believe that most messaging support message deletion. In
> such situations, forward secrecy is very desirable, as it ensures that if
> keys or any device state do leak at any moment (be it from an exploit,
> somebody imaging a device, or a temporary bug in the app itself), users’ old
> messages can at least remain secret, even if the provider had retained all
> of their ciphertexts. This also leads to a similar case for Post-Compromise
> Security, in that secrecy can be recovered even after any sort of key
> leakage: although in this case the argument applies even when no messages
> are ever deleted.

And yes, I totally agree with everything you've said here, which can
be summarised as "FS is important in consumer-grade messaging".

But:

* A verifiable record is more-or-less mandated by Government.
* A verifiable record is generally relied upon by consumer service companies.
* A (non-verifiable) record is used in most enterprise messaging
applications, and many consumer grade.
* Consumers sometimes talk to consumer service companies and Governments.

Again, I'd make it clear I am not arguing that Forward Secrecy should
never be available - I'm arguing that in some cases it may not be an
acceptable option, and in such cases if the options are between
non-viable (but good) security and no security at all, then people
will simply choose another option (like a bespoke messaging platform
for enterprise/consumer).

That feels like a missed opportunity.

Dave.

---

From: Dave Cridland <[email-masked]>
Date: Fri, 2 Mar 2018 09:51:00 +0000

On 1 March 2018 at 15:11, Russ Housley <[email-masked]> 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?

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.

---

From: "Katriel Cohn-Gordon" <[email-masked]>
Date: Fri, 02 Mar 2018 10:08:25 +0000

> no longer be authenticated, doesn't it?

Do e.g. governments require that the archive consist of the actual encrypted messages that were transmitted over the wire? As opposed to having a trusted party, perhaps a "recorder" group member, re-encrypt them for archival.

---

From: Dave Cridland <[email-masked]>
Date: Fri, 2 Mar 2018 10:55:15 +0000

> Do e.g. governments require that the archive consist of the actual encrypted messages that were transmitted over the wire? As opposed to having a trusted party, perhaps a "recorder" group member, r…

Pass.

Currently the NCSC won't accredit any solution not based around
MIKEY-SAKKE for OFFICIAL and up, but - rather like MLS, actually - we
have a bunch of security outcomes but no indication of what drove the
decision, or indeed what's important.

Dave.

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 2 Mar 2018 06:51:08 -0800

On Fri, Mar 2, 2018 at 1:51 AM, Dave Cridland <[email-masked]> wrote:

> email

Not if they are digitally signed, which is an explicit option in the
current drafts.

-Ekr

---

From: Nadim Kobeissi <[email-masked]>
Date: Fri, 02 Mar 2018 19:14:59 +0100

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

---

From: Dave Cridland <[email-masked]>
Date: Fri, 2 Mar 2018 20:27:02 +0000

> 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 Cri…

After various side-discussions, I'm comfortable that we can address
the demands of enterprise and government cases within MLS - as long as
we keep a half-eye on it.

> 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-S…

To be absolutely clear, I'm not a big fan of SAKKE and I think it's
entirely unsuitable for the consumer in any form. Consumers generally
benefit from FS, and SAKKE's mandatory escrow is just plain wrong in
that setting.

The properties that interest me within MIKEY-SAKKE are the possibility
of a secure archive with offline escrow, and I think we can do that
within MLS after discussion.

I actually think this is a fairly well-understood requirement, and as
such it'd be useful to document it somewhere in the charter.

Dave.

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 2 Mar 2018 21:04:08 +0000

Hiya,

> benefit from FS, and SAKKE's mandatory escrow is just plain wrong in

I agree with you about mikke-sakke and mandatory key escrow in general.
(As does the IETF, in RFC 1984/BCP 200.)

As a non-nit: I'd much prefer we consider people and not "consumers,"
but no need to go there as part of this thread - I know what you meant
when saying "consumer" above and it's ok in context. However, I do hope
work on MLS does not assume the existence of a major "mothership" - if
it did, then that'd be bad IMO, regardless of whether a mothership is
an employer, government or commercial service provider. (Allowing for
the existence of such entities is ok IMO, requiring them is not.)

> such it'd be useful to document it somewhere in the charter.

Fair enough. The potential that archives can be kept is reasonable,
even if the putative MLS-wg/RFCs mightn't specify an interoperable
way to do that.

Cheers,
S.

---

From: Dave Cridland <[email-masked]>
Date: Fri, 2 Mar 2018 21:18:28 +0000

On 2 March 2018 at 21:04, Stephen Farrell <[email-masked]> wrote:
> when saying "consumer" above and it's ok in context.

I'm using that term quite deliberately, I'm afraid.

"Consumers" are not the same as "People" - People act in roles, and
one such role is as a consumer. Happy to use whatever terms you like,
but not conflicting ones. "People", in general, might find a legally
recognisable record of their communications quite useful at times.

> However, I do hope

Right, totally agree.

I think it's relatively simple to ensure that a person cannot have a
"mothership", as you put it, imposed upon them without their
knowledge, and I think that's an entirely sane goal. (In fact, I think
it's met by the current drafts, which is why I'm not arguing for it).

Dave.

---

From: Nadim Kobeissi <[email-masked]>
Date: Fri, 2 Mar 2018 23:23:17 +0100

(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 <[email-masked]> wrote:
>

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 2 Mar 2018 21:09:26 -0500

On Fri, Mar 2, 2018 at 1:14 PM, Nadim Kobeissi <[email-masked]>
wrote:

> 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.
>
​​
​My point is that discussions, i.e. the application for which we might want
to use MLS very often have precisely the same security requirements as
stored documents for which it is understood FS is not​ a requirement.

> 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 has just taken you outside the scope of my statement. This is
exactly the point I am making. I can add FS to a protocol really easily,
just mix in another one time key. ​When I say 'only her knowledge of Bob's
public key' that is what I mean, not 'only her knowledge of Bob's public
key plus this other stuff'.

​So the way to avoid FS in the case that it is undesirable is to not mix in
the key in the first place. That is, FS is a security enhancement of a non
FS-protocol, not something we design in and then take away.​

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.
>

​I agree on that. And I find that quite often it is necessary to build
something to work out what it is we really want to build.​

> 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.
>

​I agree. I think that the nature of forward secrecy is different as well.
I can design a protocol that is FS to the keys of Alice and Bob but not
Carol. I can also FS different keys at different times. ​

> 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.
>

​Well only the parts that address multi party protocols and I find the
literature is often barking up the wrong tree where requirements are
concerned.​

> 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.
>

​Quite, and maybe there is an approach in which we use one set of keys to
do a key agreement for authentication purposes and a second set of keys for
a FS mix-in.​