Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Draft: Wire protocol (DEP) #8

Merged
merged 23 commits into from
Feb 27, 2019
Merged
Changes from 1 commit
Commits
Show all changes
23 commits
Select commit Hold shift + click to select a range
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Prev Previous commit
Next Next commit
wire protocol typos
  • Loading branch information
bnewbold committed Jan 20, 2019
commit db2bd3908dd45b641ccf586b9dc7bddc235d3058
8 changes: 4 additions & 4 deletions proposals/0000-wire-protocol.md
Original file line number Diff line number Diff line change
Expand Up @@ -54,7 +54,7 @@ To initiate a new channel (after the primary is established), a peer can send a
## Handshake Procedure
[handshake]: #handshake

A handshake procedure needs to occur for each feed on a channel; the first part of the first handshake happens in cleartext and both validates discovery keys and establishes encyption parameters used for the rest of the connection. The first (primary) channel has `id=0`.
A handshake procedure needs to occur for each feed on a channel; the first part of the first handshake happens in cleartext and both validates discovery keys and establishes encryption parameters used for the rest of the connection. The first (primary) channel has `id=0`.

The first (cleartext) message is a Feed message, and includes two fields: a nonce and a discovery key.

Expand Down Expand Up @@ -121,7 +121,7 @@ Each extension is capable of sending custom payloads through the Extension messa
# Message Details
[message-details]: #message-details

The connection between peers is an endless stream of bytes, so each message must be "framed" so the recipient knows when it starts and ends. The wire framing format is `<len>(<header><message>)`. `len` is a varint with the number of bytes in the following message (the sum of the `header` and `message`). `header` is a varint, of form `channel << 4 | <4-bit-type>`. Note that in most cases the `header` varint will be a single byte, but clients should treat it as a varint to accomodate large channel counts.
The connection between peers is an endless stream of bytes, so each message must be "framed" so the recipient knows when it starts and ends. The wire framing format is `<len>(<header><message>)`. `len` is a varint with the number of bytes in the following message (the sum of the `header` and `message`). `header` is a varint, of form `channel << 4 | <4-bit-type>`. Note that in most cases the `header` varint will be a single byte, but clients should treat it as a varint to accommodate large channel counts.

Messages are encoded (serialized) using Google's [protobuf][protobuf] encoding.

Expand Down Expand Up @@ -435,13 +435,13 @@ A "persistent" (all-seeing) observer can infer the following with reasonable con

Such an observer can not determine the specific content of hypercore feeds, or (with confidence) which peer (or peers) have write access to a feed.

The wire protocol does not pad message sizes. This means that a persistent observer could potentially identify traffic content by infering message sizes.
The wire protocol does not pad message sizes. This means that a persistent observer could potentially identify traffic content by inferring message sizes.

The hypercore protocol does not intentionally identify peers across connections, but it has been shown that even the smallest amount of identifying metadata can be used, statistically, to track and surveil users. These techniques are sometimes called "device fingerprints", "browser fingerprints", or "permacookies". Hypercore protocol users should not consider themselves immune to such tracking without specific additional effort to identify and mitigate such fingerprints.

Any network observer with the public key can fully decrypt the network traffic of *any* and *all* peers establishing a connection using that key. This includes channel content other than the first (discovery) channel. Peers should not consider extension messages, "Have"/"Want" metadata, or any other messages or metadata private from other peers (or observers) with the public key.

The wire protocol encryption provides message *secrecy* (from parties who do not have the public key), but does not guarantee any form of *authenticity*. In the case of Dat and hypercore, the application layer itself verifies authenticity of transfered content using hashes and signatures. However, implementors should note that network agents who can manipulate traffic can modify data in flight without detection, regardless of whether they have the feed public key. However, peers are already not trusted parties, and thus implementors must already take care to treat protocol messages as potentially hostile input.
The wire protocol encryption provides message *secrecy* (from parties who do not have the public key), but does not guarantee any form of *authenticity*. In the case of Dat and hypercore, the application layer itself verifies authenticity of transferred content using hashes and signatures. However, implementors should note that network agents who can manipulate traffic can modify data in flight without detection, regardless of whether they have the feed public key. However, peers are already not trusted parties, and thus implementors must already take care to treat protocol messages as potentially hostile input.

The issues of observer decryption and message authenticity may be addressed in a future revision of the wire protocol.

Expand Down