{: #pEp_F_1 title="Basic pEp protocol interchange" artwork-align="center" }
With no auxiliary support like pre-shared secrets, or exercising
trust in external third-parties, this is the fastest way to
automatically assist Bob in starting an encrypted conversation with
Alice.
The protocol has two advantages: it requires no external input to
start functioning, and it works fully asynchronous and in-band. The
protocol has two drawbacks though, which pEp explicitely accepts;
first, Alice may totally renounce privacy in her first messages, i.e.
until she receives a reply from Bob; and second, both won't
immediately authenticate their channel once they start the encrypted
communication.
But still, it is a huge advancement over sticking with plaintext
communication forever; at this point, a passive eavesdropper is
already locked out. And an active attacker only has a short
window-of-opportunity to attack.
The exact format is transport specific, in particular, the
cryptographic material may be sent in three different ways.
1. On a transport for structured messages (e.g. {{MIME}} based Email), it may be bundled with the original message, resulting in a replacement framing message
0. The cryptographic service may embed it into the cryptographic envelope in a transport specific way (e.g. {{SMIME}})
0. Additional technical messages may be sent precursing the actual message. \[\[TODO: Such messages MUST be cryptographically interlinked such that partial reception remains totally useless to the recipient.\]\]
Different variants of the above may be used during initialization and
in the loop state.
Lets say Alice sets up a second device, and configures it with her
same identity. pEp MUST first create a new key. Alice now ends up
with two separate keys on two devices. Alice immediately sends a
second message to Bob from her new device (Message 3 in {{pEp_F_2}}).
Her new device has not yet learned the public key of Bob, so Message
3 is send unencrypted again.
+-------+ +-------+
| Alice | | Bob |
+-------+ +-------+
| |
| Plaintext Msg 3 |
| + PubKey_A2 |
| ----------------------------------> |
| |
|\___________________________________/|
NOT encrypted
{: #pEp_F_2 title="Second device in use" artwork-align="center" }
Neither Alice nor Bob really care about the details, and if it was
not for the pEp protocol, they would continue to send and receive
messages in clear text. pEp wants to improve this, and wants to
provide encryption whenever possible. But pEp never stops anyone from
sending a message, if by no means it can't start encrypting
automatically.
* pEp, in it's default configuration, MUST NOT, ever, prevent the
user from sending a message or interrupt this process with questions
* It MUST clearly signal the predicted privacy rating for the
outgoing message though.
\[\[ **TODO**: we just introduced rating *prediction* without prior
explanation \]\]
Alice, which is sending her first message to Bob on her additional
device, will clearly see that pEp predicts a low privacy for her
outgoing message.
+-------+ +-------+
| Alice | | Bob |
+-------+ +-------+
| |
| Plaintext Msg 3 |
| + PubKey_A2 |
| ----------------------------------> | --+ Learn
| | | PubKey_A2
| Protected Msg 4 | | of Identity
| + PubKey_B | | Alice
| <----------------------------------|<-+
| |
| |
|\___________________________________/|
Encrypted but NOT authenticated
{: #pEp_F_3 title="Receiving message from unlinked additional device" artwork-align="center" }
Now Bob sees a message and a new PubKey_A2 from Alice, while he
previously learned PubKey_A from her. Bobs pEp is giving this a low
rating. As Bob and Alice have not yet expressed trust in their
connection yet, pEp now accepts the second key for Alice. Still, the
first learned key is preferred, which is Alices first key, which
resides on her first computer.
* For any identity, pEp MUST use the first learned key for
encryption, otherwise a man-in-the-middle could succesfully install
an additional key by forging a message. - The recipient MUST
maintain the validity records of learned keys independently, but the
validity MUST NOT exceed those encoded in the received keys.
\[\[ **TODO**: add note if pEp requires valid network time, I think
it could be designed such that it's not required\]\]
\[\[ **TODO**: why not encrypt to all still valid keys on a given
transport?\]\]
Note that the case above depicts the worst case scenario. When Alice
started using her new computer, she may have re-read Message 2 of Bob
on the new device, and pEp would have immediately learned Bob's
public key, so that outgoing Message 3 would've already been
encrypted. This is covered in the transports model with the incoming
and outgoing messages property, described later. TODO
### Private Device Pairing
To read Bob's message on her second device, she needs to pair them,
which engages the keysync protocol. Ideally, Alices oldest key would
automatically find its way onto all of her devices. Unfortunately,
pEp Synchronization cannot start fully automatically. Alice first
needs to be guided through another function of pEp, which is mutual
authentication. For this, Alice operates both of her devices, and
once she selected the common account or entered an address of the
other device, she has to compare the public key fingerprints of both
devices (simplified through the use of Trustwords). If she confirms
on both devices, each of them will mark the other's public key as
trusted, and register it under the same "own" user.
+----------+ +----------------+ +----------+
| Device 1 | | Sync Transport | | Device 2 |
+----------+ +----------------+ +----------+
| | |
~~~~~~~~~~~ Alice starts pairing on device 1 ~~~~~~~~~~
| | |
| | |
| Sync beacon 1 | |
| -------------------> +-+ |
| ||| |
~~~~~~~~~~~ Alice starts pairing on device 2 ~~~~~~~~~~
Note that the trasnport for synchronization messages and the
trasnport for the users messages MAY be separate transports.
### Key Synchronization
At this point in time both devices disclose all of their private keys
(one each) to each other, and Alice can now read Bob's both messages
on both her devices.
### Key Reset
Now, Bob was unlucky and got his computer infected, so that he is
setting it up anew. On the fresh system, while his previous key is
recovered from the backup, the key itself was compromised, such that
it needs to be replaced.
* When a key is recovered from backup, it SHOULD be replaced.
Bob chooses to simply "reset" pEp. This means that pEp is resetting
his "own" identity, revoking all keys and creating a new one. From
now on, every message of Bob will contain the new public key, and the
revocation of the old ones.
* When pEp receives a revocation certificate through a pEp specific
transport format, it MUST mark all the learned keys as revoked,
while,
* when pEp receives a revocation certificate through a non-pEp specific transport format, it MUST mark only the specified key as revoked.
* Revocation certificates MUST be accepted from any source, given that they pass cryptographic scrutiny (i.e. that they are valid).
* The message delivering the revocation certificate MAY be signed by the key the revoked certificate concerns.
* A revocation certificate for an "own" key MAY be received; in such a case an "own" identity reset must be triggered.
* It is a considered a good course of action to submit revocation certificates or private keys to the issuer, shall third-party private keys be found in leaked datasets. Submission MAY be anonymous.
* Receiving an "own" private key from a non-"own" identity MUST trigger an "own" identity reset.
Bob has now replaced his key. Alice wouldn't know anything of Bob's
new key until receiving a message from Bob. This is why Bobs pEp
sends a technical message to all recent correspondents. If Alice is
not a recent correspondent, and she suddenly starts writing to Bob
again, she will see a lowered rating because of the timeframe<!--
MUST! -->, and she'll be using the deprecated key of Bob which she
still considers valid. Bob can then still decrypt the received
message, but will also see a lowered rating, because of the revoked
key being used. For a baseline, it is still better to use a
deprecated key, than sending messages plaintext.
This key rollover was almost transparent for Bob and Alice. The
previous time Bob went through this, he hadn't a backup, and things
didn't go as smooth. He had lost his previous key, and pEp could not
deliver the revocation certificate automatically. Bob then needed
\[\[ **TODO**: Bob does not really know this need \]\] to write Alice
a short enquiry, to please reset the trust on his identity. Alice
heard about Bobs issue before, and followed up, and Alices pEp then
blacklisted all the previously acquired keys. The key just attached
was then the new oldest valid key learned, ready to be used.
In turn, pEp implementers MUST ensure that a discernible privacy status is clearly
visible to the user -- on a per-contact as well as per-message level -- so
that users easily understand which level of privacy messages are
about to be sent with or were received with, respectively.
\[\[Note: We are aware of the fact that usually UX requirements are
not part of RFCs. However, in order to encourage massive adoption of
secure end-to-end encryption while at the same time avoiding putting
users at risk, we believe certain straightforward
signaling requirements for users to be a good idea, just as
is currently done for already-popular instant messaging
services.\]\]
## Multiple Identities
# Specific Elements in pEp
In pEp, users MUST have the ability to have multiple identities.
## pEp identity system
pEp users MUST have the option to choose the identity they want to
appear with. This allows an user to decide how to reveal hto the
world. It is an important element to maintain privacy.
In pEp, users MUST have the ability to have multiple different identities.
To provide for this separation, pEp will create dedicated keys for
every identity defined.
pEp users MUST have the option to choose different identities. This
allows an Internet user to decide how to reveal himself/herself to the world
and is an important element in order to achieve privacy.
* By default, all identities MUST NOT be externally correlatable.
The user MAY override this through advanced usage, e.g. by importing
external keys.
These different identities MUST NOT be externally correlatable with each other by
default. On the other hand, combining different identities when such information is known MUST be
supported (alias support).
pEp assists the user in learning different identities of
correspondents (aliases).
<!--
{:: include ../shared/ascii-arts/pep_id_system.mkd}
@ -328,76 +622,487 @@ supported (alias support).
-->
## Identifiers
## Trivial Anonymization
Routed networks require that a message carries a destination address,
and often also a source address. This is metadata being leaked, and
most often it is cleartext information. {{pEp_F_5}} shows in a
sequence diagram how an eavesdropper (here depicted as a Three-Letter
Agengy), sees a message directed from Alice to Bob beind sent from
Alice to Bob.
+-------+ +-------+ +-----------+ +-----+
| Alice | | TLA | | Bobs Corp | | Bob |
+-------+ +-------+ +-----------+ +-----+
| ^ | |
~~~~~~~~~~ TLA sees message from @ alice to @ bob ~~~~~~~~~
| ^ | |
| ^ | |
| Message 5 ^ | |
| To: @ bob ^ | |
| ----------------###------------> @ |
| ^ @ ----------> |
| ^ | |
{: #pEp_F_5 title="Principle of eavesdropping messages in transit" artwork-align="center" }
A workaround for Alice is to start wrapping the messages and
directing them to a relaying party. In the simplest case she requires
Bobs Corporation Transfer Agent to cooperate, so that she can rely
the message to a generic corporate address. {{pEp_F_6}} depicts how
the eavesdropper now only sees Alice communicating with Bobs
Corporation.
+-------+ +-------+ +-----------+ +-----+
| Alice | | TLA | | Bobs Corp | | Bob |
+-------+ +-------+ +-----------+ +-----+
| ^ | |
~~~~~~~~~~ TLA sees message from @ alice to @ mta ~~~~~~~~~
| ^ | |
| Message 6 ^ | |
| @ bob ^ | |
| --+ ^ | |
| | Wrap to ^ | |
# <-+@mta^||
# ^ | |
# Message 6* ^ | |
# To: @ mta ^ | |
# ----------------###------------> @ --+ |
| ^ | | Unwrap |
| ^ # <-+6*>6 |
| ^ # |
| ^ # Submit 6 |
| ^ # To: @ bob |
| ^ # ----------> |
| ^ | |
{: #pEp_F_6 title="Principle of Onion Routing" artwork-align="center" }
Alice can apply the wrapping recursively. An Internet Service
Provider may also offer a relying service. {{pEp_F_7}} shows that by
double wrapping the message, the eavesdropper starts to read less and
less meaningful metadata from the messages, in this case a message
