status-im
/
eth2.0-specs
mirror of https://github.com/status-im/eth2.0-specs.git
2
0
Fork 0
Code Issues Projects Releases Wiki Activity

Update faq for tls 

we're not using tls1.3 (yet?)
This commit is contained in:
Jacek Sieka 2020-07-03 10:47:17 +02:00
parent 52582662f1
commit 30e0438d49
No known key found for this signature in database
GPG Key ID: A1B09461ABB656B8
1 changed files with 6 additions and 6 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

12
specs/phase0/p2p-interface.md
View File

@ -64,7 +64,7 @@ It consists of four main sections:
- [What is the difference between connection-level and stream-level protocol negotiation?](#what-is-the-difference-between-connection-level-and-stream-level-protocol-negotiation)
- [Encryption](#encryption)
- [Why are we not supporting SecIO?](#why-are-we-not-supporting-secio)
- [Why are we using Noise/TLS 1.3?](#why-are-we-using-noisetls-13)
- [Why are we using Noise?](#why-are-we-using-noise)
- [Why are we using encryption at all?](#why-are-we-using-encryption-at-all)
- [Gossipsub](#gossipsub)
- [Why are we using a pub/sub algorithm for block and attestation propagation?](#why-are-we-using-a-pubsub-algorithm-for-block-and-attestation-propagation)
@ -778,6 +778,10 @@ Clients can adopt new transports without breaking old ones, and the multi-transp
The QUIC standard is still not finalized (at working draft 22 at the time of writing), and not all mainstream runtimes/languages have mature, standard, and/or fully-interoperable [QUIC support](https://github.com/quicwg/base-drafts/wiki/Implementations). One remarkable example is node.js, where the QUIC implementation is [in early development](https://github.com/nodejs/quic).
*Note*: [TLS 1.3 is a prerequisite of the QUIC transport](https://tools.ietf.org/html/draft-ietf-quic-transport-22#section-7), although an experiment exists to integrate Noise as the QUIC crypto layer: [nQUIC](https://eprint.iacr.org/2019/028).
On the other hand, TLS 1.3 is the newest, simplified iteration of TLS. Old, insecure, obsolete ciphers and algorithms have been removed, adopting Ed25519 as the sole ECDH key agreement function. Handshakes are faster, 1-RTT data is supported, and session resumption is a reality, amongst other features.
## Multiplexing
### Why are we using mplex/yamux?
@ -826,7 +830,7 @@ Although SecIO has wide language support, we won’t be using it for mainnet bec
SecIO is not considered secure for the purposes of this spec.
### Why are we using Noise/TLS 1.3?
### Why are we using Noise?
Copied from the Noise Protocol Framework [website](http://www.noiseprotocol.org):
@ -836,10 +840,6 @@ Noise in itself does not specify a single handshake procedure, but provides a fr
Noise handshakes are lightweight and simple to understand, and are used in major cryptographic-centric projects like WireGuard, I2P, and Lightning. [Various](https://www.wireguard.com/papers/kobeissi-bhargavan-noise-explorer-2018.pdf) [studies](https://eprint.iacr.org/2019/436.pdf) have assessed the stated security goals of several Noise handshakes with positive results.
On the other hand, TLS 1.3 is the newest, simplified iteration of TLS. Old, insecure, obsolete ciphers and algorithms have been removed, adopting Ed25519 as the sole ECDH key agreement function. Handshakes are faster, 1-RTT data is supported, and session resumption is a reality, amongst other features.
*Note*: [TLS 1.3 is a prerequisite of the QUIC transport](https://tools.ietf.org/html/draft-ietf-quic-transport-22#section-7), although an experiment exists to integrate Noise as the QUIC crypto layer: [nQUIC](https://eprint.iacr.org/2019/028).
### Why are we using encryption at all?
Transport level encryption secures message exchange and provides properties that are useful for privacy, safety, and censorship resistance. These properties are derived from the following security guarantees that apply to the entire communication between two peers: