< draft-gwerder-messagevortexmain-08.txt   draft-gwerder-messagevortexmain-09.txt >
Internet Engineering Task Force M. Gwerder Internet Engineering Task Force M. Gwerder
Internet-Draft FHNW Internet-Draft FHNW
Intended status: Experimental 4 October 2021 Intended status: Experimental 6 April 2022
Expires: 7 April 2022 Expires: 8 October 2022
MessageVortex Protocol MessageVortex Protocol
draft-gwerder-messagevortexmain-08 draft-gwerder-messagevortexmain-09
Abstract Abstract
The MessageVortex (referred to as Vortex) protocol achieves different The MessageVortex (referred to as Vortex) protocol achieves different
degrees of anonymity, including sender, receiver, and third-party degrees of anonymity, including sender, receiver, and third-party
anonymity, by specifying messages embedded within the existing anonymity, by specifying messages embedded within the existing
transfer protocols, such as SMTP or XMPP, sent via peer nodes to one transfer protocols, such as SMTP or XMPP, sent via peer nodes to one
or more recipients. or more recipients.
The protocol outperforms others by decoupling the transport from the The protocol outperforms others by decoupling the transport from the
skipping to change at page 1, line 43 skipping to change at page 1, line 43
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on 7 April 2022. This Internet-Draft will expire on 8 October 2022.
Copyright Notice Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the Copyright (c) 2022 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document. license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components and restrictions with respect to this document. Code Components
extracted from this document must include Simplified BSD License text extracted from this document must include Simplified BSD License text
as described in Section 4.e of the Trust Legal Provisions and are as described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Simplified BSD License. provided without warranty as described in the Simplified BSD License.
skipping to change at page 3, line 18 skipping to change at page 3, line 18
4.3.3. Payload Block . . . . . . . . . . . . . . . . . . . . 15 4.3.3. Payload Block . . . . . . . . . . . . . . . . . . . . 15
5. General notes . . . . . . . . . . . . . . . . . . . . . . . . 15 5. General notes . . . . . . . . . . . . . . . . . . . . . . . . 15
5.1. Supported Symmetric Ciphers . . . . . . . . . . . . . . . 15 5.1. Supported Symmetric Ciphers . . . . . . . . . . . . . . . 15
5.2. Supported Asymmetric Ciphers . . . . . . . . . . . . . . 16 5.2. Supported Asymmetric Ciphers . . . . . . . . . . . . . . 16
5.3. Supported MACs . . . . . . . . . . . . . . . . . . . . . 16 5.3. Supported MACs . . . . . . . . . . . . . . . . . . . . . 16
5.4. Supported Paddings . . . . . . . . . . . . . . . . . . . 16 5.4. Supported Paddings . . . . . . . . . . . . . . . . . . . 16
5.5. Supported Modes . . . . . . . . . . . . . . . . . . . . . 16 5.5. Supported Modes . . . . . . . . . . . . . . . . . . . . . 16
6. Blending . . . . . . . . . . . . . . . . . . . . . . . . . . 17 6. Blending . . . . . . . . . . . . . . . . . . . . . . . . . . 17
6.1. Blending in Attachments . . . . . . . . . . . . . . . . . 17 6.1. Blending in Attachments . . . . . . . . . . . . . . . . . 17
6.1.1. PLAIN embedding into attachments . . . . . . . . . . 18 6.1.1. PLAIN embedding into attachments . . . . . . . . . . 18
6.1.2. F5 embedding into attachments . . . . . . . . . . . . 18 6.1.2. F5 embedding into attachments . . . . . . . . . . . . 19
6.2. Blending into an SMTP layer . . . . . . . . . . . . . . . 19 6.2. Blending into an SMTP layer . . . . . . . . . . . . . . . 19
6.3. Blending into an XMPP layer . . . . . . . . . . . . . . . 19 6.3. Blending into an XMPP layer . . . . . . . . . . . . . . . 19
7. Routing . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 7. Routing . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
7.1. Vortex Message Processing . . . . . . . . . . . . . . . . 19 7.1. Vortex Message Processing . . . . . . . . . . . . . . . . 20
7.1.1. Processing of incoming Vortex Messages . . . . . . . 19 7.1.1. Processing of incoming Vortex Messages . . . . . . . 20
7.1.2. Processing of Routing Blocks in the Workspace . . . . 22 7.1.2. Processing of Routing Blocks in the Workspace . . . . 22
7.1.3. Processing of Outgoing Vortex Messages . . . . . . . 23 7.1.3. Processing of Outgoing Vortex Messages . . . . . . . 23
7.2. Header Requests . . . . . . . . . . . . . . . . . . . . . 23 7.2. Header Requests . . . . . . . . . . . . . . . . . . . . . 24
7.2.1. Request New Ephemeral Identity . . . . . . . . . . . 23 7.2.1. Request New Ephemeral Identity . . . . . . . . . . . 24
7.2.2. Request Message Quota . . . . . . . . . . . . . . . . 24 7.2.2. Request Message Quota . . . . . . . . . . . . . . . . 24
7.2.3. Request Increase of Message Quota . . . . . . . . . . 24 7.2.3. Request Increase of Message Quota . . . . . . . . . . 24
7.2.4. Request Transfer Quota . . . . . . . . . . . . . . . 24 7.2.4. Request Transfer Quota . . . . . . . . . . . . . . . 25
7.2.5. Query Quota . . . . . . . . . . . . . . . . . . . . . 25 7.2.5. Query Quota . . . . . . . . . . . . . . . . . . . . . 25
7.2.6. Request Capabilities . . . . . . . . . . . . . . . . 25 7.2.6. Request Capabilities . . . . . . . . . . . . . . . . 25
7.2.7. Request Nodes . . . . . . . . . . . . . . . . . . . . 25 7.2.7. Request Nodes . . . . . . . . . . . . . . . . . . . . 25
7.2.8. Request Identity Replace . . . . . . . . . . . . . . 26 7.2.8. Request Identity Replace . . . . . . . . . . . . . . 26
7.2.9. Request Upgrade . . . . . . . . . . . . . . . . . . . 26 7.2.9. Request Upgrade . . . . . . . . . . . . . . . . . . . 26
7.3. Special Blocks . . . . . . . . . . . . . . . . . . . . . 26 7.3. Special Blocks . . . . . . . . . . . . . . . . . . . . . 26
7.3.1. Error Block . . . . . . . . . . . . . . . . . . . . . 26 7.3.1. Error Block . . . . . . . . . . . . . . . . . . . . . 26
7.3.2. Requirement Block . . . . . . . . . . . . . . . . . . 26 7.3.2. Requirement Block . . . . . . . . . . . . . . . . . . 27
7.3.2.1. Puzzle Requirement . . . . . . . . . . . . . . . 27 7.3.2.1. Puzzle Requirement . . . . . . . . . . . . . . . 27
7.3.2.2. Payment Requirement . . . . . . . . . . . . . . . 27 7.3.2.2. Payment Requirement . . . . . . . . . . . . . . . 27
7.3.2.3. Upgrade . . . . . . . . . . . . . . . . . . . . . 27 7.3.2.3. Upgrade . . . . . . . . . . . . . . . . . . . . . 27
7.4. Routing Operations . . . . . . . . . . . . . . . . . . . 27 7.4. Routing Operations . . . . . . . . . . . . . . . . . . . 28
7.4.1. Mapping Operation . . . . . . . . . . . . . . . . . . 28 7.4.1. Mapping Operation . . . . . . . . . . . . . . . . . . 28
7.4.2. Split and Merge Operations . . . . . . . . . . . . . 28 7.4.2. Split and Merge Operations . . . . . . . . . . . . . 28
7.4.3. Encrypt and Decrypt Operations . . . . . . . . . . . 29 7.4.3. Encrypt and Decrypt Operations . . . . . . . . . . . 29
7.4.4. Add and Remove Redundancy Operations . . . . . . . . 29 7.4.4. Add and Remove Redundancy Operations . . . . . . . . 29
7.4.4.1. Padding Operation . . . . . . . . . . . . . . . . 29 7.4.4.1. Padding Operation . . . . . . . . . . . . . . . . 29
7.4.4.2. Apply Matrix . . . . . . . . . . . . . . . . . . 30 7.4.4.2. Apply Matrix . . . . . . . . . . . . . . . . . . 30
7.4.4.3. Encrypt Target Block . . . . . . . . . . . . . . 31 7.4.4.3. Encrypt Target Block . . . . . . . . . . . . . . 31
7.5. Processing of Vortex Messages . . . . . . . . . . . . . . 31 7.5. Processing of Vortex Messages . . . . . . . . . . . . . . 31
8. Accounting . . . . . . . . . . . . . . . . . . . . . . . . . 31 8. Accounting . . . . . . . . . . . . . . . . . . . . . . . . . 31
8.1. Accounting Operations . . . . . . . . . . . . . . . . . . 31 8.1. Accounting Operations . . . . . . . . . . . . . . . . . . 31
8.1.1. Time-Based Garbage Collection . . . . . . . . . . . . 31 8.1.1. Time-Based Garbage Collection . . . . . . . . . . . . 31
8.1.2. Time-Based Routing Initiation . . . . . . . . . . . . 32 8.1.2. Time-Based Routing Initiation . . . . . . . . . . . . 32
8.1.3. Routing Based Quota Updates . . . . . . . . . . . . . 32 8.1.3. Routing Based Quota Updates . . . . . . . . . . . . . 32
8.1.4. Routing Based Authorization . . . . . . . . . . . . . 32 8.1.4. Routing Based Authorization . . . . . . . . . . . . . 32
8.1.5. Ephemeral Identity Creation . . . . . . . . . . . . . 32 8.1.5. Ephemeral Identity Creation . . . . . . . . . . . . . 32
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32
10. Security Considerations . . . . . . . . . . . . . . . . . . . 32 10. Security Considerations . . . . . . . . . . . . . . . . . . . 32
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 35 10.1. CIA Triad . . . . . . . . . . . . . . . . . . . . . . . 33
11.1. Normative References . . . . . . . . . . . . . . . . . . 35 10.2. Anonymity and Detectability . . . . . . . . . . . . . . 34
11.2. Informative References . . . . . . . . . . . . . . . . . 37 10.2.1. Blending Layer Considerations . . . . . . . . . . . 34
Appendix A. The ASN.1 schema for Vortex messages . . . . . . . . 37 10.2.2. Routing and Accounting Layer Considerations . . . . 34
A.1. The Main MessageVortex Blocks . . . . . . . . . . . . . . 38 10.3. Active Adversaries . . . . . . . . . . . . . . . . . . . 35
A.2. The MessageVortex Ciphers Structures . . . . . . . . . . 41 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 36
A.3. The MessageVortex Request Structures . . . . . . . . . . 44 11.1. Normative References . . . . . . . . . . . . . . . . . . 36
A.4. The MessageVortex Replies Structures . . . . . . . . . . 45 11.2. Informative References . . . . . . . . . . . . . . . . . 38
A.5. The MessageVortex Requirements Structures . . . . . . . . 48 Appendix A. The ASN.1 schema for Vortex messages . . . . . . . . 38
A.6. The MessageVortex Helpers Structures . . . . . . . . . . 48 A.1. The Main MessageVortex Blocks . . . . . . . . . . . . . . 39
A.7. The MessageVortex Additional Structures . . . . . . . . . 50 A.2. The MessageVortex Ciphers Structures . . . . . . . . . . 42
Appendix B. Changelog . . . . . . . . . . . . . . . . . . . . . 52 A.3. The MessageVortex Request Structures . . . . . . . . . . 45
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 52 A.4. The MessageVortex Replies Structures . . . . . . . . . . 46
A.5. The MessageVortex Requirements Structures . . . . . . . . 49
A.6. The MessageVortex Helpers Structures . . . . . . . . . . 49
A.7. The MessageVortex Additional Structures . . . . . . . . . 51
Appendix B. Changelog . . . . . . . . . . . . . . . . . . . . . 53
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 53
1. Introduction 1. Introduction
Anonymization is difficult to achieve. Most previous attempts relied Anonymization is difficult to achieve. Most previous attempts relied
on either trust in a dedicated infrastructure or a specialized on either trust in a dedicated infrastructure or a specialized
networking protocol. networking protocol.
Instead of defining a transport layer, Vortex piggybacks on other Instead of defining a transport layer, Vortex piggybacks on other
transport protocols. A blending layer embeds MessageVortex messages transport protocols. A blending layer embeds MessageVortex messages
(VortexMessage) into ordinary messages of the respective transport (VortexMessage) into ordinary messages of the respective transport
skipping to change at page 32, line 51 skipping to change at page 32, line 51
RFC. For testing purposes, IDs above 1,000,000 should be used. RFC. For testing purposes, IDs above 1,000,000 should be used.
10. Security Considerations 10. Security Considerations
The MessageVortex protocol should be understood as a toolset instead The MessageVortex protocol should be understood as a toolset instead
of a fixed product. Depending on the usage of the toolset, anonymity of a fixed product. Depending on the usage of the toolset, anonymity
and security are affected. For a detailed analysis, see and security are affected. For a detailed analysis, see
[MVAnalysis]. [MVAnalysis].
The primary goals for security within this protocol rely on the The primary goals for security within this protocol rely on the
following focus areas. following focus areas:
* Confidentiality * Confidentiality
* Integrity * Integrity
* Availability * Availability
* Anonymity * Anonymity
- Third-party anonymity - Third-party anonymity (unobservability)
- Sender anonymity - Sender anonymity (sender is not known to the recipient if not
disclosed)
- Receiver anonymity - Receiver anonymity (recipient is not known to the sender if
using a reply block for routing)
These aspects are affected by the usage of the protocol, and the * Detectability
following sections provide additional information on how they impact
the primary goals. The first three are known as the CIA triad.
All of these aspects are affected by the usage of the protocol, and
the following sections provide additional information on how they
impact the primary goals.
10.1. CIA Triad
The Vortex protocol does not rely on any encryption of the transport The Vortex protocol does not rely on any encryption of the transport
layer since Vortex messages are already encrypted. In addition, layer for confidentiality since Vortex messages are already
confidentiality is not affected by the protection mechanisms of the encrypted. However - Additional transport layer encryption may help
transport layer. to make it harder to identify blended messages on the transport layer
when not crafted individually.
If a transport layer supports encryption, then a Vortex node SHOULD All authentification, integrity and encryption schemes are already
use it to improve the privacy of the message. part of the MessageVortex protocol and do not rely on any other
mechanism except for the mechanism of reliable transport. However,
even an unreliable transport may be used to a certain extent by
offering redundant paths in the built routing block. This will not
introduce a general retry mechanism but may counter outages in the
routing nodes or temporary outages in the connectivity of
MessageVortex nodes.
Anonymity is affected by the inner workings of the blending layer in 10.2. Anonymity and Detectability
many ways. A Vortex message cannot be read by anyone except the peer
nodes and routing block builder. The presence of a Vortex node
message may be detected through the typical high entropy of an
encrypted file, broken structures of a carrier file, meaningless
content of a carrier file, or the contextless communication of the
transport layer with its peer partner. A blending layer SHOULD
minimize the possibility of simple detection by minimizing these
effects.
A blending layer SHOULD use carrier files with high compression or Anonymity is affected by the inner workings of the blending layer and
encryption. Carrier files SHOULD NOT have inner structures such that routing block outline in many ways. In general, A Vortex message
the payload is comparable to valid content. To achieve cannot be read by anyone except the peer nodes and routing block
undetectability by a human reviewer, a routing block builder should builder. The presence of a Vortex message may be detected through
use F5 instead of PLAIN blending. This approach however, increases the typical high entropy of an encrypted file, broken structures of a
the protocol overhead by approximately tenfold. carrier file, meaningless content of a carrier file, or the
contextless communication of the transport layer with its peer
partner. A blending layer SHOULD minimize the possibility of simple
detection by minimizing these effects.
Proposing a general scheme is useless, as such a scheme would allow
identification of blending layer. Instead a list of DOs and DON'Ts
is provided as an excerpt from[MVAnalysis].
10.2.1. Blending Layer Considerations
A Blending layer should have one or more message types to send. The
content of these message highly affect the detecatbility of a
protocol. The messages should be clearly machine generatet (e.g.,
statistics, password recovery requests, event notifications) that
contain attachments or images (carrier content) in an generated
manner (no static imagery). The size of this carrier content should
be chosen statically and should contain continuously changing
content. This requirement has massive effects on implementations of
Vortex nodes. A context of the content (e.g., in a timely context)
should be maintained. In general cantent with high compression
(e.g., jpeg imagery) is used in the context of the internet. If not
indicated otherwise this rule should be followed.
Ideally, carrier files SHOULD NOT have inner structures such that the
payload is comparable to valid content. To achieve undetectability
by a human reviewer, a routing block builder should use jpeg and F5
instead of PLAIN blending. This approach however, increases the
protocol overhead by approximately tenfold.
10.2.2. Routing and Accounting Layer Considerations
The two layers of 'routing' and 'accounting' have the deepest insight The two layers of 'routing' and 'accounting' have the deepest insight
into a Vortex message's inner workings. Each is aware of the into a Vortex message's inner workings. Each is aware of the
immediate peer sender and the peer recipients of all payload chunks. immediate peer sender and the peer recipients of all payload chunks.
As decoy traffic is generated by combining chunks and applying As decoy traffic is generated by combining chunks and applying
redundancy calculations, a node can never know if a malfunction redundancy calculations, a node can never know if a malfunction
(e.g., during a recovery calculation) was intended. Therefore, a (e.g., during a recovery calculation) was intended. Therefore, a
node is unable to distinguish a failed transaction from a terminated node is unable to distinguish a failed transaction from a terminated
transaction as well as content from decoy traffic. transaction as well as content from decoy traffic.
A routing block builder SHOULD follow the following rules not to A routing block builder SHOULD follow the following rules not to
compromise a Vortex message's anonymity. compromise a Vortex message's anonymity.
* All operations applied SHOULD be credibly involved in a message * All operations applied SHOULD be credibly involved in a message
transfer. transfer. The combined knowledge of multiple subsequent routing
nodes should not allow judgement of wheather it is real or decoy
traffic.
* A sufficient subset of the result of an addRedundancy operation * A sufficient subset of the result of an addRedundancy operation
should always be sent to peers to allow recovery of the data should always be sent to peers to allow recovery of the data
built. built.
* The anonymity set of a message should be sufficiently large to * The anonymity set of a message should be sufficiently large to
avoid legal prosecution of all jurisdictional entities involved, avoid legal prosecution of all jurisdictional entities involved,
even if a certain amount of the anonymity set cooperates with an even if a certain amount of the anonymity set cooperates with an
adversary. adversary.
* Encryption and decryption SHOULD follow normal usage whenever * Encryption and decryption SHOULD follow normal usage whenever
possible by avoiding the encryption of a block on a node with one possible by avoiding the encryption of a block on a node with one
key and decrypting it with a different key on the same or adjacent key and decrypting it with a different key on the same or adjacent
node. node.
* Traffic peaks SHOULD be uniformly distributed within the entire * Traffic peaks SHOULD be uniformly distributed within the entire
anonymity set. anonymity set. This restriction applies to all traffic as a
whole. A single message may generate unbalanced traffic.
* A routing block SHOULD be used for a limited number of messages. * A routing block SHOULD be used for a limited number of messages.
If used as a message block for the node, then it should be used If used as a message block for the node, then it should be used
only once. A block builder SHOULD use the only once.
HeaderRequestReplaceIdentity block to update the reply to routing
blocks regularly. Implementers should always remember that the * A block builder SHOULD use the HeaderRequestReplaceIdentity block
same routing block is identifiable by its structure. to update the reply to routing blocks regularly. Implementers
should always remember that the same routing block is identifiable
by its structure.
10.3. Active Adversaries
An active adversary cannot use blocks from other routing block An active adversary cannot use blocks from other routing block
builders. While the adversary may falsify the result by injecting an builders. While the adversary may falsify the result by injecting an
incorrect message chunk or not sending a message, such message incorrect message chunk or not sending a message, such message
disruptions may be detected by intentionally routing information to disruptions may be detected by intentionally routing information to
the routing block builder (RBB) node. If the Vortex message does not the routing block builder (RBB) node. If the Vortex message does not
carry the information expected, then the node may safely assume that carry the information expected, then the node may safely assume that
one of the involved nodes is misbehaving. A block building node MAY one of the involved nodes is misbehaving. A block building node MAY
calculate the reputation for involved nodes over time and MAY build calculate the reputation for involved nodes over time and MAY build
redundancy paths into a routing block to withstand such malicious redundancy paths into a routing block to withstand such malicious
skipping to change at page 52, line 42 skipping to change at page 53, line 42
| | | padding to improve credibility of bad | | | | padding to improve credibility of bad |
| | | values. | | | | values. |
+---------+---------+-----------------------------------------------+ +---------+---------+-----------------------------------------------+
| 6 | 02-2021 | Removed some outdated references and | | 6 | 02-2021 | Removed some outdated references and |
| | | updated draft according to the final | | | | updated draft according to the final |
| | | research document. Refining of | | | | research document. Refining of |
| | | language. | | | | language. |
+---------+---------+-----------------------------------------------+ +---------+---------+-----------------------------------------------+
| 7 | 04-2021 | Lectorate and improved rendering. | | 7 | 04-2021 | Lectorate and improved rendering. |
+---------+---------+-----------------------------------------------+ +---------+---------+-----------------------------------------------+
| 9 | 04-2022 | Rewrite of security considerations |
| | | section. |
+---------+---------+-----------------------------------------------+
Table 1: changes in versions Table 1: changes in versions
Author's Address Author's Address
Martin Gwerder Martin Gwerder
University of Applied Sciences and Arts Northwestern Switzerland University of Applied Sciences and Arts Northwestern Switzerland
Bahnhofstrasse 5 Bahnhofstrasse 5
CH-5210 Windisch CH-5210 Windisch
Switzerland Switzerland
 End of changes. 24 change blocks. 
60 lines changed or deleted 112 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/