Subject: [MLS] Deniability in MLS

From: Konrad Kohbrok <[email-masked]>
Date: Mon, 7 Mar 2022 17:42:05 +0100

Hi everyone,

we discussed the possibility of achieving deniability in MLS at some 
point in the past and in my view the WG agreed to leave a potential gap 
between the signature keys in the credentials vs. the signature keys 
used to verify MLS messages. This was proposed by Sofia via email to 
this list 
(https://mailarchive.ietf.org/arch/msg/mls/FitDfKtiyB6VIq7QTmJdIxDUh-0/) 
and then via GH PR: https://github.com/mlswg/mls-protocol/pull/437, both 
of which found agreement and the PR was subsequently merged.

There was also an alternative proposal involving deniable credentials 
proposed in the same email thread. These deniable credentials would be 
part of the tree and members would provide a link to their actual 
identity for each joiner after they joined the group. The downside here 
as laid out by Chelsea and Raphael on the thread is that this leads to 
problems with asynchronicity, as newly added members can't know who the 
members are until each member has shared their identity oob in a 
deniable way.

The gap ultimately introduced in the PR mentioned above does not have 
this problem, as the new joiner can see the real credentials in the 
tree. The oob distribution of the link between the real credentials and 
the deniable signature/verification keys is only needed at a later 
point, when the newly added member wants to verify a received message.

During a discussion in the context of the AS definition in the 
architecture doc it became clear that the spec is inconsistent: There's 
the spot touched by PR 437, but there are a few other places that talk 
about message authentication using the credential signature key 
specifically (without the added layer of indirection).

I filed this PR in an attempt to make the gap more explicit and to 
remove the inconsistencies: https://github.com/mlswg/mls-protocol/pull/610.

Richard and I continued the discussion oob and it turns out that there 
is disagreement about the semantics of the change made in PR 437, i.e. 
if it in fact does introduce a gap or if it doesn't change the semantics 
of the spec at all.

The situation from my point of view is the following:

- we agreed on adding the gap/layer of indirection at some point in the 
past as evidenced by agreement on this list and the merge of PR 437
- the spec is currently inconsistent w.r.t. message authentication

So the spec needs to change in either direction: Make the gap explicit 
(which is what I attempted in PR 610), or reverse PR 437 to remove any 
ambiguity.

Since, again, I believe the gap was an explicit addition, I would 
appreciate if the WG could revisit the discussion on deniability and 
decide either to include it in the spec explicitly or to remove it 
entirely. Sorry to raise this problem so late on the road to the WG last 
call, but I think it's important that we address this issue.

Cheers,
Konrad

---

From: Mallory Knodel <[email-masked]>
Date: Mon, 7 Mar 2022 12:51:34 -0500

Top posting to show support for the inclusion of deniability in the spec 
and thanks to the contributors who have included it for discussion in 
sessions and on the list.

Deniability is something we try to define in draft-e2ee-definition, 
which I'm presenting at OpenPGP during IETF 113. I presented it to MLS a 
few meetings ago, too.

My preference on direction for the spec would be to include it in the 
spec explicitly, and satisfactorily document the gap from PR 437.

-Mallory

On 3/7/22 11:42 AM, Konrad Kohbrok wrote:

> point in the past and in my view the WG agreed to leave a potential 
> gap between the signature keys in the credentials vs. the signature 
> keys used to verify MLS messages. This was proposed by Sofia via email 
> to this list 
> and then via GH PR: https://github.com/mlswg/mls-protocol/pull/437, 
> both of which found agreement and the PR was subsequently merged.
>
> identity for each joiner after they joined the group. The downside 
> here as laid out by Chelsea and Raphael on the thread is that this 
> leads to problems with asynchronicity, as newly added members can't 
> know who the members are until each member has shared their identity 
> oob in a deniable way.
>
> tree. The oob distribution of the link between the real credentials 
> and the deniable signature/verification keys is only needed at a later 
> architecture doc it became clear that the spec is inconsistent: 
> There's the spot touched by PR 437, but there are a few other places 
> that talk about message authentication using the credential signature 
> key specifically (without the added layer of indirection).
>
> remove the inconsistencies: 
> https://github.com/mlswg/mls-protocol/pull/610.
>
> if it in fact does introduce a gap or if it doesn't change the 
> semantics of the spec at all.
>
> - we agreed on adding the gap/layer of indirection at some point in 
> the past as evidenced by agreement on this list and the merge of PR 437
> entirely. Sorry to raise this problem so late on the road to the WG 
> last call, but I think it's important that we address this issue.
>
> Cheers,
> Konrad
>
> _______________________________________________
> MLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mls

-- 
Mallory Knodel
CTO, Center for Democracy and Technology
gpg fingerprint :: E3EB 63E0 65A3 B240 BCD9 B071 0C32 A271 BD3C C780

---

From: Richard Barnes <[email-masked]>
Date: Mon, 7 Mar 2022 13:50:50 -0500

tl;dr:

- Solving deniability is not on the table
- Allowing external signature keys has significant interop costs
- ... and can be done cleanly in an extension
- So we should not do it now
- Instead we should be clear that signatures are done with keys in
credentials

The same points with more prose...

We are choosing between two alternatives here:

1. Signatures in MLS are created / verified with keys distributed in MLS
credentials
2. Signatures in MLS are created / verified with keys distributed in some
unspecified way

I'll call these "credential keys" and "external keys".

To be blunt, we are not going to define a deniable version of MLS in this
specification.  (Sorry, Mallory!)  To do that, we would need some analysis
of the form "MLS when operated in X way (or with protocol extension Y)
provides deniability property Z."  Much like the analyses we have of
confidentiality and authenticity properties.  To my knowledge, no such
analysis exists.  The best we'll be able to say is something like "You
might be able to operate MLS in such a way as to get deniability
properties, if you're clever.  But maybe not!"

So the benefits here are dubious.  What about the costs?  I agree with
Konrad that the specification is not OK as it is even if we are going to
allow signatures by external keys.  But the problem is worse than he says,
because the external keys aren't interoperable.  There's no mechanism in
the specification for the clients to agree on how signatures are verified,
so some clients might verify with credential keys and others with keys they
got from a blockchain or something, thus coming to completely different
results.  At the very least, we would need a way for the members of a group
to agree on how signatures are being done.

Conveniently, the protocol has a way for group members to agree on
behaviors, namely extensions.  If we require credential keys in the base
protocol and deniability turns out to need external keys, it would be
natural to have a GroupContextExtension that says "In this group, we don't
use credential keys, but [other thing]".

Thus, it seems like there's no justification for taking on the complexity
of external keys now.  Either it's not needed for deniability, or it can be
cleanly and more safely added in an extension.

Instead we should revise the spec to be super clear that signatures are
done with credential keys.  This establishes a clear, self-contained
baseline protocol that can be a good basis for deniability analysis.

Personally, I don't think this requires reverting #437.  I don't think I
ever understood it to allow external keys, which is probably why I let it
go in the first place.  (To be clear, I don't agree with Konrad that the WG
agreed to have "gap" ~= external keys.)  But if folks think it would be
clearer to revert, happy to do it.

--Richard

---

From: "Hale, Britta (CIV)" <[email-masked]>
Date: Mon, 7 Mar 2022 19:21:59 +0000

Konrad,

Thank you for raising this discussion and pointing out the issue. Regardless of direction on this, we should indeed be clear and unambiguous regarding how anonymity can be integrated, if supported.

TL:DR: 
- There are security considerations for each alternative and those should be contrasted. 
- It sounds like we need more explicit clarity (across PRs) for any step in MLS that we are implicitly assuming can be used for deniability, since spec interpretation should not be guesswork. Let's avoid hinting at deniability integration points and either allow or disallow it.

Zooming out on the issue (vs. PR-specific), it seems that the WG has more or less considered two cases for achieving anonymity. To summarize the authenticity chain from what you have pointed out, we have the following choices. Arrows indicate a chain of authentication and each 'disconnecting step for anonymity' is prepended and appended by forward slashes:

-------------------------------------
1. User Alice --> MLS group: [MLS identity for Alice  --> // anonymous credential for message signing, C // --> messages signed under C]
Here the MLS identity is known, so a joiner can verify parties upon joining the group. 
The MLS identity is linked to the user.
Messages are signed by an anonymous credential.
The types of anonymous credentials that can be supported are restricted, e.g. it must constitute keys for signing, vs some other attestation of identity.

This allows deniability on the message, but not on the user identity. It also implies a stronger guarantees for entity authenticity to joiners (avoiding honeypots, so to speak).
-------------------------------------
-------------------------------------
2. User Alice --> MLS group: [// anonymous MLS identity for Alice //  --> credential for message signing, C --> messages signed under C]
(the anonymous MLS identity may also subsume C)
Here the anonymity takes place 'at the user' in the sense that original MLS credentials must be provided OOB. 
The joiner cannot verify parties immediately on joining the group, however.

This allows for deniability on the message as well as the participating identity. It does imply weaker guarantees for entity authenticity, as there is no attestation between Alice and Alice's identity in the group, particularly when joining. 
-------------------------------------

I would strongly suggest that we avoid the ambiguity of supporting both options (or others not listed). Authenticity is hard enough to get right when also aiming for deniability, let alone the potential for someone to interweave two attempts at deniability. ***Note that each 'option' is actually a broad category of different methods - the option only addresses at which stage in the authentication chain the method for indirection is incorporated.

Furthermore, it would be best to be explicit about this in the spec. In both PRs there is open phrasing or reference to "alterative" methods, but we do not explicitly state "do something with at this step if desiring anonymity". That issue of open phrasing seems to be what lead to the various interpretations of PR 437 referenced below, and that interpretation problem will be compounded once the protocol is standardized. The point of a standard is clarity to all parties - whether something is in or out of scope. So, whether anonymity is built into MLS (option #1) or intended for support in the AS (option #2), it would be in the best interest of a clear specification to not leave that decision vague. Personally I think that both options above cover Malory's point about support for deniability.

I will give some more thought to the implications of options #1 and #2 above and respond either here or on the PR (currently the implication of an 'unspecified step' mid-protocol in option #1 seems fraught with risks). However, I wanted to capture some of the tradeoffs we are considering as a point of discussion, first, vs comparing contents of the PRs. 

PR 437 was heavily discussed in the WG in the context of that we wanted to support an option for deniability, but the precise permitted indirection option step (or combination of option steps) for anonymity, either internal to or external to the core MLS protocol (or both), was not closely looked at, and that is a decision issue that must now be addressed. 

Britta

On 3/7/22, 9:51 AM, "MLS on behalf of Mallory Knodel" <[email-masked] on behalf of [email-masked]> wrote:

    NPS WARNING: *external sender* verify before acting.

    -Mallory

    On 3/7/22 11:42 AM, Konrad Kohbrok wrote:

    > (https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailarchive.ietf.org%2Farch%2Fmsg%2Fmls%2FFitDfKtiyB6VIq7QTmJdIxDUh-0%2F&amp;data=04%7C01%7Cbritta.hale%40nps.edu%7Ce1abad08574245aea8d608da006325f0%7C6d936231a51740ea9199f7578963378e%7C0%7C0%7C637822723149799226%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=bEFnOor4AD5Vt%2Fqypi4WxWDob%2BpLUtN8H2PppEI0%2FA8%3D&amp;reserved=0)
    > and then via GH PR: https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fmlswg%2Fmls-protocol%2Fpull%2F437&amp;data=04%7C01%7Cbritta.hale%40nps.edu%7Ce1abad08574245aea8d608da006325f0%7C6d936231a51740ea9199f7578963378e%7C0%7C0%7C637822723149799226%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=Xg3sJDhTL547Z3vOdyJApNCrV4AYy%2B6WKzGyzRcNm7E%3D&amp;reserved=0,
    > https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fmlswg%2Fmls-protocol%2Fpull%2F610&amp;data=04%7C01%7Cbritta.hale%40nps.edu%7Ce1abad08574245aea8d608da006325f0%7C6d936231a51740ea9199f7578963378e%7C0%7C0%7C637822723149799226%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=c9KXeZ5R2yiD5lPyubNodaerSA2DDaE4kcaXSbOfQWQ%3D&amp;reserved=0.
    >
    > https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fmls&amp;data=04%7C01%7Cbritta.hale%40nps.edu%7Ce1abad08574245aea8d608da006325f0%7C6d936231a51740ea9199f7578963378e%7C0%7C0%7C637822723149799226%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=QwginpByfaIYQKP2VuAWlw6cWm7jZRWqKbTs13%2FeFe4%3D&amp;reserved=0

    _______________________________________________
    MLS mailing list
    [email-masked]
    https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fmls&amp;data=04%7C01%7Cbritta.hale%40nps.edu%7Ce1abad08574245aea8d608da006325f0%7C6d936231a51740ea9199f7578963378e%7C0%7C0%7C637822723149799226%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=QwginpByfaIYQKP2VuAWlw6cWm7jZRWqKbTs13%2FeFe4%3D&amp;reserved=0

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 7 Mar 2022 11:25:25 -0800

I'm basically aligned with Richard here.

The situation as I understand it is that we do not have a complete
design for a deniable variant of MLS. When assessing this PR, we need
to ask whether it makes it meaningfully easier to build such a system
if/when we have such a design. AFAICT the answer is "no".

If we assume that messages are going to be signed, the question then
becomes how those signing keys are to be authentically but undeniably
bound to the sender's identity. ISTM that once we have addressed that,
the rest of the situation will be easy to resolve. As an example,
consider Richard's suggestion of exchanging authentication keys over a
deniable channel [0].

If we had such a mechanism, the change to allow new messages to be
signed with those keys would presumably be straightforward and that
spec could just update the relevant parts of this spec to suit, with
the negotiation for the new mechanism also indicating the correct
behavior. But absent such a design, PR #610 seems premature.

I am also indifferent to whether #347 is reverted.

-Ekr

[0] https://mailarchive.ietf.org/arch/msg/mls/1NKnpm_RlFSHXBIRc0BVehIMvik/

---

From: Raphael Robert <[email-masked]>
Date: Mon, 7 Mar 2022 20:36:55 +0100

This is surprising turn of events at the last minute. For context, we have been discussing deniability ever since the WG formed and there was a broad consensus that it should be optionally supported for those who are interested.
In October/November 2020 thanks to Sofia Cell, Chelsea Komlo and others (sorry if I forgot someone), a concrete proposal was made with the aim of allowing deniable signature keys while having a minimal impact on the protocol otherwise. The PR (437) was advertised on the mailing list and a) received support, b) there were no counter arguments and c) was merged into the spec. See https://mailarchive.ietf.org/arch/msg/mls/FitDfKtiyB6VIq7QTmJdIxDUh-0/ <https://mailarchive.ietf.org/arch/msg/mls/FitDfKtiyB6VIq7QTmJdIxDUh-0/> for reference.

It has been there ever since, so this is not a new feature request by either Konrad or Mallory. As Konrad mentioned, the discussion around the architecture document triggered another round of scrutiny on the spec. Furthermore, the request for supporting deniability has been expressed several times from implementors. So saying that “we are not going to define a deniable version of MLS in this specification” does not accurately reflect the past discussions at all.

If we need more discussion around the exact mechanism, that’s totally fair. Defining an extension might just be the right way to deal with it. However that extension should then be defined in the spec, just like we define other extension already, it should not be a proprietary change of the protocol that puts implementors and users at risk of not being compliant with the spec if they use it.

In practical terms I also don’t think this is such a big deal. We already leave many things up to the AS (we recently did it again in the context of member identifiers), so this doesn’t fundamentally change that logic. For interoperability there always needs to be a consensus on the AS level as well, which has always been out-of scope for for the protocol spec.

Raphael

> On 7. Mar 2022, at 19:50, Richard Barnes <[email-masked]> wrote:
> 
> tl;dr:
> 
> - Instead we should be clear that signatures are done with keys in credentials
> 
> 1. Signatures in MLS are created / verified with keys distributed in MLS credentials
> 2. Signatures in MLS are created / verified with keys distributed in some unspecified way
> 
> To be blunt, we are not going to define a deniable version of MLS in this specification.  (Sorry, Mallory!)  To do that, we would need some analysis of the form "MLS when operated in X way (or with protocol extension Y) provides deniability property Z."  Much like the analyses we have of confidentiality and authenticity properties.  To my knowledge, no such analysis exists.  The best we'll be able to say is something like "You might be able to operate MLS in such a way as to get deniability properties, if you're clever.  But maybe not!"
> 
> So the benefits here are dubious.  What about the costs?  I agree with Konrad that the specification is not OK as it is even if we are going to allow signatures by external keys.  But the problem is worse than he says, because the external keys aren't interoperable.  There's no mechanism in the specification for the clients to agree on how signatures are verified, so some clients might verify with credential keys and others with keys they got from a blockchain or something, thus coming to completely different results.  At the very least, we would need a way for the members of a group to agree on how signatures are being done.
> 
> Conveniently, the protocol has a way for group members to agree on behaviors, namely extensions.  If we require credential keys in the base protocol and deniability turns out to need external keys, it would be natural to have a GroupContextExtension that says "In this group, we don't use credential keys, but [other thing]".
> 
> Thus, it seems like there's no justification for taking on the complexity of external keys now.  Either it's not needed for deniability, or it can be cleanly and more safely added in an extension.
> 
> Instead we should revise the spec to be super clear that signatures are done with credential keys.  This establishes a clear, self-contained baseline protocol that can be a good basis for deniability analysis.
> 
> Personally, I don't think this requires reverting #437.  I don't think I ever understood it to allow external keys, which is probably why I let it go in the first place.  (To be clear, I don't agree with Konrad that the WG agreed to have "gap" ~= external keys.)  But if folks think it would be clearer to revert, happy to do it.
> 
> --Richard
> 
> On Mon, Mar 7, 2022 at 12:52 PM Mallory Knodel <[email-masked] <mailto:[email-masked]>> wrote:
> > (https://mailarchive.ietf.org/arch/msg/mls/FitDfKtiyB6VIq7QTmJdIxDUh-0/ <https://mailarchive.ietf.org/arch/msg/mls/FitDfKtiyB6VIq7QTmJdIxDUh-0/>) 
> > and then via GH PR: https://github.com/mlswg/mls-protocol/pull/437 <https://github.com/mlswg/mls-protocol/pull/437>, 
> > https://github.com/mlswg/mls-protocol/pull/610 <https://github.com/mlswg/mls-protocol/pull/610>.
> >
> > [email-masked] <mailto:[email-masked]>
> > https://www.ietf.org/mailman/listinfo/mls <https://www.ietf.org/mailman/listinfo/mls>
> 
> -- 
> Mallory Knodel
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/mls <https://www.ietf.org/mailman/listinfo/mls>

---

From: Richard Barnes <[email-masked]>
Date: Mon, 7 Mar 2022 15:06:26 -0500

I was also surprised by this, in the other direction!  But that means it's
a good thing we're hashing it out.

I don't think this WG ever signed up to create a deniable protocol.  It's
not in the charter [1], and the discussion in the BoF minutes [2] only
cover it as a nice-to-have.  The conversation in the thread you cite
doesn't provide a concrete proposal either; in fact, your message says "I
don’t have a good comprehensive proposal to make at this point".  I think
PR #437 skated by because it didn't appear to actually change anything.
TBH it seems like kind of stretch to read it as allowing external keys,
since the "public key authenticated by a credential" is exactly the public
key in the credential in the widely deployed public-key credential systems
today (e.g., X.509).

Not having a real, worked out model for deniability makes any support for
deniability here a non-starter.  Without that, we're just guessing!

So either we delay this spec for another year or two while we work out that
model and the relevant security proofs, or we tighten up on credential keys
and publish something.  Obviously I favor the latter.

--Richard

[1] https://datatracker.ietf.org/wg/mls/about/
[2] https://datatracker.ietf.org/doc/minutes-101-mls/

On Mon, Mar 7, 2022 at 2:36 PM Raphael Robert <[email-masked]>
wrote:

> This is surprising turn of events at the last minute. For context, we have
> been discussing deniability ever since the WG formed and there was a broad
> consensus that it should be optionally supported for those who are
> interested.
> In October/November 2020 thanks to Sofia Cell, Chelsea Komlo and others
> (sorry if I forgot someone), a concrete proposal was made with the aim of
> allowing deniable signature keys while having a minimal impact on the
> protocol otherwise. The PR (437) was advertised on the mailing list and a)
> received support, b) there were no counter arguments and c) was merged into
> the spec. See
> https://mailarchive.ietf.org/arch/msg/mls/FitDfKtiyB6VIq7QTmJdIxDUh-0/ for
> reference.
>
> It has been there ever since, so this is not a new feature request by
> either Konrad or Mallory. As Konrad mentioned, the discussion around the
> architecture document triggered another round of scrutiny on the spec.
> Furthermore, the request for supporting deniability has been expressed
> several times from implementors. So saying that “we are not going to define
> a deniable version of MLS in this specification” does not accurately
> reflect the past discussions at all.
>
> If we need more discussion around the exact mechanism, that’s totally
> fair. Defining an extension might just be the right way to deal with it.
> However that extension should then be defined in the spec, just like we
> define other extension already, it should not be a proprietary change of
> the protocol that puts implementors and users at risk of not being
> compliant with the spec if they use it.
>
> In practical terms I also don’t think this is such a big deal. We already
> leave many things up to the AS (we recently did it again in the context of
> member identifiers), so this doesn’t fundamentally change that logic. For
> interoperability there always needs to be a consensus on the AS level as
> well, which has always been out-of scope for for the protocol spec.
>
> Raphael
>
>

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 7 Mar 2022 12:17:33 -0800

FWIW, I read the text in PR #437 as allowing public keys to be
authenticated by the credential in some indirect way a la
https://datatracker.ietf.org/doc/html/draft-ietf-tls-subcerts-12. As
someone who wasn't paying as close attention, when I read this text it puts
me in mind of a design in which you issue a short-lived subvert for a
conversation and then leak the private key at some point in the future,
thus creating some level of deniability.

I don't personally think it's the right thing to do to hold MLS while we
work out deniability, but if people think that we need that feature, then I
think that would be having something that sort of handwaves in the
direction of deniability but doesn't provide it.

-Ekr

On Mon, Mar 7, 2022 at 12:06 PM Richard Barnes <[email-masked]> wrote:

> So either we delay this spec for another year or two while we work out
> that model and the relevant security proofs, or we tighten up on credential
> keys and publish something.  Obviously I favor the latter.
>
> --Richard
>
>> This is surprising turn of events at the last minute. For context, we
>> have been discussing deniability ever since the WG formed and there was a
>> broad consensus that it should be optionally supported for those who are
>> interested.
>>> > (
>>> https://mailarchive.ietf.org/arch/msg/mls/FitDfKtiyB6VIq7QTmJdIxDUh-0/)

---

From: Raphael Robert <[email-masked]>
Date: Mon, 7 Mar 2022 21:33:15 +0100

> On 7. Mar 2022, at 21:06, Richard Barnes <[email-masked]> wrote:

>   The conversation in the thread you cite doesn't provide a concrete proposal either; in fact, your message says "I don’t have a good comprehensive proposal to make at this point". 

I commented on the list after PR 437 was issued: "I think this is exactly what we need to achieve optional deniability for message authorship without touching the authentication guarantees of the the core protocol.”
I think that’s pretty unambiguous.

> I think PR #437 skated by because it didn't appear to actually change anything.  TBH it seems like kind of stretch to read it as allowing external keys, since the "public key authenticated by a credential" is exactly the public key in the credential in the widely deployed public-key credential systems today (e.g., X.509).
> 
> Not having a real, worked out model for deniability makes any support for deniability here a non-starter.  Without that, we're just guessing!
> 
> So either we delay this spec for another year or two while we work out that model and the relevant security proofs, or we tighten up on credential keys and publish something.  Obviously I favor the latter.

To be clear: I don’t recall anyone arguing for designing a mechanism on how signature keys can be distributed over a deniable channel. This was never in-scope for the protocol spec and it is also excluded by the charter. The intention behind PR 437 was to provide an indirection in the signature chain, nothing else. The exact mechanism still needs to be defined on the AS-level.

As for guessing, there is prior art, e.g. sender keys. 

I think there is a misunderstanding in what this entails: The intention is not to delay MLS, the intention is also not to now define a deniable distraction scheme and have it covered in the spec (again, that’s AS territory). The intention is merely to keep on supporting this indirection.

If it helps to disambiguate things, this could indeed be expressed in an extension so that interoperability becomes easier. To a degree we already allow this by supporting preconfigured senders (verifying those signatures is also completely out-of-scope and up to the AS). The mere difference here is that the senders are actual members not necessarily external entities as it is the case for preconfigured senders. Maybe it is as simple as introducing a new sender type. That way things would be completely unambiguous, authentication is not threatened as such, and we still keep the possibility to introduce deniable signature (with a mechanism that is defined elsewhere). Specific implementations can then just simply not support this new sender type, just like they can choose to not support preconfigured senders today.

Modulo the exact details of spec changes needed for disambiguation, I think this could put everyone at ease and not hamper the general progress of MLS.

Raphael

> 
> --Richard
> 
> [1] https://datatracker.ietf.org/wg/mls/about/ <https://datatracker.ietf.org/wg/mls/about/>
> [2] https://datatracker.ietf.org/doc/minutes-101-mls/ <https://datatracker.ietf.org/doc/minutes-101-mls/>
> 
> 
> On Mon, Mar 7, 2022 at 2:36 PM Raphael Robert <[email-masked] <mailto:[email-masked]>> wrote:
>> On 7. Mar 2022, at 19:50, Richard Barnes <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> tl;dr:
>>

---

From: Richard Barnes <[email-masked]>
Date: Mon, 7 Mar 2022 16:11:54 -0500

To be clear, I have no objection to doing this in extension.  I would be
fine with the WG taking on a "deniable MLS extension" work item.  (Again,
*if* any new protocol is needed, which is still not clear to me.)  However:

1. I do object to changing the base semantic of the protocol away from
credential keys.  Unless all members have opted in, the credential keys
behavior needs to be the default, because it's the only interoperable
behavior.

2. I would object to defining an extension in the main protocol document,
because (a) it's not clear what the extension would do and (b) to the
degree it is, it's a nontrivial architectural departure (e.g., extending
the AS to be a key source as well as providing authentication).  Those
details are going to take time to work out, and we shouldn't delay
deployment of the current version.

On Mon, Mar 7, 2022 at 3:33 PM Raphael Robert <[email-masked]>
wrote:

>   The conversation in the thread you cite doesn't provide a concrete
> proposal either; in fact, your message says "I don’t have a good
> comprehensive proposal to make at this point".
>
>
> I commented on the list after PR 437 was issued: "I think this is exactly
> what we need to achieve optional deniability for message authorship without
> touching the authentication guarantees of the the core protocol.”
> I think PR #437 skated by because it didn't appear to actually change
> anything.  TBH it seems like kind of stretch to read it as allowing
> external keys, since the "public key authenticated by a credential" is
> exactly the public key in the credential in the widely deployed public-key
> credential systems today (e.g., X.509).
>
> To be clear: I don’t recall anyone arguing for designing a mechanism on
> how signature keys can be distributed over a deniable channel. This was
> never in-scope for the protocol spec and it is also excluded by the
> charter. The intention behind PR 437 was to provide an indirection in the
> signature chain, nothing else. The exact mechanism still needs to be
> defined on the AS-level.
>
> I think there is a misunderstanding in what this entails: The intention is
> not to delay MLS, the intention is also not to now define a deniable
> distraction scheme and have it covered in the spec (again, that’s AS
> territory). The intention is merely to keep on supporting this indirection.
>
> If it helps to disambiguate things, this could indeed be expressed in an
> extension so that interoperability becomes easier. To a degree we already
> allow this by supporting preconfigured senders (verifying those signatures
> is also completely out-of-scope and up to the AS). The mere difference here
> is that the senders are actual members not necessarily external entities as
> it is the case for preconfigured senders. Maybe it is as simple as
> introducing a new sender type. That way things would be completely
> unambiguous, authentication is not threatened as such, and we still keep
> the possibility to introduce deniable signature (with a mechanism that is
> defined elsewhere). Specific implementations can then just simply not
> support this new sender type, just like they can choose to not support
> preconfigured senders today.
>
> Modulo the exact details of spec changes needed for disambiguation, I
> think this could put everyone at ease and not hamper the general progress
> of MLS.
>
> Raphael
>
>
> --Richard
>

---

From: Raphael Robert <[email-masked]>
Date: Mon, 7 Mar 2022 22:40:17 +0100

> To be clear, I have no objection to doing this in extension.  I would be fine with the WG taking on a "deniable MLS extension" work item.  (Again, *if* any new protocol is needed, which is still not clear to me.)  However:
> 
> 1. I do object to changing the base semantic of the protocol away from credential keys.  Unless all members have opted in, the credential keys behavior needs to be the default, because it's the only interoperable behavior.

I think we are fully aligned on that. 

> 2. I would object to defining an extension in the main protocol document, because (a) it's not clear what the extension would do and (b) to the degree it is, it's a nontrivial architectural departure (e.g., extending the AS to be a key source as well as providing authentication).  Those details are going to take time to work out, and we shouldn't delay deployment of the current version.

We have already departed by allowing preconfigured senders:

"The preconfigured SenderType is reserved for signers that are pre-provisioned to the clients within a group. If proposals with these sender IDs are to be accepted within a group, the members of the group MUST be provisioned by the application with a mapping between these IDs and authorized signing keys. Recipients MUST verify that the MLSPlaintext carrying the Proposal message is validly signed with the corresponding key. To ensure consistent handling of external proposals, the application MUST ensure that the members of a group have the same mapping and apply the same policies to external proposals.”

With preconfigured senders, it is up to the AS to verify signatures and thus to ensure authenticity. Having a new sender type for indirections would be no different. Btw, we also don’t have an extension to make sure that everyone in the group supports preconfigured senders. We just assume that this is somehow handled on the application level. So following this logic we should introduce an extension for that as well for robustness.

These details aside, my main worry is that we shut the door to any (future) deniable authentication if don’t allow this indirection now. We’ve been very flexible to accommodate all sorts of AS configurations so far (BasicCredentials, X.509, preconfigured senders), why not this one? I think it is very reasonable to keep the door open, given that there has been sufficient support for this in the past. Again, any implementation that does not wish to support it is not forced to support it. In fact, I suspect that in many deployment scenarios preconfigured senders won’t be allowed either.

Raphael

> 
> 
> On Mon, Mar 7, 2022 at 3:33 PM Raphael Robert <[email-masked] <mailto:[email-masked]>> wrote:
> 
> 
>> On 7. Mar 2022, at 21:06, Richard Barnes <[email-masked] <mailto:[email-masked]>> wrote:
>

---

From: Richard Barnes <[email-masked]>
Date: Mon, 7 Mar 2022 17:02:26 -0500

Inline...

> I think we are fully aligned on that.

Great.

> "The preconfigured SenderType is reserved for signers that are
> pre-provisioned to the clients within a group. If proposals with these
> sender IDs are to be accepted within a group, the members of the group MUST
> be provisioned by the application with a mapping between these IDs
> and authorized signing keys. Recipients MUST verify that the MLSPlaintext
> carrying the Proposal message is validly signed with the corresponding key.
> To ensure consistent handling of external proposals, the application MUST
> ensure that the members of a group have the same mapping and apply the same
> policies to external proposals.”
>
> With preconfigured senders, it is up to the AS to verify signatures and
> thus to ensure authenticity. Having a new sender type for indirections
> would be no different. Btw, we also don’t have an extension to make sure
> that everyone in the group supports preconfigured senders. We just assume
> that this is somehow handled on the application level. So following this
> logic we should introduce an extension for that as well for robustness.
>

I would actually be OK with this.  I think this was something that folks
thought was going to be necessary in the beginning that hasn't really
played out.  For example, in Webex, we just have the server forward a
KeyPackage instead of synthesizing an Add proposal under a preconfigured
signer; the TLS authentication is as good as a preconfigured signer
signature.  We could pretty cleanly remove this from the current document
as long as we kept the SenderType enum, which we need anyway for external
join.  Then the preconfigured_signer extension would just add back the new
SenderType and associated validation rules (and probably have a list of
authorized signers).  Filed an issue:

https://github.com/mlswg/mls-protocol/issues/616

These details aside, my main worry is that we shut the door to any (future)
> deniable authentication if don’t allow this indirection now. We’ve been
> very flexible to accommodate all sorts of AS configurations so far
> (BasicCredentials, X.509, preconfigured senders), why not this one? I think
> it is very reasonable to keep the door open, given that there has been
> sufficient support for this in the past. Again, any implementation that
> does not wish to support it is not forced to support it. In fact, I suspect
> that in many deployment scenarios preconfigured senders won’t be allowed
> either.
>

We wouldn't really be shutting the door, because extensions can make
arbitrary changes to protocol behavior.  The definition of the
`deniable_system_x` extension could specify that in any group where it's
negotiated, you use a new credential type SystemXCredential{} inside the
group, and pull the actual keys from System X.  Or whatever dance you need
to do to make your deniable system work.

The difference I would draw with BasicCredential / X509Credential is that
those are clearly defined.  BasicCredential is essentially raw public keys
with some UKS proection; X509Credential is essentially TLS.  With the
deniable key exchange stuff, there's just a hole; just "get the signature
keys <somehow>".  I'm sure there are ways to fill that in, but they need to
be worked out.

--RLB

>> I commented on the list after PR 437 was issued: "I think this is
>> exactly what we need to achieve optional deniability for message authorship
>> without touching the authentication guarantees of the the core protocol.”
>> I think there is a misunderstanding in what this entails: The intention
>> is not to delay MLS, the intention is also not to now define a deniable
>>> In practical terms I also don’t think this is such a big deal. We
>>> already leave many things up to the AS (we recently did it again in the
>>> context of member identifiers), so this doesn’t fundamentally change that
>>> logic. For interoperability there always needs to be a consensus on the AS
>>> level as well, which has always been out-of scope for for the protocol spec.
>>>
>>> Raphael
>>>
>>>
>>> To be blunt, we are not going to define a deniable version of MLS in
>>> this specification.  (Sorry, Mallory!)  To do that, we would need some
>>> analysis of the form "MLS when operated in X way (or with protocol
>>> extension Y) provides deniability property Z."  Much like the analyses we
>>> have of confidentiality and authenticity properties.  To my knowledge, no
>>> such analysis exists.  The best we'll be able to say is something like "You
>>> Thus, it seems like there's no justification for taking on the
>>> complexity of external keys now.  Either it's not needed for deniability,
>>> or it can be cleanly and more safely added in an extension.
>>>

---

From: Raphael Robert <[email-masked]>
Date: Tue, 8 Mar 2022 11:54:40 +0100

I would like to rewind a bit because I feel the conversation keeps shifting.

The discussion started with PR 610, which has the intention of harmonizing the signature key indirection introduced in PR 437. PR 437 in turn was introduced in November 2020.
There purpose of the PR was stated by Richard during the IETF109 MLS session (https://youtu.be/OFbkx_SNrh4?t=1963) and doesn't leave any room for ambiguity regarding the intent. There were no objections during its introduction, and there haven't been any objections ever since. We had rough consensus and working code (OpenMLS allows the indirection during message verification by accepting optional additional signature keys: https://github.com/openmls/openmls/blob/main/openmls/src/group/mls_group/processing.rs#L60)

I would really like to ask that we follow the IETF process here. If – after more than a year – folks feel that PR 437 is no longer desirable, they should state their concerns and seek for consensus to remove it.
Personally I wish this would have happened during one of the last interims because there are obviously nuances to the subject that can get lost in an unstructured debate on the mailing list.

Raphael

> On 7. Mar 2022, at 23:02, Richard Barnes <[email-masked]> wrote:
> 
> Inline...
> 
> On Mon, Mar 7, 2022 at 4:40 PM Raphael Robert <[email-masked] <mailto:[email-masked]>> wrote:
> 
> I would actually be OK with this.  I think this was something that folks thought was going to be necessary in the beginning that hasn't really played out.  For example, in Webex, we just have the server forward a KeyPackage instead of synthesizing an Add proposal under a preconfigured signer; the TLS authentication is as good as a preconfigured signer signature.  We could pretty cleanly remove this from the current document as long as we kept the SenderType enum, which we need anyway for external join.  Then the preconfigured_signer extension would just add back the new SenderType and associated validation rules (and probably have a list of authorized signers).  Filed an issue:
>  
> https://github.com/mlswg/mls-protocol/issues/616 <https://github.com/mlswg/mls-protocol/issues/616>
> 
> We wouldn't really be shutting the door, because extensions can make arbitrary changes to protocol behavior.  The definition of the `deniable_system_x` extension could specify that in any group where it's negotiated, you use a new credential type SystemXCredential{} inside the group, and pull the actual keys from System X.  Or whatever dance you need to do to make your deniable system work.
> 
> The difference I would draw with BasicCredential / X509Credential is that those are clearly defined.  BasicCredential is essentially raw public keys with some UKS proection; X509Credential is essentially TLS.  With the deniable key exchange stuff, there's just a hole; just "get the signature keys <somehow>".  I'm sure there are ways to fill that in, but they need to be worked out.
> 
> --RLB
>  
> 
> Raphael
> 
>> 
>>

---

From: Richard Barnes <[email-masked]>
Date: Tue, 8 Mar 2022 09:51:55 -0500

Heh, touché.  Apparently past-Richard was on a different page than I
thought.  I am genuinely sorry that the disagreement lurked for so long;
given the lack of interop testing so far, we just haven't had anything to
bring it to a head until this push to finish the spec.

Regardless, I do think that it makes sense to revisit this decision at this
point in the evolution of the document.  Now that we have some deployment
experience, the need for interop on key points is much more clear.  And I
think we agree that this deniable signature functionality is totally
non-interoperable.

To be clear, even if we tighten up the spec here, OpenMLS can still have
that code and you could even ship a real messaging system that relies on
it.  It would just be "off-book" usage, in the sense that the security
proofs wouldn't necessarily apply (how could they?) and you wouldn't expect
interop.  But I'm not sure the security proofs accommodate indirection
anyway and indirection isn't interoperable in any meaningful sense anyway.

--RLB

On Tue, Mar 8, 2022 at 5:54 AM Raphael Robert <[email-masked]>
wrote:

> The discussion started with PR 610, which has the intention of harmonizing
> the signature key indirection introduced in PR 437. PR 437 in turn was
> introduced in November 2020.
> There purpose of the PR was stated by Richard during the IETF109 MLS
> session (https://youtu.be/OFbkx_SNrh4?t=1963) and doesn't leave any room
> for ambiguity regarding the intent. There were no objections during its
> introduction, and there haven't been any objections ever since. We had
> rough consensus and working code (OpenMLS allows the indirection during
> message verification by accepting optional additional signature keys:
> https://github.com/openmls/openmls/blob/main/openmls/src/group/mls_group/processing.rs#L60
> )
>
> I would really like to ask that we follow the IETF process here. If –
> after more than a year – folks feel that PR 437 is no longer desirable,
> they should state their concerns and seek for consensus to remove it.
> Personally I wish this would have happened during one of the last interims
> because there are obviously nuances to the subject that can get lost in an
> unstructured debate on the mailing list.
>
> Raphael
>
> These details aside, my main worry is that we shut the door to any
>> (future) deniable authentication if don’t allow this indirection now. We’ve
>> been very flexible to accommodate all sorts of AS configurations so far
>>> Not having a real, worked out model for deniability makes any support
>>> for deniability here a non-starter.  Without that, we're just guessing!
>>>
>>>> Personally, I don't think this requires reverting #437.  I don't think
>>>> I ever understood it to allow external keys, which is probably why I let it

---

From: Raphael Robert <[email-masked]>
Date: Wed, 9 Mar 2022 15:05:48 +0100

It looks like there is agreement that the mechanism introduced in #437 is problematic for interoperability. The problem is somewhat aligned with what is described in #616 for preconfigured senders.

Konrad prepared PR #617 that reverts #437 and also fixes #616. I think this should address all the concerns raised in this thread.

Note that this does not mean that some sort of deniability/unlinkability cannot be achieved (Richard pointed out some options and there might be more), it only reverts the indirection in signature verification.

Raphael

> On 8. Mar 2022, at 23:21, 'Alwen, Joel' via ietf <[email-masked]> wrote:
> 
> TL;DR for my 2 cents on PR 437 & Deniability.
>  
> - I’m in favour of rolling back PR 437. More generally, I’m quite hesitant to include any language somehow hinting at the possibility of deniability via some extra feature (like using OOB deniable signature keys).
>  
> - I’m convinced deniability should not be a goal of the (initial version of) MLS.
>  
>  
>  
> The longer version.
>  
> - Why role back PR 437? 
>    It creates the possibility of using an unspecified OOB key distribution mechanism which leads to further under specification around how signatures are verified. To me, this means PR 437 takes a big step away from interop (and even just completeness). To me the change introduced in PR 437 doesn’t seem like a valuable enough feature to justify this negative side-effect. Especially since, as Richard pointed out, the same end could be achieved by those that want it via an extension (which would then presumably also lay out all the missing pieces not included in PR 437 to create a complete authentication mechanism).
>  
> - Why not mention deniability related mechanisms at all?
>    I’m unaware of any cryptographic analysis of the deniability properties of MLS in any setting. Let alone, what is achieved by MLS when signature PKs are distributed over OOB deniable channels. Formal deniability can be pretty subtle so, for something as complicated as MLS, it seems pretty non-trivial to analyse.
>    For starters, this means I would not want to put my name to any claim concerning what deniability MLS provides when using a particular setup (like OOB deniable key distribution). By extension, it also means I’m hesitant to include any language that could be reasonably understood to be implying that a certain version of MLS (like when using OOB deniable keys) provides “deniability”. In other words, my worry is if we say something like “and this is how you can use sig keys distributed over a deniable channel” then the reader might reasonably assume that using such keys would result in a deniable MLS session. I am far from certain for which standard/reasonable form of deniability (if any) this might be true and which not (especially for an MLS session that can last for years and where I might never rotate my signature keys). So mentioning deniability this way strikes me as risky.
>  
> - Why do I think deniability should not be a goal for MLS?
>    First and formost, because I thought deniability never was a declared goal of MLS; i.e. its not in the charter. Rather it was a “nice to have one day in some version” type thing.
>    More generally, (and less importantly) deniability –- as an intuitive (collection of) concepts -- strikes me as pretty dubious/niche. My problem is that I *really* struggle to motivate them in practical terms. They are either too weak or too strong depending on the real-world scenario. (I’ll spare everyone my reasoning here but hit me up if you want to change my mind. I realize its a contentious topic.) 😊
>     However, there are a ton of other security/efficiency properties we could analyse/add to MLS that I believe would each add *significantly* more value over allthen deniability. E.g. anonymity, post-quantum security, better efficiency, more meta-data hiding, stronger PCFS, stronger robustness against insiders anddefences against server-side group partitioning attacks to name a few. Nor are any of these implied by deniability. (Notably this is true for anonymity which I believe to be a *much* more relevant property than deniability in the overwhelming majority of real-world scenarios used to motivate the latter.) With all this in mind, I think we’d be better letting deniability be for now.
>  
> - Joël
>  
> From: MLS <[email-masked] <mailto:[email-masked]>> On Behalf Of Richard Barnes
> Sent: Tuesday, 8 March 2022 15:52
> To: Raphael Robert <[email-masked] <mailto:[email-masked]>>
> Cc: Mallory Knodel <[email-masked] <mailto:[email-masked]>>; Messaging Layer Security WG <[email-masked] <mailto:[email-masked]>>; Konrad Kohbrok <[email-masked] <mailto:[email-masked]>>
> Subject: [EXTERNAL] [UNVERIFIED SENDER] Re: [MLS] Deniability in MLS
>  
> CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe.
> 
>  
> Heh, touché.  Apparently past-Richard was on a different page than I thought.  I am genuinely sorry that the disagreement lurked for so long; given the lack of interop testing so far, we just haven't had anything to bring it to a head until this push to finish the spec.
>  
> Regardless, I do think that it makes sense to revisit this decision at this point in the evolution of the document.  Now that we have some deployment experience, the need for interop on key points is much more clear.  And I think we agree that this deniable signature functionality is totally non-interoperable.
>  
> To be clear, even if we tighten up the spec here, OpenMLS can still have that code and you could even ship a real messaging system that relies on it.  It would just be "off-book" usage, in the sense that the security proofs wouldn't necessarily apply (how could they?) and you wouldn't expect interop.  But I'm not sure the security proofs accommodate indirection anyway and indirection isn't interoperable in any meaningful sense anyway.
>  
> --RLB
>  
> On Tue, Mar 8, 2022 at 5:54 AM Raphael Robert <[email-masked] <mailto:[email-masked]>> wrote:
> There purpose of the PR was stated by Richard during the IETF109 MLS session (https://youtu.be/OFbkx_SNrh4?t=1963 <https://youtu.be/OFbkx_SNrh4?t=1963>) and doesn't leave any room for ambiguity regarding the intent. There were no objections during its introduction, and there haven't been any objections ever since. We had rough consensus and working code (OpenMLS allows the indirection during message verification by accepting optional additional signature keys:https://github.com/openmls/openmls/blob/main/openmls/src/group/mls_group/processing.rs#L60 <https://github.com/openmls/openmls/blob/main/openmls/src/group/mls_group/processing.rs#L60>)
>  
> On 7. Mar 2022, at 23:02, Richard Barnes <[email-masked] <mailto:[email-masked]>> wrote:
>  
> Inline...
>  
> Amazon Development Center Austria GmbH 
> Brueckenkopfgasse 1 
> 8020 Graz 
> Oesterreich 
> Sitz in Graz 
> Firmenbuchnummer: FN 439453 f 
> Firmenbuchgericht: Landesgericht fuer Zivilrechtssachen Graz

---

From: Richard Barnes <[email-masked]>
Date: Thu, 10 Mar 2022 09:18:44 -0500

Thanks, #617 seems like a good compromise.  It nails down the preconfigured
stuff and allows for external keys for everything but Commit.  Seems like
you should be able to make some headway on deniability with those tools.

It looks like there's pretty good agreement on #617.  Please chime in now
if you're not OK with it.  If I don't hear objections, I'll merge on Monday
or Tuesday.

--Richard

On Wed, Mar 9, 2022 at 9:05 AM Raphael Robert <[email-masked]>
wrote:

> It looks like there is agreement that the mechanism introduced in #437 is
> problematic for interoperability. The problem is somewhat aligned with what
> is described in #616 for preconfigured senders.
>
> Konrad prepared PR #617 that reverts #437 and also fixes #616. I think
> this should address all the concerns raised in this thread.
>
> Note that this does not mean that some sort of deniability/unlinkability
> cannot be achieved (Richard pointed out some options and there might be
> more), it only reverts the indirection in signature verification.
>
> Raphael
>
> - I’m in favour of rolling back PR 437. More generally, I’m quite hesitant
> to include any language somehow hinting at the possibility of deniability
> via some extra feature (like using OOB deniable signature keys).
>
>    It creates the possibility of using an unspecified OOB key distribution
> mechanism which leads to further under specification around how signatures
> are verified. To me, this means PR 437 takes a big step away from interop
> (and even just completeness). To me the change introduced in PR 437 doesn’t
> seem like a valuable enough feature to justify this negative side-effect.
> Especially since, as Richard pointed out, the same end could be achieved by
> those that want it via an extension (which would then presumably also lay
> out all the missing pieces not included in PR 437 to create a complete
> authentication mechanism).
>
>    I’m unaware of any cryptographic analysis of the deniability properties
> of MLS in any setting. Let alone, what is achieved by MLS when signature
> PKs are distributed over OOB deniable channels. Formal deniability can be
> pretty subtle so, for something as complicated as MLS, it seems pretty
> non-trivial to analyse.
>    For starters, this means I would not want to put my name to any claim
> concerning what deniability MLS provides when using a particular setup
> (like OOB deniable key distribution). By extension, it also means I’m
> hesitant to include any language that could be reasonably understood to be
> implying that a certain version of MLS (like when using OOB deniable keys)
> provides “deniability”. In other words, my worry is if we say something
> like “and this is how you can use sig keys distributed over a deniable
> channel” then the reader might reasonably assume that using such keys would
> result in a deniable MLS session. I am far from certain for which
> standard/reasonable form of deniability (if any) this might be true and
> which not (especially for an MLS session that can last for years and where
> I might never rotate my signature keys). So mentioning deniability this way
> strikes me as risky.
>
>    First and formost, because I thought deniability never was a declared
> goal of MLS; i.e. its not in the charter. Rather it was a “nice to have one
> day in some version” type thing.
>    More generally, (and less importantly) deniability –- as an intuitive
> (collection of) concepts -- strikes me as pretty dubious/niche. My
> problem is that I **really** struggle to motivate them in practical
> terms. They are either too weak or too strong depending on the real-world
> scenario. (I’ll spare everyone my reasoning here but hit me up if you want
> to change my mind. I realize its a contentious topic.) 😊
>     However, there are a ton of other security/efficiency properties we
> could analyse/add to MLS that I believe would each add **significantly** more
> value over allthen deniability. E.g. anonymity, post-quantum security, better
> efficiency, more meta-data hiding, stronger PCFS, stronger robustness
> against insiders anddefences against server-side group partitioning
> attacks to name a few. Nor are any of these implied by deniability.
> (Notably this is true for anonymity which I believe to be a **much** more
> relevant property than deniability in the overwhelming majority of
> real-world scenarios used to motivate the latter.) With all this in mind, I
> think we’d be better letting deniability be for now.
>
> - Joël
>
> *From:* MLS <[email-masked]> *On Behalf Of *Richard Barnes
> *Sent:* Tuesday, 8 March 2022 15:52
> *To:* Raphael Robert <[email-masked]>
> *Cc:* Mallory Knodel <[email-masked]>; Messaging Layer Security WG <
> [email-masked]>; Konrad Kohbrok <[email-masked]>
> *Subject:* [EXTERNAL] [UNVERIFIED SENDER] Re: [MLS] Deniability in MLS
>
>
> *CAUTION*: This email originated from outside of the organization. Do not
> click links or open attachments unless you can confirm the sender and know
> the content is safe.
>
> Regardless, I do think that it makes sense to revisit this decision at
> this point in the evolution of the document.  Now that we have some
> deployment experience, the need for interop on key points is much more
> clear.  And I think we agree that this deniable signature functionality is
> totally non-interoperable.
>

---

From: Jeff Burdges <[email-masked]>
Date: Mon, 14 Mar 2022 09:15:48 +0100

At this point, we've evidence that users deleting messages provides significant protection to marginalized communities, so messaging developers should think seriously about message deletion schemes, but..

We've afaik zero evidence that deniability provides protection to people not in already in positions of power or wealth. Instead, there exist a strong argument that deniability protects powerful people, while harming people who lack power: If you lack the power or money to bias courts or the press, then text files wind up being sufficient to penalize you, while if you have power or money then you can typically bias courts against simple text files evidence.
Anecdotally, all high profile cases I've noticed consist of a less powerful person proving nefarious activity of a more powerful person that was clearly in the public interest. I would know nothing about cases that were not in the public interest however, like tabloid celebrity gossip, so my own sample while somewhat compelling cannot be considered truly representative.
There are several interesting open questions around these topics of course:
Would old messages being editable provide some of the protections deniability fans claim?

How long should message signatures be retained to maximize protections for innocent people?

How should voluntary exfiltration of signed messages work?

We need more honest evaluations of when deniability is, or might be, useful to ordinary people, who do not occupy a position of power relative to their accusers. In particular, if the accuser is a major government or multi-national corporation, then deniability will afaik never be useful to an ordinary person, so other user stories must be considered.
We also need an honest & relatively complete list & assessment of how DKIM signatures, or other non-deniable evidence, have appeared in the press and maybe courts. If one assess such lists based upon the relative power of the involved parties, then one likely discovers that non-deniability has served to defend the weaker parties.
Best,
Jeff

---

From: "Hale, Britta (CIV)" <[email-masked]>
Date: Mon, 14 Mar 2022 15:33:36 +0000

Jeff,

Thank you for this summary, these are very good points.

Certainly within the WG and in side channels some of these issues have been discussed at length. Most of those discussions have ended up circling back to your core points of that more information is needed to build an actionable and useful form of deniability for a messaging applications – the type of deniability that aligns to court interpretations and not solely technical understanding.

For MLS, decisions on message deletion as well as constructs such as publishing a secret signature key are left to the AS and out-of-scope of the core protocol (simply given the scale of complexity of adding them and the various use cases). As a simple example, the implementation and AS design could rotate signature keys and publish older ones based on some application-defined acceptable window. Thus MLS protects information on the wire, but is conditioned on a very, very critical piece of infrastructure – the AS – which can heavily influence the security guarantees provided by any given application due to its role in authentication.

Likewise deletion of local messages or state is determined by the application.

While these aspects are outside the scope of the MLS protocol definition, the document also aims to not over-specify particular points so as to allow flexibility and ‘hooks’ for applications to use to support e.g. deniability if they so desire. It would indeed be beneficial to get more insight on leveraging those well, and more guidance to developers in general on the issues that you describe. Perhaps there should be an RFC on deniability methods and guarantees that the protocol standards or associated architecture documents can link to. It is definitely a point of need for the secure messaging space, broadly speaking.

Britta

From: MLS <[email-masked]> on behalf of Jeff Burdges <[email-masked]>
Date: Monday, March 14, 2022 at 1:16 AM
To: "[email-masked]" <[email-masked]>
Subject: [MLS] The quest for deniability looks like a problematic case of cutsy adversaries

  *   Would old messages being editable provide some of the protections deniability fans claim?

  *   How long should message signatures be retained to maximize protections for innocent people?

  *   How should voluntary exfiltration of signed messages work?

Best,
Jeff

---

From: Sofía Celi <[email-masked]>
Date: Mon, 14 Mar 2022 15:41:30 +0000

Dear, Jeff and Britta,

Thank you so much for this discussion. It is very interesting and 
important one.

> While these aspects are outside the scope of the MLS protocol 
> definition, the document also aims to not over-specify particular points 
> so as to allow flexibility and ‘hooks’ for applications to use to 
> support e.g. deniability if they so desire. It would indeed be 
> beneficial to get more insight on leveraging those well, and more 
> guidance to developers in general on the issues that you describe. 
> Perhaps there should be an RFC on deniability methods and guarantees 
> that the protocol standards or associated architecture documents can 
> link to. It is definitely a point of need for the secure messaging 
> space, broadly speaking.

I strongly agree on this with Britta. I would be happy to start said 
document or expand the definitions of it here: 
https://datatracker.ietf.org/doc/draft-knodel-e2ee-definition/

Thank you,

> *From: *MLS <[email-masked]> on behalf of Jeff Burdges 
> <[email-masked]>
> *Date: *Monday, March 14, 2022 at 1:16 AM
> *To: *"[email-masked]" <[email-masked]>
> *Subject: *[MLS] The quest for deniability looks like a problematic case 
> of cutsy adversaries
> 
> At this point, we've evidence that users deleting messages provides 
> significant protection to marginalized communities, so messaging 
> developers should think seriously about message deletion schemes, but..
> 
> We've afaik zero evidence that deniability provides protection to people 
> not in already in positions of power or wealth.  Instead, there exist a 
> strong argument that deniability protects powerful people, while harming 
> people who lack power: If you lack the power or money to bias courts or 
> the press, then text files wind up being sufficient to penalize you, 
> while if you have power or money then you can typically bias courts 
> against simple text files evidence.
> 
> Anecdotally, all high profile cases I've noticed consist of a less 
> powerful person proving nefarious activity of a more powerful person 
> that was clearly in the public interest.  I would know nothing about 
> cases that were not in the public interest however, like tabloid 
> celebrity gossip, so my own sample while somewhat compelling cannot be 
> considered truly representative.
> 
> We need more honest evaluations of when deniability is, or might be, 
> useful to ordinary people, who do not occupy a position of power 
> relative to their accusers.  In particular, if the accuser is a major 
> government or multi-national corporation, then deniability will afaik 
> never be useful to an ordinary person, so other user stories must be 
> considered.
> 
> We also need an honest & relatively complete list & assessment of how 
> DKIM signatures, or other non-deniable evidence, have appeared in the 
> press and maybe courts.  If one assess such lists based upon the 
> relative power of the involved parties, then one likely discovers that 
> non-deniability has served to defend the weaker parties.
> 
> Best,
> 
> Jeff
> 
> 

-- 
Sofía Celi
@claucece
Cryptographic research and implementation at many places, but specially 
Cloudflare
Reach me out at: [email-masked]
3D0B D6E9 4D51 FBC2 CEF7  F004 C835 5EB9 42BF A1D6

---

From: Raphael Robert <[email-masked]>
Date: Mon, 14 Mar 2022 18:12:49 +0100

I agree with the points that were brought up. More precisely:

 - There is a lack of evidence in either direction. Any public documentation seems to be anecdotal at this point. The notion of deniability introduced by the OTR protocol (and later continued in the Signal protocol) was probably largely based on assumptions (Sofia please correct me if I’m wrong).

 - As Jeff points out, there are certainly situations where deniability is not desirable. In particular in a communication channel where there is a strong power misbalance between the peers and instead a certain degree of accountability would be more desirable.

 - On the opposite end of the spectrum, it can sometimes also be advantageous to not have strong evidence that a certain communication took place, or that certain messages were sent. I’m thinking about whistleblowing or discussions among activists (obviously the cryptographic layer is only one aspect of deniability, disappearing messages etc. play a role as well).

 - As Britta pointed out, the AS plays a crucial role here. It seems that in practice there’s always a certain tradeoff between the authentication guarantees and the deniability guarantees. The Signal protocol for example has above-average (offline) deniability guarantees because it uses an authenticated channel between two peers and refrains from further authenticating individual messages. This comes at the cost of sub-optimal authentication guarantees, because it becomes impossible to distinguish whether you received a message from a peer or if your own device was compromised and the message was sent by the attacker in the name of your peer. In this respect, MLS does provide stronger authentication.

 - I also think the question of (cryptographic) deniability is not limited to the protocol itself, but also to the PKI used in a messaging system. According to [1], iMessage uses plain signatures for message authentication which are not deniable as such and could serve as proof that a certain message was authored/sent. In practical terms however, the overall system doesn’t really expose the users’ public keys which makes it difficult if not impossible to attribute a signature to a specific user. This does provide a degree of de facto deniability. However, this might change going forward. Perhaps it will be more common to have PKIs/registries that resemble what e.g. Keybase does: a system where there is a strong public link between users and their signature keys. If that was the case – and deniability remains a desirable goal in some circumstances – it becomes more important to think about the linke between the PKI and the messaging protocol.

 - Another aspect of de facto deniability is the fact that even if messages are signed, the signature is typically immediately discarded by messaging apps once it’s verified. It would require special tools or a modified messaging client to preserve the signature to attribute messages to users beyond using screenshots. This is again not a strong guarantee, but in practice it makes it harder to prove authenticity to third parties easily and on a large scale.

Konrad and I recently discussed what after-the-fact signing key reveals could look like (thanks for also bringing this up Britta). We have a hunch that this could be possibly done in a way that doesn’t automatically decrease the authentication guarantees and also doesn’t rely on any changes in the MLS protocol as such. Sofia, happy to join forces here to explore this further (and maybe start a document as you mentioned).

Raphael

[1]https://support.apple.com/en-gb/guide/security/secd9764312f/web

> On 14. Mar 2022, at 16:41, Sofía Celi <[email-masked]> wrote:
> 
> Dear, Jeff and Britta,
> 
> Thank you so much for this discussion. It is very interesting and important one.
> 
> I strongly agree on this with Britta. I would be happy to start said document or expand the definitions of it here: https://datatracker.ietf.org/doc/draft-knodel-e2ee-definition/
> 
> Thank you,
> 
> 
>> *From: *MLS <[email-masked]> on behalf of Jeff Burdges <[email-masked]>
>> *Subject: *[MLS] The quest for deniability looks like a problematic case of cutsy adversaries
> Cryptographic research and implementation at many places, but specially Cloudflare