From 0dc29927179c3deb465f668dd022b5da2b4db57a Mon Sep 17 00:00:00 2001 From: Cole Brown Date: Wed, 24 Oct 2018 21:36:40 +0300 Subject: [PATCH 01/10] Initial transcription work --- secio/README.md | 55 +++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 55 insertions(+) create mode 100644 secio/README.md diff --git a/secio/README.md b/secio/README.md new file mode 100644 index 000000000..2cd3ef52b --- /dev/null +++ b/secio/README.md @@ -0,0 +1,55 @@ +# SECIO 1.0.0 + +> A stream security transport for libp2p. Streams wrapped by SECIO use secure +> sessions to encrypt all traffic. + +## Authors + +- [Juan Benet](https://github.com/jbenet) (October, 2015) + +## Editors + +- [Cole Brown](https://github.com/bigs) +- [Lars Gierth](https://github.com/lgierth) + +## Implementations + +- [js-libp2p-secio](https://github.com/libp2p/js-libp2p-secio) +- [go-secio](https://github.com/libp2p/go-libp2p-secio) + +## Table of Contents + +- [Algorithm Support](#algorithm-support) + +## Algorithm Support + +SECIO allows participating peers to support a subset of the following +algorithms. + +### Exhchanges + +- P-256 +- P-384 +- P-521 + +### Ciphers + +- AES-256 +- AES-128 +- Blowfish + +### Hashes + +- SHA-256 +- SHA-512 + +## Data Structures + +The SECIO wire protocol features two message types defined in the +[protobuf description language](https://github.com/libp2p/go-libp2p-secio/blob/master/pb/spipe.proto). +These two messages, `Propose` and `Exchange` are the only serialized types +required to implement SECIO. + +## Protocol + +### Proposal Generation From 2194c68599ed051f028507177b5350e979fae846 Mon Sep 17 00:00:00 2001 From: Cole Brown Date: Wed, 24 Oct 2018 17:35:24 -0400 Subject: [PATCH 02/10] Finish first pass of SECIO spec --- secio/README.md | 105 ++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 105 insertions(+) diff --git a/secio/README.md b/secio/README.md index 2cd3ef52b..d1f923dc9 100644 --- a/secio/README.md +++ b/secio/README.md @@ -53,3 +53,108 @@ required to implement SECIO. ## Protocol ### Proposal Generation + +SECIO channel negotiation begins with a proposal phase. Both sides generate a +proposal as follows: + +*Note: the public key should be serialized per the `Bytes` method from +[go-libp2p-crypto](https://godoc.org/github.com/libp2p/go-libp2p-crypto#Key).* + +``` +Propose{ + Rand: <16 secure random bytes>, + Pubkey: , + Exchanges: , + Ciphers: , + Hashes: , +} +``` + +Both peers serialize this message and send it over the wire. Upon deserializing +their peer's message, they verify that the pubkey matches that described by the +peer's peer ID (NOTE: this is sometimes only possible for the peer *initiating* +the connection.) If the key doesn't match the peer ID, the peer can close the +connection. If the peer doesn't know the remote peer's ID, they can compute and +store the remote peer ID for later use. + +### Determining Roles and Algorithms + +Next, the peers use a deterministic formula to compute their roles in the coming +exchanges. Each peer computes: + +``` +oh1 := sha256(concat(remotePeerPubKeyBytes, myNonce)) +oh2 := sha256(concat(myPubKeyBytes, remotePeerNonce)) +``` + +With these hashes, determine which peer's preferences to favor. This peer will +be referred to as the "preferred peer". If `oh1 == oh2`, then the peer is +communicating with itself and should return an error. If `oh1 < oh2`, use the +remote peer's preferences. If `oh1 > oh2`, prefer the local peer's preferences. + +Given our preference, we now sort through each of the `Exchanges`, `Ciphers`, +and `Hashes` provided by both peers, selecting the first item from our preferred +peer's set that is also shared by the other peer. + +### Key Exchange + +Now the peers prepare a key exchange. Both peers generate an ephemeral key based +on the agreed upon exchange (currently support is only available for elliptic +curve algorithms). Ephemeral keys are generated via +[go-libp2p-crypto](https://godoc.org/github.com/libp2p/go-libp2p-crypto#GenerateEKeyPair). + +With keys generated, both peers create a `Exchange` message. First, they start by +generating a "corpus" that they will sign. + +``` +corpus := concat(myProposalBytes, remotePeerProposalBytes, ephemeralPubKey) +``` + +Then, generate the `Exchange`: + +``` +Exchange{ + Epubkey: , + Signature: , +} +``` + +The peers serialize these and write them over the wire. Upon receiving the +remote peer's `Exchange`, validate the signature by computing the `corpus` you +expect them to have generated with their public key. Peers should close the +connection if the signature does not validate. + +### Key Stretching + +Peers now generate their shared secret based on the function generated by the +ephemeral key generation, passing it the remote peer's ephemeral key. With the +shared secret generated, both peers stretch the key using the algorithm +described by +[go-libp2p-crypto](https://godoc.org/github.com/libp2p/go-libp2p-crypto#KeyStretcher). + +``` +k1, k2 := KeyStretcher(sharedSecret) +``` + +With `k1` and `k2` computed, swap the two values if the remote peer is the +preferred peer. After swapping if necessary, `k1` becomes the local peer's key +and `k2` the remote peer's key. + +Each peer now generates a MAC key and cipher for the remote and local keys +generated in the previous step using the `MacKey` and `CipherKey` from the +generated +[`StretchedKeys`](https://godoc.org/github.com/libp2p/go-libp2p-crypto#StretchedKeys) +objects. + +### Initiate Secure Channel + +With the cipher and HMAC signer created, the secure channel is ready to be +opened. Each packet is of the form: + +``` +[uint32 length of packet | encrypted body | hmac signature of encrypted body] +``` + +The first packet transmitted by each peer must be the remote peer's nonce. Peers +validate that the remote peer sent them their nonce, closing if unsuccessful. +Otherwise, a secure channel has been successfully opened. From 3497da6aa5372b08cbfec8e2c3a56835c03e5a62 Mon Sep 17 00:00:00 2001 From: Yusef Napora Date: Thu, 9 May 2019 12:20:40 -0400 Subject: [PATCH 03/10] address review feedback --- secio/README.md | 234 +++++++++++++++++++++++++++++++++++++----------- 1 file changed, 180 insertions(+), 54 deletions(-) diff --git a/secio/README.md b/secio/README.md index d1f923dc9..ee7a230eb 100644 --- a/secio/README.md +++ b/secio/README.md @@ -11,11 +11,13 @@ - [Cole Brown](https://github.com/bigs) - [Lars Gierth](https://github.com/lgierth) +- [Yusef Napora](https://github.com/yusefnapora) ## Implementations - [js-libp2p-secio](https://github.com/libp2p/js-libp2p-secio) - [go-secio](https://github.com/libp2p/go-libp2p-secio) +- [rust-libp2p](https://github.com/libp2p/rust-libp2p/tree/master/protocols/secio) ## Table of Contents @@ -26,7 +28,9 @@ SECIO allows participating peers to support a subset of the following algorithms. -### Exhchanges +### Exchanges + +The following elliptic curves are used for ephemeral key generation: - P-256 - P-384 @@ -34,48 +38,87 @@ algorithms. ### Ciphers +The following symmetric ciphers are used for encryption of messages once +the SECIO channel is established: + - AES-256 - AES-128 -- Blowfish + +Note that current versions of `go-libp2p` support the Blowfish cipher, however +support for Blowfish will be dropped in future releases and should not be +considered part of the SECIO spec. ### Hashes -- SHA-256 -- SHA-512 +The following hash algorithms are used for key stretching and for HMACs once +the SECIO channel is established: + +- SHA256 +- SHA512 ## Data Structures -The SECIO wire protocol features two message types defined in the -[protobuf description language](https://github.com/libp2p/go-libp2p-secio/blob/master/pb/spipe.proto). +The SECIO wire protocol features two message types defined in the version 2 syntax of the +[protobuf description language](https://developers.google.com/protocol-buffers/docs/proto). + +```protobuf +syntax = "proto2"; + +message Propose { + optional bytes rand = 1; + optional bytes pubkey = 2; + optional string exchanges = 3; + optional string ciphers = 4; + optional string hashes = 5; +} + +message Exchange { + optional bytes epubkey = 1; + optional bytes signature = 2; +} +``` + + These two messages, `Propose` and `Exchange` are the only serialized types required to implement SECIO. ## Protocol +### Prerequisites + +Prior to undertaking the SECIO handshake described below, it is assumed that +we have already established a dedicated bidirectional channel between both +parties, and that both have agreed to proceed with the SECIO handshake +using [multistream-select][multistream-select] or some other form of protocol +negotiation. + +### Message framing + +All messages sent over the wire are prefixed with the message length in bytes, +encoded as an unsigned variable length integer as defined by the +[multiformats unsigned-varint spec][unsigned-varint]. + ### Proposal Generation -SECIO channel negotiation begins with a proposal phase. Both sides generate a -proposal as follows: +SECIO channel negotiation begins with a proposal phase. -*Note: the public key should be serialized per the `Bytes` method from -[go-libp2p-crypto](https://godoc.org/github.com/libp2p/go-libp2p-crypto#Key).* +Each side will construct a `Propose` protobuf message (as defined [above](#data-structures)), +setting the fields as follows: -``` -Propose{ - Rand: <16 secure random bytes>, - Pubkey: , - Exchanges: , - Ciphers: , - Hashes: , -} -``` +| field | value | +|-------------|--------------------------------------------------------------------------------------| +| `rand` | A 16 byte random nonce, generated using the most secure means available | +| `pubkey` | The sender's public key, serialized [as described in the peer-id spec][peer-id-spec] | +| `exchanges` | A list of supported [key exchanges](#exchanges) as a comma-separated string | +| `ciphers` | A list of supported [ciphers](#ciphers) as a comma-separated string | +| `hashes` | A list of supported [hashes](#hashes) as a comma-separated string | + + +Both parties serialize this message and send it over the wire. If either party +has prior knowledge of the other party's peer id, they may attempt to validate +that the given public key can be used to generate the same peer id, and may +close the connection if there is a mismatch. -Both peers serialize this message and send it over the wire. Upon deserializing -their peer's message, they verify that the pubkey matches that described by the -peer's peer ID (NOTE: this is sometimes only possible for the peer *initiating* -the connection.) If the key doesn't match the peer ID, the peer can close the -connection. If the peer doesn't know the remote peer's ID, they can compute and -store the remote peer ID for later use. ### Determining Roles and Algorithms @@ -87,21 +130,24 @@ oh1 := sha256(concat(remotePeerPubKeyBytes, myNonce)) oh2 := sha256(concat(myPubKeyBytes, remotePeerNonce)) ``` +Where `myNonce` is the `rand` component of the local peer's `Propose` message, +and `remotePeerNonce` is the `rand` field from the remote peer's proposal. + With these hashes, determine which peer's preferences to favor. This peer will be referred to as the "preferred peer". If `oh1 == oh2`, then the peer is communicating with itself and should return an error. If `oh1 < oh2`, use the remote peer's preferences. If `oh1 > oh2`, prefer the local peer's preferences. -Given our preference, we now sort through each of the `Exchanges`, `Ciphers`, -and `Hashes` provided by both peers, selecting the first item from our preferred +Given our preference, we now sort through each of the `exchanges`, `ciphers`, +and `hashes` provided by both peers, selecting the first item from our preferred peer's set that is also shared by the other peer. ### Key Exchange -Now the peers prepare a key exchange. Both peers generate an ephemeral key based -on the agreed upon exchange (currently support is only available for elliptic -curve algorithms). Ephemeral keys are generated via -[go-libp2p-crypto](https://godoc.org/github.com/libp2p/go-libp2p-crypto#GenerateEKeyPair). +Now the peers prepare a key exchange. + +Both peers generate an ephemeral keypair using the elliptic curve algorithm that was +chosen from the proposed `exchanges` in the previous step. With keys generated, both peers create a `Exchange` message. First, they start by generating a "corpus" that they will sign. @@ -110,41 +156,112 @@ generating a "corpus" that they will sign. corpus := concat(myProposalBytes, remotePeerProposalBytes, ephemeralPubKey) ``` -Then, generate the `Exchange`: +The `corpus` is then signed using the permanent private key associated with the local +peer's peer id, producing a byte array `signature`. + + +| field | value | +|-------------|---------------------------------------------------------------------------| +| `epubkey` | The ephemeral public key, marshaled as described [below](#key-marshaling) | +| `signature` | The `signature` of the `corpus` described above | -``` -Exchange{ - Epubkey: , - Signature: , -} -``` -The peers serialize these and write them over the wire. Upon receiving the -remote peer's `Exchange`, validate the signature by computing the `corpus` you -expect them to have generated with their public key. Peers should close the -connection if the signature does not validate. +The peers serialize their `Exchange` messages and write them over the wire. Upon +receiving the remote peer's `Exchange`, the local peer will compute the remote peer's +expected `corpus` using the known proposal bytes and the ephemeral public key sent by +the remote peer in the `Exchange`. The `signature` can then be validated using the +permanent public key of the remote peer obtained in the initial `Proposal`. + +Peers MUST close the connection if the signature does not validate. + +#### Key marshaling + +Within the `Exchange` message, ephemeral public keys are marshaled into the +uncompressed form specified in section 4.3.6 of ANSI X9.62. + +This is the behavior provided by the go standard library's +[`elliptic.Marshal`](https://golang.org/pkg/crypto/elliptic/#Marshal) function. + +### Shared Secret Generation + +Peers now generate their shared secret by combining their ephemeral private key with the +remote peer's ephemeral public key. + +First, the remote ephemeral public key is unmarshaled into a point on the elliptic curve +used in the agreed-upon exchange algorithm. If the point is not valid for the agreed-upon +curve, secret generation fails and the connection must be closed. + +The remote ephemeral public key is then combined with the local ephemeral private key +by means of elliptic curve scalar multiplication. The result of the multiplication is +the shared secret, which will then be stretched to produce MAC and cipher keys, as +described in the next section. ### Key Stretching -Peers now generate their shared secret based on the function generated by the -ephemeral key generation, passing it the remote peer's ephemeral key. With the -shared secret generated, both peers stretch the key using the algorithm -described by -[go-libp2p-crypto](https://godoc.org/github.com/libp2p/go-libp2p-crypto#KeyStretcher). +The key stretching process uses an HMAC algorithm to derive encryption and MAC keys +and a stream cipher initialization vector from the shared secret. + +Key stretching produces the following three values for each peer: + +- A MAC key used to initialize an HMAC algorithm for message verification +- A cipher key used to initialize a block cipher +- An initialization vector (IV), used to generate a CTR stream cipher from the block cipher + +The key stretching function will return two data structures `k1` and `k2`, each containing +the three values above. + +Before beginning the stretching process, the size of the IV and cipher key are determined +according to the agreed-upon cipher algorithm. The sizes (in bytes) used are as follows: + +| cipher type | cipher key size | IV size | +|-------------|-----------------|---------| +| AES-128 | 16 | 16 | +| AES-256 | 32 | 16 | + +The generated MAC key will always have a size of 20 bytes. + +Once the sizes are known, we can compute the total size of the output we need to generate +as `outputSize := 2 * (ivSize + cipherKeySize + macKeySize)`. + +The stretching algorithm will then proceed as follows: + +First, an HMAC instance is initialized using the agreed upon hash function and shared secret. + +A fixed seed value of `"key expansion"` (encoded into bytes as UTF-8) is fed into the HMAC +to produce an initial digest `a`. + +Then, the following process repeats until `outputSize` bytes have been generated: + +- reset the HMAC instance or generate a new one using the same hash function and shared secret +- compute digest `b` by feeding `a` and the seed value into the HMAC: + - `b := hmac_digest(concat(a, "key expansion"))` +- append `b` to previously generated output (if any). + - if, after appending `b`, the generated output exceeds `outputSize`, the output is truncated to `outputSize` and generation ends. +- reset the HMAC and feed `a` into it, producing a new value for `a` to be used in the next iteration + - `a = hmac_digest(a)` +- repeat until `outputSize` is reached + +Having generated `outputSize` bytes, the output is then split into six parts to +produce the final return values `k1` and `k2`: ``` -k1, k2 := KeyStretcher(sharedSecret) +| k1.IV | k1.CipherKey | k1.MacKey | k2.IV | k2.CipherKey | k2.MacKey | ``` +The size of each field is determined by the cipher key and IV sizes detailed above. + +### Creating the Cipher and HMAC signer + With `k1` and `k2` computed, swap the two values if the remote peer is the preferred peer. After swapping if necessary, `k1` becomes the local peer's key and `k2` the remote peer's key. -Each peer now generates a MAC key and cipher for the remote and local keys -generated in the previous step using the `MacKey` and `CipherKey` from the -generated -[`StretchedKeys`](https://godoc.org/github.com/libp2p/go-libp2p-crypto#StretchedKeys) -objects. +Each peer now generates an HMAC signer using the agreed upon algorithm and the +`MacKey` produced by the key stretcher. + +Each peer will also initialize the agreed-upon block cipher using the generated +`CipherKey`, and will then initialize a CTR stream cipher from the block cipher +using the generated initialization vector `IV`. ### Initiate Secure Channel @@ -157,4 +274,13 @@ opened. Each packet is of the form: The first packet transmitted by each peer must be the remote peer's nonce. Peers validate that the remote peer sent them their nonce, closing if unsuccessful. -Otherwise, a secure channel has been successfully opened. + +If both peers successfully validate the initial packet, the secure channel has +been opened and is ready for use. + + + +[peer-id-spec]: https://github.com/libp2p/specs/peer-ids/peer-ids.md + +[multistream-select]: https://github.com/multiformats/multistream-select +[unsigned-varint]: https://github.com/multiformats/unsigned-varint From 029798f088e8c95c2be49e2147e65b975cc6662e Mon Sep 17 00:00:00 2001 From: Yusef Napora Date: Thu, 9 May 2019 12:25:31 -0400 Subject: [PATCH 04/10] generate TOC --- secio/README.md | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/secio/README.md b/secio/README.md index ee7a230eb..812f99ad9 100644 --- a/secio/README.md +++ b/secio/README.md @@ -21,7 +21,28 @@ ## Table of Contents -- [Algorithm Support](#algorithm-support) +- [SECIO 1.0.0](#secio-100) + - [Authors](#authors) + - [Editors](#editors) + - [Implementations](#implementations) + - [Table of Contents](#table-of-contents) + - [Algorithm Support](#algorithm-support) + - [Exchanges](#exchanges) + - [Ciphers](#ciphers) + - [Hashes](#hashes) + - [Data Structures](#data-structures) + - [Protocol](#protocol) + - [Prerequisites](#prerequisites) + - [Message framing](#message-framing) + - [Proposal Generation](#proposal-generation) + - [Determining Roles and Algorithms](#determining-roles-and-algorithms) + - [Key Exchange](#key-exchange) + - [Key marshaling](#key-marshaling) + - [Shared Secret Generation](#shared-secret-generation) + - [Key Stretching](#key-stretching) + - [Creating the Cipher and HMAC signer](#creating-the-cipher-and-hmac-signer) + - [Initiate Secure Channel](#initiate-secure-channel) + ## Algorithm Support From 0c0a2aa68bbd341bd598b0abe43f2ddfab804e76 Mon Sep 17 00:00:00 2001 From: Yusef Napora Date: Thu, 9 May 2019 13:50:58 -0400 Subject: [PATCH 05/10] more detail about secure packet contents & initial verification --- secio/README.md | 42 ++++++++++++++++++++++++++++++++++-------- 1 file changed, 34 insertions(+), 8 deletions(-) diff --git a/secio/README.md b/secio/README.md index 812f99ad9..e7eed1cb7 100644 --- a/secio/README.md +++ b/secio/README.md @@ -42,6 +42,8 @@ - [Key Stretching](#key-stretching) - [Creating the Cipher and HMAC signer](#creating-the-cipher-and-hmac-signer) - [Initiate Secure Channel](#initiate-secure-channel) + - [Secure Message Framing](#secure-message-framing) + - [Initial Packet Verification](#initial-packet-verification) ## Algorithm Support @@ -116,8 +118,8 @@ negotiation. ### Message framing All messages sent over the wire are prefixed with the message length in bytes, -encoded as an unsigned variable length integer as defined by the -[multiformats unsigned-varint spec][unsigned-varint]. +encoded as an unsigned variable length integer as defined +by the [multiformats unsigned-varint spec][unsigned-varint]. ### Proposal Generation @@ -128,7 +130,7 @@ setting the fields as follows: | field | value | |-------------|--------------------------------------------------------------------------------------| -| `rand` | A 16 byte random nonce, generated using the most secure means available | +| `rand` | A 16 byte random nonce, generated using the most secure means available | | `pubkey` | The sender's public key, serialized [as described in the peer-id spec][peer-id-spec] | | `exchanges` | A list of supported [key exchanges](#exchanges) as a comma-separated string | | `ciphers` | A list of supported [ciphers](#ciphers) as a comma-separated string | @@ -170,7 +172,7 @@ Now the peers prepare a key exchange. Both peers generate an ephemeral keypair using the elliptic curve algorithm that was chosen from the proposed `exchanges` in the previous step. -With keys generated, both peers create a `Exchange` message. First, they start by +With keys generated, both peers create an `Exchange` message. First, they start by generating a "corpus" that they will sign. ``` @@ -287,17 +289,41 @@ using the generated initialization vector `IV`. ### Initiate Secure Channel With the cipher and HMAC signer created, the secure channel is ready to be -opened. Each packet is of the form: +opened. + +#### Secure Message Framing + +To communicate over the channel, peers send packets containing an encrypted +body and an HMAC signature of the encrypted body. + +The encrypted body is produced by applying the stream cipher initialized +previously to an arbitrary plaintext message payload. The encrypted data +is then fed into the HMAC signer to produce the HMAC signature. + +Once the encrypted body and HMAC signature are known, they are concatenated +together, and their combined length is prefixed to the resulting payload. + +Each packet is of the form: ``` [uint32 length of packet | encrypted body | hmac signature of encrypted body] ``` -The first packet transmitted by each peer must be the remote peer's nonce. Peers -validate that the remote peer sent them their nonce, closing if unsuccessful. +The packet length is in bytes, and it is encoded as an unsigned 32-bit integer +in network (big endian) byte order. + +#### Initial Packet Verification + +The first packet transmitted by each peer must be the remote peer's nonce. + +Each peer will decrypt the message body and validate the HMAC signature, +comparing the decrypted output to the nonce recieved in the initial +`Proposal` message. If either peer is unable to validate the initial +packet against the known nonce, they must abort the connection. If both peers successfully validate the initial packet, the secure channel has -been opened and is ready for use. +been opened and is ready for use, using the framing rules described +[above](#secure-message-framing). From c73bc5d8b7cf4705f074cb098466fe6ed536318d Mon Sep 17 00:00:00 2001 From: Yusef Napora Date: Thu, 9 May 2019 14:33:21 -0400 Subject: [PATCH 06/10] small fix --- secio/README.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/secio/README.md b/secio/README.md index e7eed1cb7..e5bd9161a 100644 --- a/secio/README.md +++ b/secio/README.md @@ -193,7 +193,7 @@ The peers serialize their `Exchange` messages and write them over the wire. Upon receiving the remote peer's `Exchange`, the local peer will compute the remote peer's expected `corpus` using the known proposal bytes and the ephemeral public key sent by the remote peer in the `Exchange`. The `signature` can then be validated using the -permanent public key of the remote peer obtained in the initial `Proposal`. +permanent public key of the remote peer obtained in the initial proposal. Peers MUST close the connection if the signature does not validate. @@ -318,7 +318,7 @@ The first packet transmitted by each peer must be the remote peer's nonce. Each peer will decrypt the message body and validate the HMAC signature, comparing the decrypted output to the nonce recieved in the initial -`Proposal` message. If either peer is unable to validate the initial +`Propose` message. If either peer is unable to validate the initial packet against the known nonce, they must abort the connection. If both peers successfully validate the initial packet, the secure channel has From a7272567b18af7c92fc75142e5ce1ce158749520 Mon Sep 17 00:00:00 2001 From: Yusef Napora Date: Tue, 21 May 2019 10:49:57 -0400 Subject: [PATCH 07/10] add DRAFT status notice --- secio/README.md | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/secio/README.md b/secio/README.md index e5bd9161a..6ec9959c1 100644 --- a/secio/README.md +++ b/secio/README.md @@ -3,6 +3,11 @@ > A stream security transport for libp2p. Streams wrapped by SECIO use secure > sessions to encrypt all traffic. +## Status + +This document is a DRAFT and may be revised for clarity and precision. If you +find inaccuracies, please [file an issue.](https://github.com/libp2p/specs/issues/new) + ## Authors - [Juan Benet](https://github.com/jbenet) (October, 2015) From 9264ceac71ec109242b5aecd254e91c44f858402 Mon Sep 17 00:00:00 2001 From: Yusef Napora Date: Wed, 22 May 2019 11:06:15 -0400 Subject: [PATCH 08/10] set status to 3A and link to lifecycle doc --- secio/README.md | 16 +++++++++++++--- 1 file changed, 13 insertions(+), 3 deletions(-) diff --git a/secio/README.md b/secio/README.md index 6ec9959c1..dd3346a15 100644 --- a/secio/README.md +++ b/secio/README.md @@ -5,8 +5,19 @@ ## Status -This document is a DRAFT and may be revised for clarity and precision. If you -find inaccuracies, please [file an issue.](https://github.com/libp2p/specs/issues/new) +Status: 3A - Recommendation, Active +Last revision: 2019-05-22 + +This document is an Active Recommendation. SECIO is widely supported across +libp2p implementations, and it is the current default for connection security in +libp2p. + +See [the lifecycle +document](https://github.com/libp2p/specs/00-framework-01-spec-lifecycle.md) for +more information on spec status. + +If you find inaccuracies or room for improvment, please [file an +issue.](https://github.com/libp2p/specs/issues/new) ## Authors @@ -331,7 +342,6 @@ been opened and is ready for use, using the framing rules described [above](#secure-message-framing). - [peer-id-spec]: https://github.com/libp2p/specs/peer-ids/peer-ids.md [multistream-select]: https://github.com/multiformats/multistream-select From 2c7fe9346489283972add02d9438bb85a30f98fd Mon Sep 17 00:00:00 2001 From: Yusef Napora Date: Mon, 27 May 2019 10:47:23 -0400 Subject: [PATCH 09/10] add lifecycle header & regenerate TOC --- secio/README.md | 51 ++++++++++++++++++++----------------------------- 1 file changed, 21 insertions(+), 30 deletions(-) diff --git a/secio/README.md b/secio/README.md index dd3346a15..6373d4030 100644 --- a/secio/README.md +++ b/secio/README.md @@ -3,45 +3,31 @@ > A stream security transport for libp2p. Streams wrapped by SECIO use secure > sessions to encrypt all traffic. -## Status +| Lifecycle Stage | Maturity Level | Status | Latest Revision | +|-----------------|----------------|--------|-----------------| +| 3A | Recommendation | Active | r0, 2019-05-27 | -Status: 3A - Recommendation, Active -Last revision: 2019-05-22 +Authors: [@jbenet][@jbenet], [@bigs][@bigs], [@yusefnapora][@yusefnapora] -This document is an Active Recommendation. SECIO is widely supported across -libp2p implementations, and it is the current default for connection security in -libp2p. +Interest Group: [@Stebalien][@Stebalien], +[@richardschneider][@richardschneider], [@tomaka][@tomaka], [@raulk][@raulk] -See [the lifecycle -document](https://github.com/libp2p/specs/00-framework-01-spec-lifecycle.md) for -more information on spec status. +[@jbenet]: https://github.com/jbenet +[@bigs]: https://github.com/bigs +[@yusefnapora]: https://github.com/yusefnapora +[@Stebalien]: https://github.com/Stebalien +[@richardschneider]: https://github.com/richardschneider +[@tomaka]: https://github.com/tomaka +[@raulk]: https://github.com/raulk -If you find inaccuracies or room for improvment, please [file an -issue.](https://github.com/libp2p/specs/issues/new) - -## Authors - -- [Juan Benet](https://github.com/jbenet) (October, 2015) - -## Editors - -- [Cole Brown](https://github.com/bigs) -- [Lars Gierth](https://github.com/lgierth) -- [Yusef Napora](https://github.com/yusefnapora) - -## Implementations - -- [js-libp2p-secio](https://github.com/libp2p/js-libp2p-secio) -- [go-secio](https://github.com/libp2p/go-libp2p-secio) -- [rust-libp2p](https://github.com/libp2p/rust-libp2p/tree/master/protocols/secio) +See the [lifecycle document](../00-framework-01-spec-lifecycle.md) for context +about maturity level and spec status. ## Table of Contents - [SECIO 1.0.0](#secio-100) - - [Authors](#authors) - - [Editors](#editors) - - [Implementations](#implementations) - [Table of Contents](#table-of-contents) + - [Implementations](#implementations) - [Algorithm Support](#algorithm-support) - [Exchanges](#exchanges) - [Ciphers](#ciphers) @@ -61,6 +47,11 @@ issue.](https://github.com/libp2p/specs/issues/new) - [Secure Message Framing](#secure-message-framing) - [Initial Packet Verification](#initial-packet-verification) +## Implementations + +- [js-libp2p-secio](https://github.com/libp2p/js-libp2p-secio) +- [go-secio](https://github.com/libp2p/go-libp2p-secio) +- [rust-libp2p](https://github.com/libp2p/rust-libp2p/tree/master/protocols/secio) ## Algorithm Support From 1443ebfbd4642e0160f60255023f64b20e92e3c2 Mon Sep 17 00:00:00 2001 From: Yusef Napora Date: Mon, 27 May 2019 11:38:32 -0400 Subject: [PATCH 10/10] use shortcut reference links for authors in header --- secio/README.md | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/secio/README.md b/secio/README.md index 6373d4030..bb1aaa2aa 100644 --- a/secio/README.md +++ b/secio/README.md @@ -7,10 +7,9 @@ |-----------------|----------------|--------|-----------------| | 3A | Recommendation | Active | r0, 2019-05-27 | -Authors: [@jbenet][@jbenet], [@bigs][@bigs], [@yusefnapora][@yusefnapora] +Authors: [@jbenet], [@bigs], [@yusefnapora] -Interest Group: [@Stebalien][@Stebalien], -[@richardschneider][@richardschneider], [@tomaka][@tomaka], [@raulk][@raulk] +Interest Group: [@Stebalien], [@richardschneider], [@tomaka], [@raulk] [@jbenet]: https://github.com/jbenet [@bigs]: https://github.com/bigs