Internet-Draft MIMI pseudonym privacy flows August 2024
Mahy Expires 20 February 2025 [Page]
Workgroup:
More Instant Messaging Interoperability
Internet-Draft:
draft-mahy-mimi-pseudonyms-latest
Published:
Intended Status:
Informational
Expires:
Author:
R. Mahy
Rohan Mahy Consulting Services

Some pseudonymous privacy flows for More Instant Messaging Interoperability (MIMI)

Abstract

The MIMI protocol has a baseline level of metadata privacy, which can be made more private through the optional use of per-room pseudonyms. This document describes three of many possible flows that use pseudonyms for enhanced privacy. It also discusses some ways that spam and abuse prevention mechanisms can work in conjunction with pseudonyms.

About This Document

This note is to be removed before publishing as an RFC.

The latest revision of this draft can be found at https://rohanmahy.github.io/mimi-pseudonyms/draft-mahy-mimi-pseudonyms.html. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-mahy-mimi-pseudonyms/.

Discussion of this document takes place on the More Instant Messaging Interoperability Working Group mailing list (mailto:mimi@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/mimi/. Subscribe at https://www.ietf.org/mailman/listinfo/mimi/.

Source for this draft and an issue tracker can be found at https://github.com/rohanmahy/mimi-pseudonyms.

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on 20 February 2025.

Table of Contents

1. Introduction

The More Instant Messaging Interoperability (MIMI) protocol [I-D.ietf-mimi-protocol] defines a baseline mechanism of metadata privacy with the following properties. Each local provider can know which of its users are a participant in any given room, and the domain of the hub. The hub provider knows the list of participants for each room that it manages. Local/follower providers do not learn the identity (or even the domain of) participants from other providers as those users send handshakes and application messages, unless the provider happens to also be the hub for the room.

There is also consensus that user can join rooms using a unique pseudonym per room. The MIMI endpoints provided by the hub operate equally well on pseudonyms as on "real" identities. However, there are operational implications related to authorization, consent, KeyPackage availability, credentials, spam/abuse mitigation, and disclosure of the user's "real" identity. As a result there are several possible ways of using pseudonyms that are compatible with MIMI. This document describes three specific flows. Other flows and other metadata privacy mechanisms are possible, some of which also use pseudonyms, for example [I-D.kohbrok-mimi-metadata-minimalization].

The flows described here include a connection-oriented flow, an out-of-band join link flow, and a knock flow. A very high level summary of each flow follows.

Connection flow:

Since the last step is based on a human delay which could vary from seconds to years, the timing would be difficult to correlate between a pair of providers with a large volume of traffic. If either provider has a very small number of users, either provider could use traffic analysis to associate the second room with Bob.

Out-of-band link flow:

Knock flow:

This flow is substantially similar to the connection flow, except that Cathy immediately leaves the "knock room", and the administrator adds Cathy to an existing room (vs. Bob creating a new room).

2. Conventions and Definitions

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.

This document uses MIMI terms defined in [I-D.ietf-mimi-arch] and [I-D.ietf-mimi-protocol]. MIMI uses the Messaging Layer Security (MLS) protocol extensively; the document uses several MLS terms defined in [RFC9420].

3. Example flows

3.1. Connection flow

Initially Alice and Bob both request a number of pseudonyms (and associated MLS credentials). They may upload KeyPackages for these pseudonyms.

ClientA1 ServerA ServerB ClientB* Request Request pseudonyms pseudonyms Store KPs Store KPs ... time passes ...

Alice decides to connect to Bob. She creates a room in which to bootstrap her private connection with Bob. She uses one of her pseudonyms as her identifier in the new room. Alice searches for Bob using his handle identifier. She requests KeyPackages for Bob's real identity. Note that she may need consent to fetch his KeyPackages (not shown), or Bob may grant blanket consent for connection rooms. Alice adds Bob and Welcomes him to the new temporary room.

Alice now sends Bob an application message revealing her actual identity, another of her pseudonyms, and optionally a list of her KeyPackages from that pseudonym. In all likelihood, the user Bob would not be presented with any indication that Alice wants to connect until this point.

ClientA1 ServerA ServerB ClientB* Create room Add Alice's other clients /idQuery 200 OK Request KPs /keyMaterial 200 OK connect KPs Commit, etc. Accepted /notify 200 OK Welcome, Tree Message /notify 200 OK AliceID, KPs ... time passes ...

At some point, Bob accepts Alice's connection request. Bob creates a new room using one of his pseudonyms. Bob adds Alice's clients to the room using the provided KeyPackages. Bob can also add the rest of his clients at the same time, assuming that Bob has a way to get KeyPackages securely among his clients. Bob then sends a message to Alice. The hub sees a room between two pseudonyms.

ClientA1 ServerA ServerB ClientB* Bob Create room accepts Commit, etc. /notify Welcome, Tree Message /notify Message

Alice eventually destroys the bootstrap room, for example after a random delay (not shown).

Alice and Bob can add each other to additional rooms by sending an application message with a join link, as shown in the next flow.

The connection flow may be useful when the sender wants to initially establish connectivity but does not have an out-of-band or third-party channel to the receiver. On providers with a low volume of flows or when relatively few flows use pseudonyms, this flow is vulnerable to timing analysis. Between a pair of providers with large volumes of new rooms using pseudonyms, this approach can be very effective. This flow has the advantage that the initiator can validate the real identity of the receiver before establishing any type of communication. This may be useful when contacting a known journalist, law-enforcement agent, rights-advocacy group, or ombudsperson.

3.3. Knock flow

A new user Cathy is aware of a room that she wants to join. Likely there is web page for the room with instructions for joining. The page includes a related "knock room" which contains the moderators or administrators of the target room. The "knock room" can be joined by anyone, but by default each joiner can send one message to the admins while regular users never receive application messages sent to the group (although the client has the keying material needed to decrypt the ciphertext if they receive it.)

Cathy sends a message with her KeyPackages for one of her pseudonyms. She then leaves the "knock room".

ClientA1 ServerA ServerC ClientC* Cathy finds "knock room" get GroupInfo /groupInfo OK GroupInfo GroupInfo Commit, etc. /notify Commit App Message: "Knock" App Message: Real ID, KPs "Knock" /notify Real ID, KPs Remove Proposals Cathy removes herself Remove ... time passes ...

An administrator of the target room decides to add Cathy using the KeyPackages she provided in the (related) "knock room".

ClientA1 ServerA ServerC ClientC* Commit, etc. Accepted /notify 200 OK Welcome, Tree

This flow is ideal for joining an established affinity group. For example, this method could be used by members of marginalized communities. The perspective joiner needs to believe that the "knock room" contains only moderators who will treat their join request in confidence and not "out" them.

4. Disclosing additional identity properties in an application message

The concept of pseudonyms is of limited utility if the subject of the pseudonym cannot disclose additional "real" identity properties as it wishes. In the connection flow, Alice reveals her "real" identity only to Bob; in the join link flow, Bob reveals aspects of his "real" identity to the room; in the knock flow, Cathy reveals aspects of her "real" identity to the moderators of her target room, and depending on the policy of the target room she might reveal a different aspect of her identity inside the target room.

The properties needed for safe and appropriate identity disclosure include:

This document assumes that these disclosures happen to participants of a room inside an application message, directly using an appropriate media type (not necessarily inside a MIMI content message). The next three subsections describe three such mechanisms.

4.1. Generic MLS Credential

MIMI describes its use with the MLS protocol [RFC9420]. If a new media type application/mls-credential was defined, clients could send the MLS Credential struct (possibly with the credential name as a media type parameter.) The MLS struct is reproduced here:

struct {
    CredentialType credential_type;
    select (Credential.credential_type) {
        case basic:
            opaque identity<V>;

        case x509:
            Certificate certificates<V>;
    };
} Credential;

For example, the client's MLS LeafNode could contain an MLS Credential with an X.509 certificate with a subjectAltName URI that corresponds to the pseudonym address of the client. The client could then disclose to the room a different X.509 certificate with the same issuer and public key which also reveals the "real" display name, and email address of the user.

OpenID Connect UserInfo Verifiable Credentials (VCs) are another proposed MLS Credential type [I-D.barnes-mls-addl-creds] with more natural claims semantics.

4.2. Selective Disclosure JSON Web Tokens

While the use of JSON Web Tokens (JWT) [RFC7519] is widespread, most uses do not require the holder/presenter to prove possession of a private key as in [RFC9449]. Selective disclosure JWT (SD-JWT) [I-D.ietf-oauth-selective-disclosure-jwt] describes both a way to selectively disclose claims, it also include an optional presenter key binding mechanism. The format uses the media type application/sd+jwt.

This format could be used directly in MIMI with an appropriate profile.

4.3. Selective Disclosure CBOR Web Tokens

Likewise, there are Selective Disclosure CBOR Web Tokens (SD-CWT) [I-D.prorock-spice-cose-sd-cwt]. SD-CWT uses the media type application/sd+cwt, and requires the use of its key binding mechanism in presentations.

5. Spam and Abuse prevention

MIMI has a requirement to be able to prevent spam and other forms of abuse. When using pseudonymous identities, there is naturally concern that an account with many pseudonyms could be used to violate room policy in the same room repeatedly or in multiple rooms with impunity. This section explores some implementation options to prevent this.

In a multi-provider messaging system, the hub provider is the only provider that knows the room policy and therefore the only provider that can decide if the policy is being violated. The local provider will need to eventually cooperate with the hub provider in order to prevent the same bad actor from violating policy repeatedly with different pseudonyms.

5.1. Detection signals

There are several signals used for detection of spam or abuse. In theory, an explicit abuse report should be a very strong signal of abuse. However, an abuse report could be sent accidentally; it could be the result of a misunderstanding about the policy in a room; or it could have been sent maliciously. A report might be incorrectly processed by an algorithm, or it might need to wait for a human moderator to process it.

A ban or kick by a moderator or administrator of a group could also be a strong signal, but an administrator might maliciously act against someone they disagree with rather than someone who actually violated policy. Since the motivation for the ban or kick is not shared with the hub, the claim is also impossible to validate.

The hub may also use the rate or pattern of joining groups or sending messages for one of its own users as an indicator of how spammy that user is, but for users based on other providers it has no way to correlate that information across pseudonyms.

5.2. Remedies

Once the hub suspects that a user has violated its policies, it has a number of possible remedies. Some of these remedies require cooperation with the local provider of that user.

Actions the hub can take independently:

  • prevent the user from sending messages in a room

  • remove the user from a room (kick)

  • ban the user from a room (temporarily)

  • ban the user from a room (permanently)

Actions requiring cooperation of the user's local provider

  • suspend the account of the user

  • suspend the account of the user and remove the user (including all pseudonyms) from all rooms

  • completely delete the account of the user

  • suspend the account and any accounts deemed "related" (ex: used the same email address or phone number)

  • delete the account and any "related" accounts

Specifying an interface for reporting suspected abusive identities from one provider to another is currently out-of-scope of the MIMI charter and likely to be defined between providers or by a more focussed standards developing organization, such as the Messaging Anti-Abuse Working Group (M3AAWG).

5.3. Correlating anti-abuse actions across multiple pseudonyms

It is possible that the local provider for a user can lookup the account associated with a specific user identity. This may be straightforward, or the provider might implement a scheme where this lookup is possible but requires extra technical or operational steps and leaves evidence of the inquiry. This would be the moral equivalent of breaking the pane of glass in some manual fire alarms.

In other implementations, perhaps no direct lookup is possible during normal operation of the system, but an API could suspend of delete the account associated with a particular pseudonym.

For some providers it may be operationally acceptable that only a small number of pseudonyms can be created for a particular account.

There are also mechanisms such as searchable encryption and homomorphic encryption, which allow searching for all the pseudonyms with the same account id with a combined spam factor over a certain threshold. Alternatively, a provider may use similar encryption mechanisms but require a positive reputation threshold in order to allow new pseudonyms to be created.

7. Other mechanism needed

This document describes some flows for effective, selectively pseudonymous privacy. Use in a MIMI system requires a small amount of additional specification and implementation. The author has attempted to list this items according to whether they are in-scope according to the MIMI charter.

Out of scope:

Assumed in scope:

8. Security Considerations

TODO Security

9. IANA Considerations

This document has no IANA actions.

10. References

10.1. Normative References

[I-D.ietf-mimi-protocol]
Barnes, R., Hodgson, M., Kohbrok, K., Mahy, R., Ralston, T., and R. Robert, "More Instant Messaging Interoperability (MIMI) using HTTPS and MLS", Work in Progress, Internet-Draft, draft-ietf-mimi-protocol-01, , <https://datatracker.ietf.org/doc/html/draft-ietf-mimi-protocol-01>.
[I-D.ietf-oauth-selective-disclosure-jwt]
Fett, D., Yasuda, K., and B. Campbell, "Selective Disclosure for JWTs (SD-JWT)", Work in Progress, Internet-Draft, draft-ietf-oauth-selective-disclosure-jwt-10, , <https://datatracker.ietf.org/doc/html/draft-ietf-oauth-selective-disclosure-jwt-10>.
[I-D.prorock-spice-cose-sd-cwt]
Prorock, M., Steele, O., and H. Birkholz, "Selective Disclosure CWTs (SD-CWT)", Work in Progress, Internet-Draft, draft-prorock-spice-cose-sd-cwt-01, , <https://datatracker.ietf.org/doc/html/draft-prorock-spice-cose-sd-cwt-01>.
[RFC2119]
Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <https://www.rfc-editor.org/rfc/rfc2119>.
[RFC8174]
Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, , <https://www.rfc-editor.org/rfc/rfc8174>.
[RFC9420]
Barnes, R., Beurdouche, B., Robert, R., Millican, J., Omara, E., and K. Cohn-Gordon, "The Messaging Layer Security (MLS) Protocol", RFC 9420, DOI 10.17487/RFC9420, , <https://www.rfc-editor.org/rfc/rfc9420>.

10.2. Informative References

[I-D.barnes-mls-addl-creds]
Barnes, R. and S. Nandakumar, "Additional MLS Credentials", Work in Progress, Internet-Draft, draft-barnes-mls-addl-creds-01, , <https://datatracker.ietf.org/doc/html/draft-barnes-mls-addl-creds-01>.
[I-D.ietf-mimi-arch]
Barnes, R., "An Architecture for More Instant Messaging Interoperability (MIMI)", Work in Progress, Internet-Draft, draft-ietf-mimi-arch-00, , <https://datatracker.ietf.org/doc/html/draft-ietf-mimi-arch-00>.
[I-D.kohbrok-mimi-metadata-minimalization]
Kohbrok, K. and R. Robert, "MIMI Metadata Minimalization (MIMIMI)", Work in Progress, Internet-Draft, draft-kohbrok-mimi-metadata-minimalization-00, , <https://datatracker.ietf.org/doc/html/draft-kohbrok-mimi-metadata-minimalization-00>.
[RFC7519]
Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token (JWT)", RFC 7519, DOI 10.17487/RFC7519, , <https://www.rfc-editor.org/rfc/rfc7519>.
[RFC9449]
Fett, D., Campbell, B., Bradley, J., Lodderstedt, T., Jones, M., and D. Waite, "OAuth 2.0 Demonstrating Proof of Possession (DPoP)", RFC 9449, DOI 10.17487/RFC9449, , <https://www.rfc-editor.org/rfc/rfc9449>.

Acknowledgments

TODO acknowledge.

Author's Address

Rohan Mahy
Rohan Mahy Consulting Services