Begin writing a new explanation of channels.

1 files changed, 62 insertions, 1 deletions

diff --git a/spec/tor-spec/channels.md b/spec/tor-spec/channels.md
index 60b871d..6cd0ef6 100644
--- a/spec/tor-spec/channels.md
+++ b/spec/tor-spec/channels.md
@@ -1,6 +1,67 @@
 <a id="tor-spec.txt-2"></a>
 
-# Connections{#connections}
+# Channels {#connections}
+
+A channel is a direct encrypted connection
+between two Tor relays,
+or between a client and a relay.
+
+Channels are implemented as
+[TLS](https://www.rfc-editor.org/rfc/rfc8446) sessions over TCP.
+
+Clients and relays may both open new channels;
+only a relay may be the recipient of a channel.
+
+> Historical note:
+> in some older documentation,
+> channels were sometimes called "connections".
+> This proved to be confusing,
+> and we are trying not to use the term.
+
+As part of establishing a channel,
+the responding relay will always prove cryptographic ownership
+of one or more [**relay identities**](./relay-keys.md).
+The initiator MAY prove cryptographic ownership
+of their own relay identities,
+if they have any:
+public relays SHOULD prove their identities when they initiate a channel,
+whereas clients and bridges SHOULD NOT do so.
+
+Parties should usually reuse an existing channel
+rather than opening new a channel to the same relay.
+There are exceptions here;
+we discuss them more [below](#XXXX).
+
+To open a channel,
+a client or relay must know the IP address and port
+of the target relay.
+(This is sometimes called
+the "OR address" or "OR port" for the relay.)
+In most cases, the participant will also know
+one or more expected identities for the target relay,
+and will reject the channel
+if the target relay cannot cryptographically prove
+ownership of those identities.
+
+Opening a channel is a two-step process.
+First, the initiator opens
+a new TLS session with certain properties,
+and the responding relay checks and enforces those properties.
+Then, the initiator and responder
+exchange messages over this TLS session
+in order to establish their identity or identities.
+
+> Historical note:
+> In this section we will describe only the current handshake,
+> called the "v3" or "in-protocol" handshake,
+> first introduced in Tor 0.2.3.6-alpha.
+> There are two earlier variations,
+> now obsolete,
+> which we will explain [elsewhere](#XXXX).
+
+
+<!-- TODO: Revise the rest of this section. -->
+
 
 Connections between two Tor relays, or between a client and a relay,
 use TLS/SSLv3 for link authentication and encryption.  All