Mixnets are designed with the assumption that a PKI exists and it
gives each client the same view of the network. This specification
is inspired by the Tor and Mixminion Directory Authority systems
[MIXMINIONDIRAUTH][TORDIRAUTH] whose main features are precisely what
we need in our PKI. These are decentralized systems meant to be
collectively operated by multiple entities.

The mix network directory authority system (PKI) is essentially a
cooperative decentralized database and voting system that is used
to produce network consensus documents which mix clients
periodically retrieve and use for their path selection algorithm
when creating Sphinx packets. These network consensus documents are
derived from a voting process between the Directory Authority
servers.

This design prevents mix clients from using only a partial view of
the network for their path selection so as to avoid fingerprinting
and bridging attacks [FINGERPRINTING][BRIDGING][LOCALVIEW].

The PKI is also used by Authority operators to specify network-wide
parameters, for example in the Katzenpost Decryption Mix Network
[KATZMIXNET] the Poisson mix strategy is used and therefore all the
clients must use the same lambda parameter for their exponential
distribution function when choosing hop delays in the path
selection. The Mix Network Directory Authority system aka PKI
SHALL be used to distribute such network-wide parameters in the network
consensus document that have an impact on security and performance.

communicate directly with to communicate with the Mixnet.
It is responsible for Client authentication,
forwarding outgoing messages to the Mixnet, and storing incoming
messages for the Client. The Provider MUST have the ability to
perform cryptographic operations on the relayed messages.

This Directory Authority system has the following feature goals and
security properties:

All Directory Authority servers must agree with each other on
the set of Directory Authorities.

All Directory Authority servers must agree with each other on
the set of mixes.

This system is intentionally designed to provide identical
network consensus documents to each mix client. This mitigates
epistemic attacks against the client path selection algorithm
such as fingerprinting and bridge attacks [FINGERPRINTING][BRIDGING].

This system is NOT byzantine-fault-tolerant, it instead allows
for manual intervention upon consensus fault by the Directory
Authority operators. Further, these operators are responsible
for expelling bad acting operators from the system.

This system enforces the network policies such as mix join
policy wherein intentionally closed mixnets will prevent
arbitrary hosts from joining the network by authenticating all
descriptor signatures with a list of allowed public keys.

The Directory Authority system for a given mix network is
essentially the root of all authority.

In this document we specify a Directory Authority system
which is different from that of Tor’s and Mixminion’s in a number
of ways:

The list of valid mixes is expressed in a white list. For
the time being there is no specified “bandwidth authority”
system which verifies the health of mixes.
(Further research required.)

There’s no non-directory channel to inform clients that a node
is down, so it will end up being a lot of packet loss, since
clients will continue to include the missing node in their
path selection till keys published by the node expire and it
falls out of the consensus.

The schema of the mix descriptors is different from that used
in Mixminion and Tor, including a change which allows our mix
descriptor to express n Sphinx mix routing public keys in a
single mix descriptor whereas in the Tor and Mixminion Directory
Authority systems, n descriptors are used.

The serialization format of mix descriptors is different from
that used in Mixminion and Tor.

The shared random number computation is performed every voting round,
and is required for a vote to be accepted by each authority. The shared
random number is used to deterministically generate the network
topology.

Each Mix MUST rotate the key pair used for Sphinx packet processing
periodically for forward secrecy reasons and to keep the list of
seen packet tags short. [SPHINX09][SPHINXSPEC] The Katzenpost Mix
Network uses a fixed interval (epoch), so that key rotations happen
simultaneously throughout the network, at predictable times.

Each Directory Authority server MUST use some time synchronization
protocol in order to correctly use this protocol. This Directory
Authority system requires time synchronization to within a few
minutes.

Let each epoch be exactly 10800seconds(3hours) in duration, and
the 0th Epoch begin at 2017-06-0100:00UTC.

To facilitate smooth operation of the network and to allow for
delays that span across epoch boundaries, Mixes MUST publish keys
to the PKI for at least 3 epochs in advance, unless the mix will
be otherwise unavailable in the near future due to planned downtime.

Thus, at any time, keys for all Mixes for the Nth through N + 2nd
epoch will be available, allowing for a maximum round trip (forward
message + SURB) delay + transit time of 6 hours. SURB lifetime is
limited to a few hours because of the key rotation epoch, however
this shouldn’t present any useability problems since SURBs are only
used for sending ACK messages from the destination Provider to the
sender as described in [KATZMIXE2E].

Mix PKI interactions are conducted according to the following
schedule, where T is the beginning of the current epoch.

T+P/2 - Deadline for publication of all mixes documents

for the next epoch.

T+(7/8)*P - This marks the beginning of the period

where mixes perform staggered fetches
of the PKI consensus document.

T+(8/9)*P - Start establishing connections to the new set of

relevant mixes in advance of the next epoch.

T+P-1MSL - Start accepting new Sphinx packets encrypted to

the next epoch’s keys.

T+P+1MSL - Stop accepting new Sphinx packets encrypted to

the previous epoch’s keys, close connections to
peers no longer listed in the PKI documents and
erase the list of seen packet tags.

As it stands, mixes have ~1.5 hours to publish, the PKI has ~1 hour
to vote, and the mixes have 20 mins to establish connections before
there is network connectivity failure.

Mix layer changes are controlled by the Directory Authorities and
therefore a mix can be reassigned to a different layer in our
stratified topology at any new epoch. Mixes will maintain incoming
and outgoing connections to the various nodes until all mix keys
have expired, iff the node is still listed anywhere in the current
document.

In our Directory Authority protocol, all the actors conduct their
behavior according to a common schedule as outlined in section “2.1
PKI Protocol Schedule”. The Directory Authority servers exchange
messages to reach consensus about the network. Other tasks they
perform include collecting mix descriptor uploads from each mix for
each key rotation epoch, voting, shared random number generation,
signature exchange and publishing of the network consensus documents.

Mixes MUST compose mix descriptors which are signed using their
private identity key, an ed25519 key. Directories are signed by one
or more Directory Authority servers using their authority key, also
an ed25519 key. In all cases, signing is done using JWS [RFC7515].

As described in section “2.1 PKI Protocol Schedule”, the Directory
Authority servers begin the voting process 2 hours after epoch
beginning. Each Authority exchanges vote directory messages with
each other.

Authorities archive votes from other authorities and make them
available for retreival. Upon receiving a new vote, the authority
examines it for new descriptors and includes any valid descriptors
in its view of the network.

Each Authority includes in its vote a hashed value committing to a choice of
a random number for the vote. See section 4.3 for more details.

3.2.1 Voting Wire Protocol Commands

The Katzenpost Wire Protocol as described in [KATZMIXWIRE] is used
by Authorities to exchange votes. We define additional wire
protocol commands for sending votes:

The get_consensus command is used to send a PKI document to a peer
Authority during the voting period of the PKI schedule.

The payload field contains the signed and serialized PKI document
representing the sending Authority’s vote. The public_key field
contains the public identity key of the sending Authority which the
receiving Authority can use to verify the signature of the payload.
The epoch_number field is used by the receiving party to quickly
check the epoch for the vote before deserializing the payload.

Each authority MUST include its commit value for the
shared random computation in this phase along with its signed vote.
This computation is derived from the Tor Shared Random Subsystem,
[TORSRV].

3.2.3 The vote_status Command

The vote_status command is used to reply to a vote command. The
error_code field indicates if there was a failure in the receiving
of the PKI document.

The epoch_number field of the vote struct is compared with the
epoch that is currently being voted on. vote_too_early and
vote_too_late are replied back to the voter to report that their
vote was not accepted.

As described in section “2.1 PKI Protocol Schedule”, the Directory
Authority servers exchange the reveal values after they have exchanged
votes which contain a commit value. Each Authority exchanges reveal
messages with each other.

3.3.1 Reveal Wire Protocol Commands

The Katzenpost Wire Protocol as described in [KATZMIXWIRE] is used by Authorities to exchange reveal values previously commited to in their votes. We define additional wire protocol commands for exchanging reveals:

The reveal command is used to send a reveal value to a peer authority during
the reveal period of the PKI schedule.

The payload field contains the signed and serialized reveal value. The
public_key field contains the public identity key o fthe sending Authority
which the receiving Authority can use to verify the signature of the
payload. The epoch_number field is used by the receiving party to quickly
check the epoch for the reveal before deserializing the payload.

3.3.3 The reveal_status Command

The reveal_status command is used to reply to a reveal command. The
error_code field indicates if there was a failure in the receiving of
the shared random reveal value.

The epoch_number field of the reveal struct is compared with the epoch
that is currently being voted on. reveal_too_early and reveal_too_late
are replied back to the autohrity to report their reveal was not
accepted. The status code reveal_not_authorized is used if the
Authority is rejected. The reveal_already_received is used to
report that a valid reveal command was already received for this
round.

The main design constraint of the vote tabulation algorithm is that
it MUST be a deterministic process that produces the same result
for each directory authority server. This result is known as a
network consensus file.

A network consensus file is a well formed directory struct where
the status field is set to consensus and contains 0 or more
descriptors, the mix directory is signed by 0 or more directory
authority servers. If signed by the full voting group then this is
called a fully signed consensus.

Validate each vote directory:
- that the liveness fields correspond to the following epoch
- status is vote
- version number matches ours

Each Authority exchanges their newly generated consensus files with
each other. Upon receiving signed consensus documents from the
other Authorities, peer signatures are appended to the current
local consensus file if the signed contents match. The Authority
SHOULD warn the administrator if network partition is detected.

If there is disagreement about the consensus directory, each
authority collects signatures from only the servers which it agrees
with about the final consensus.

Note that there is no signature field. This is because mix
descriptors are serialized and signed using JWS. The
IdentityKey field is a public ed25519 key. The MixKeys field
is a map from epoch to public X25519 keys which is what the Sphinx
packet format uses.

Each voting round a commit value is included in the votes sent to other authorities. These are produced as follows:

H = SHA3-256

COMMIT = Uint64(epoch) | H(REVEAL)
REVEAL = Uint64(epoch) | H(RN)

After the votes are collected from the voting round, and before signature exchange, the Shared Random Value field of the consensus document is the output of H over the input string calculated as follows:

Validated Reveal commands received including the authorities own reveal

are sorted by reveal value in ascending order and appended to the input
in format IdentityPublicKeyBytes_n | RevealValue_n

If a SharedRandomValue for the previous epoch exists, it is appended to

The Katzenpost Wire Protocol as described in [KATZMIXWIRE] is used
by both clients and by Directory Authority peers. In the following
section we describe additional wire protocol commands for publishing
mix descriptors, voting and consensus retrieval.

The get_consensus command is used to send a PKI document to a peer
Authority during the voting period of the PKI schedule.

The payload field contains the signed and serialized PKI document
representing the sending Authority’s vote. The public_key field
contains the public identity key of the sending Authority which the
receiving Authority can use to verify the signature of the payload.
The epoch_number field is used by the receiving party to quickly
check the epoch for the vote before deserializing the payload.

The vote_status command is used to reply to a vote command. The
error_code field indicates if there was a failure in the receiving
of the PKI document.

enum{vote_ok(0),/* None error condition. */vote_too_early(1),/* The Authority should try again later. */vote_too_late(2),/* This round of voting was missed. */vote_not_authorized(3),/* The voter's key is not white-listed */vote_not_signed(4),/* The vote signature verification failed */vote_malformed(5),/* The vote payload was invalid */vote_already_received(6),/* The vote was already received */vote_not_found(7),/* The vote was not found */}

The epoch_number field of the vote struct is compared with the
epoch that is currently being voted on. vote_too_early and
vote_too_late are replied back to the voter to report that their
vote was not accepted.

The get_vote command is used to request a PKI document (vote) from a peer
Authority. The epoch field contains the epoch from which to request the
vote, and the public_key field contains the public identity key of the
Authority of the requested vote. A successful query is responded to with a
vote command, and queries that fail are responded to with a vote_status
command with error_code vote_not_found(7).

The get_consensus command is a command that is used to retrieve a
recent consensus document. If a given get_consensus command
contains an Epoch value that is either too big or too small then a
reply consensus command is sent with an empty payload. Otherwise if
the consensus request is valid then a consensus command containing
a recent consensus document is sent in reply.

Initiators MUST terminate the session immediately upon reception of
a get_consensus command.

The consensus command is a command that is used to send a
recent consensus document. The error_code field indicates if there
was a failure in retrieval of the PKI consensus document.

enum{consensus_ok(0),/* None error condition and SHOULD be accompanied with a valid consensus payload. */consensus_not_found(1),/* The client should try again later. */consensus_gone(2),/* The consensus will not be available in the future. */}ErrorCodes;

This system is intentionally designed to provide identical
network consensus documents to each mix client. This mitigates
epistemic attacks against the client path selection algorithm
such as fingerprinting and bridge attacks [FINGERPRINTING][BRIDGING].

If consensus has failed and thus there is more than one consensus
file, clients MUST NOT use this compromised consensus and refuse
to run.

We try to avoid randomizing the topology because doing so splits
the anonymity sets on each mix into two. That is, packets belonging
to the previous topology versus the current topology are trivially
distinguishable. On the other hand if enough mixes fall out of
consensus eventually the mixnet will need to be rebalanced to avoid
an attacker compromised path selection. One example of this would
be the case where the adversary controls the only mix is one
layer of the network topology.

The Directory Authority/PKI system for a given mix network is
essentially the root of all authority in the system. The PKI
controls the contents of the network consensus documents that mix
clients download and use to inform their path selection.
Therefore if the PKI as a whole becomes compromised then so will
the rest of the system in terms of providing the main security
properties described as traffic analysis resistance. Therefore a
decentralized voting protocol is used so that the system is more
resiliant when attacked, in accordance with the principle of
least authority. [SECNOTSEP]

Short epoch durations make it is more practical to make
corrections to network state using the PKI voting rounds.

Fewer epoch keys published in advance is a more conservative
security policy because it implies reduced exposure to key
compromise attacks.

A bad acting Directory Authority who lies on each vote and votes
inconsistently can trivially cause a denial of service for each
voting round.