kytv/I2P_Website
1
0
Fork 0
forked from I2P_Developers/i2p.www
Code Issues Pull Requests Packages Projects Releases Wiki Activity

Proposal #111 - Improve formatting

Browse Source
This commit is contained in:
slumlord
2018-04-04 13:54:03 +00:00
parent a1571dd9fa
commit b4f17d3ca0
1 changed files with 410 additions and 393 deletions
Download Patch File Download Diff File Expand all files Collapse all files

447
i2p2www/spec/proposals/111-ntcp-2.rst
View File

@@ -6,7 +6,7 @@ NTCP 2
:editor: manas, str4d :editor: manas, str4d
:created: 2014-02-13 :created: 2014-02-13
:thread: http://zzz.i2p/topics/1577 :thread: http://zzz.i2p/topics/1577
:lastupdated: 2018-04-02 :lastupdated: 2018-04-04
:status: Open :status: Open
:supercedes: 106 :supercedes: 106
@@ -15,8 +15,8 @@ NTCP 2
Note Note
==== ====
Major revisions in progress. For now, not necessarily complete or even consistent. Major revisions in progress. For now, not necessarily complete or even
Not ready for implementation. consistent. Not ready for implementation.
Overview Overview
@@ -36,19 +36,19 @@ candidates for the authenticated cipher.
Motivation Motivation
========== ==========
[NTCP]_ data is encrypted after the first message (and the first message appears [NTCP]_ data is encrypted after the first message (and the first message
to be random data), thus preventing protocol identification through "payload appears to be random data), thus preventing protocol identification through
analysis". It is still vulnerable to protocol identification through "flow "payload analysis". It is still vulnerable to protocol identification through
analysis". That's because the first 4 messages (i.e. the handshake) are fixed "flow analysis". That's because the first 4 messages (i.e. the handshake) are
length (288, 304, 448, and 48 bytes). fixed length (288, 304, 448, and 48 bytes).
By adding random amounts of random data to each of the messages, we can make it By adding random amounts of random data to each of the messages, we can make it
a lot harder. a lot harder.
The authors acknowledge that standard security practices would suggest to use an The authors acknowledge that standard security practices would suggest to use
existing protocol such as TLS, but this is [Prop104]_ and it has problems of its an existing protocol such as TLS, but this is [Prop104]_ and it has problems of
own. Wherever appropriate, "future work" paragraphs have been added to indicate its own. Wherever appropriate, "future work" paragraphs have been added to
missing features or subjects of discussion. indicate missing features or subjects of discussion.
Design Goals Design Goals
@@ -76,8 +76,8 @@ Design Goals
Also ensure that the messages going to a single peer or set of peers do not Also ensure that the messages going to a single peer or set of peers do not
have a similar pattern of bits. have a similar pattern of bits.
- Fix loss of bits in DH due to Java format [Ticket1112]_, possibly - Fix loss of bits in DH due to Java format [Ticket1112]_, possibly (probably?)
(probably?) by switching to X25519. by switching to X25519.
- Switch to a real key derivation function (KDF) rather than using the DH - Switch to a real key derivation function (KDF) rather than using the DH
result as-is? result as-is?
@@ -88,9 +88,9 @@ Design Goals
for our application. for our application.
- Continue to use the variable-type, variable-length signatures (from the - Continue to use the variable-type, variable-length signatures (from the
published [RouterIdentity]_ signing key) as a part of authentication. published [RouterIdentity]_ signing key) as a part of authentication. Rely
Rely on a static public key published in the RouterInfo as another on a static public key published in the RouterInfo as another part of
part of authentication. authentication.
- Add options/version in handshake for future extensibility. - Add options/version in handshake for future extensibility.
@@ -99,8 +99,8 @@ Design Goals
- Don't add significantly to CPU required for connection setup; if possible, - Don't add significantly to CPU required for connection setup; if possible,
reduce it significantly. reduce it significantly.
- Add message authentication (MAC), possibly HMAC-SHA256 and Poly1305, - Add message authentication (MAC), possibly HMAC-SHA256 and Poly1305, and
and remove Adler checksum. remove Adler checksum.
- Shorten and simplify I2NP header: - Shorten and simplify I2NP header:
Shorten expiration to 4 bytes, as in SSU. Shorten expiration to 4 bytes, as in SSU.
@@ -131,7 +131,8 @@ Design Goals
Non-Goals Non-Goals
--------- ---------
- Bullet-proof DPI resistance... that would be pluggable transports, [Prop109]_. - Bullet-proof DPI resistance... that would be pluggable transports,
[Prop109]_.
- A TLS-based (or HTTPS-lookalike) transport... that would be [Prop104]_. - A TLS-based (or HTTPS-lookalike) transport... that would be [Prop104]_.
@@ -212,24 +213,24 @@ We assume two DPI components:
1) Online DPI 1) Online DPI
````````````` `````````````
Online DPI inspecting all flows in real-time. Connections may be blocked or otherwise Online DPI inspecting all flows in real-time. Connections may be blocked or
tampered with. Connection data or metadata may be identified and stored for offline analysis. otherwise tampered with. Connection data or metadata may be identified and
The online DPI does not have access to the I2P network database. stored for offline analysis. The online DPI does not have access to the I2P
The online DPI has only limited real-time computational capability, including length network database. The online DPI has only limited real-time computational
calculation, field inspection, and simple calculations such as XOR. capability, including length calculation, field inspection, and simple
The online DPI does have the capability of fast real-time cryptographic functions calculations such as XOR. The online DPI does have the capability of fast
such as AES, AEAD, and hashing, but these would be too expensive to apply to real-time cryptographic functions such as AES, AEAD, and hashing, but these
most or all flows. Any application of these cryptographic operations would be too expensive to apply to most or all flows. Any application of these
would apply only to flows on IP/Port combinations previously identified by offline analysis. cryptographic operations would apply only to flows on IP/Port combinations
The online DPI does not have the capability of high-overhead cryptographic functions previously identified by offline analysis. The online DPI does not have the
such as DH or elligator2. capability of high-overhead cryptographic functions such as DH or elligator2.
The online DPI is not designed specifically to detect I2P, although it may have limited The online DPI is not designed specifically to detect I2P, although it may have
classification rules for that purpose. limited classification rules for that purpose.
It is a goal to prevent protocol identification by an online DPI. It is a goal to prevent protocol identification by an online DPI.
The notion of online or "straightforward" DPI is here taken to include the following The notion of online or "straightforward" DPI is here taken to include the
adversary capabilities: following adversary capabilities:
1) The ability to inspect all data sent or received by the target. 1) The ability to inspect all data sent or received by the target.
@@ -248,11 +249,11 @@ However, the online DPI is assumed to have the following restrictions:
6) The inability to use timing information to detect the protocol. 6) The inability to use timing information to detect the protocol.
7) Generally speaking, the online DPI toolbox does not contain any built-in tools 7) Generally speaking, the online DPI toolbox does not contain any built-in
that are specifically designed for I2P detection. This includes creating tools that are specifically designed for I2P detection. This includes
"honeypots", which would for example include nonrandom padding in their creating "honeypots", which would for example include nonrandom padding in
messages. Note that this does not exclude machine learning systems or highly their messages. Note that this does not exclude machine learning systems or
configurable DPI tools as long as they meet the other requirements. highly configurable DPI tools as long as they meet the other requirements.
To counter payload analysis, it is ensured that all messages are To counter payload analysis, it is ensured that all messages are
indistinguishable from random. This also requires their length to be random, indistinguishable from random. This also requires their length to be random,
@@ -280,11 +281,11 @@ The offline DPI does have access to this and other I2P specifications.
The offline DPI has unlimited computational capability, including The offline DPI has unlimited computational capability, including
all cryptographic functions defined in this specification. all cryptographic functions defined in this specification.
The offline DPI does not have the ability to block existing connections. The offline DPI does not have the ability to block existing connections. The
The offline DPI does have the capability to do near-realtime (within minutes of setup) offline DPI does have the capability to do near-realtime (within minutes of
sending to host/port of parties, for example TCP RST. setup) sending to host/port of parties, for example TCP RST. The offline DPI
The offline DPI does have the capability to do near-realtime (within minutes of setup) does have the capability to do near-realtime (within minutes of setup) replay
replay of previous messages (modified or not) for "probing" or other reasons. of previous messages (modified or not) for "probing" or other reasons.
It is not a goal to prevent protocol identification by an offline DPI. It is not a goal to prevent protocol identification by an offline DPI.
All decoding of obfuscated data in the first two messages, which All decoding of obfuscated data in the first two messages, which
@@ -310,10 +311,10 @@ Future work
Noise Protocol Framework Noise Protocol Framework
======================== ========================
This proposal provides the requirements based on the This proposal provides the requirements based on the Noise Protocol Framework
Noise Protocol Framework [NOISE]_. Noise has similar properties to the [NOISE]_. Noise has similar properties to the Station-To-Station protocol
Station-To-Station protocol [STS]_, which is the basis for the [SSU]_ protocol. [STS]_, which is the basis for the [SSU]_ protocol. In Noise parlance, Alice
In Noise parlance, Alice is the initiator, and Bob is the responder. is the initiator, and Bob is the responder.
The Noise Protocol Identifier for NTCP2 is Noise_XK_25519_ChaChaPoly_SHA256. The Noise Protocol Identifier for NTCP2 is Noise_XK_25519_ChaChaPoly_SHA256.
This uses the following primitives: This uses the following primitives:
@@ -336,11 +337,12 @@ This uses the following primitives:
Additions to the Framework Additions to the Framework
========================== ==========================
This proposal defines the following enhancements to Noise_XK_25519_ChaChaPoly_SHA256. This proposal defines the following enhancements to
These generally follow the guidelines in [NOISE]_ section 13. Noise_XK_25519_ChaChaPoly_SHA256. These generally follow the guidelines in
[NOISE]_ section 13.
1) Cleartext ephemeral keys are obfuscated with AES encryption using a known key and IV. 1) Cleartext ephemeral keys are obfuscated with AES encryption using a known
This is quicker than elligator2. key and IV. This is quicker than elligator2.
2) Random cleartext padding is added to messages 1 and 2. 2) Random cleartext padding is added to messages 1 and 2.
The cleartext padding is included in the handshake hash calculation. The cleartext padding is included in the handshake hash calculation.
@@ -357,16 +359,16 @@ These generally follow the guidelines in [NOISE]_ section 13.
It of course is not defined in Noise. It of course is not defined in Noise.
Processing overhead estimate Processing overhead estimate
============================ ============================
Message sizes for the 3 messages: Message sizes for the 3 messages:
- 1) 64 bytes + padding (NTCP was 288 bytes) 1) 64 bytes + padding (NTCP was 288 bytes)
- 2) 56 bytes + padding (NTCP was 304 bytes) 2) 56 bytes + padding (NTCP was 304 bytes)
- 3) 66 bytes + Alice router info + padding Average router info is about 750 bytes Total average 816 bytes (NTCP was 448 bytes) 3) 66 bytes + Alice router info + padding Average router info is about 750
- 4) not required in NTCP2 (NTCP was 48 bytes) bytes Total average 816 bytes (NTCP was 448 bytes)
4) not required in NTCP2 (NTCP was 48 bytes)
Total before padding: Total before padding:
NTCP2: 936 bytes NTCP2: 936 bytes
@@ -379,12 +381,14 @@ The following crypto operations are required by each party to complete
the handshake and start the data phase: the handshake and start the data phase:
- AES: 2 - AES: 2
- SHA256: 8 (Alice), 6 (Bob) (not including 4 Alice, 6 Bob precalculated for all connections) (not including HMAC-SHA256) - SHA256: 8 (Alice), 6 (Bob) (not including 4 Alice, 6 Bob precalculated for
all connections) (not including HMAC-SHA256)
- HMAC-SHA256: 15 - HMAC-SHA256: 15
- ChaCha/Poly: 4 - ChaCha/Poly: 4
- X25519 DH: 3 - X25519 DH: 3
- SipHash: 1 - SipHash: 1
- Signature verification: 1 (Bob) (Alice previously signed when generating her RI) Presumably Ed25519 (dependent on RI sigtype) - Signature verification: 1 (Bob) (Alice previously signed when generating her
RI) Presumably Ed25519 (dependent on RI sigtype)
The following crypto operations are required by each party for each data phase message: The following crypto operations are required by each party for each data phase message:
@@ -476,7 +480,6 @@ Inputs to the encryption/decryption functions:
{% highlight lang='dataspec' %} {% highlight lang='dataspec' %}
k :: 32 byte cipher key, as generated from KDF k :: 32 byte cipher key, as generated from KDF
nonce :: Counter-based nonce, 12 bytes. nonce :: Counter-based nonce, 12 bytes.
@@ -523,8 +526,6 @@ Output of the encryption function, input to the decryption function:
encrypted data :: Same size as plaintext data encrypted data :: Same size as plaintext data
{% endhighlight %} {% endhighlight %}
For ChaCha20, what is described here corresponds to [RFC-7539]_, which is also For ChaCha20, what is described here corresponds to [RFC-7539]_, which is also
@@ -571,7 +572,8 @@ exactly as defined in the Noise spec.
This is the "e" message pattern: This is the "e" message pattern:
Define protocol_name. Define protocol_name.
Set protocol_name = "Noise_XK_25519_ChaChaPoly_SHA256" which is 32 bytes (US-ASCII encoded, no NULL termination). Set protocol_name = "Noise_XK_25519_ChaChaPoly_SHA256" which is 32 bytes
(US-ASCII encoded, no NULL termination).
Define Hash h = 32 bytes Define Hash h = 32 bytes
h = SHA256(protocol_name); h = SHA256(protocol_name);
@@ -680,17 +682,21 @@ XK(s, rs): Authentication Confidentiality
This payload may have been sent by any party, including an active attacker. This payload may have been sent by any party, including an active attacker.
Confidentiality: 2. Confidentiality: 2.
Encryption to a known recipient, forward secrecy for sender compromise only, vulnerable to replay. Encryption to a known recipient, forward secrecy for sender compromise
This payload is encrypted based only on DHs involving the recipient's static key pair. only, vulnerable to replay. This payload is encrypted based only on DHs
If the recipient's static private key is compromised, even at a later date, this payload can be decrypted. involving the recipient's static key pair. If the recipient's static
This message can also be replayed, since there's no ephemeral contribution from the recipient. private key is compromised, even at a later date, this payload can be
decrypted. This message can also be replayed, since there's no ephemeral
contribution from the recipient.
"e": Alice generates a new ephemeral key pair and stores it in the e variable, "e": Alice generates a new ephemeral key pair and stores it in the e
writes the ephemeral public key as cleartext into the message buffer, variable, writes the ephemeral public key as cleartext into the
and hashes the public key along with the old h to derive a new h. message buffer, and hashes the public key along with the old h to
derive a new h.
"es": A DH is performed between the Alice's ephemeral key pair and the Bob's static key pair. "es": A DH is performed between the Alice's ephemeral key pair and the
The result is hashed along with the old ck to derive a new ck and k, and n is set to zero. Bob's static key pair. The result is hashed along with the old ck to
derive a new ck and k, and n is set to zero.
{% endhighlight %} {% endhighlight %}
@@ -835,22 +841,21 @@ Note: All fields are big-endian.
Notes Notes
````` `````
- When the published address is "NTCP", Bob supports both NTCP and NTCP2 - When the published address is "NTCP", Bob supports both NTCP and NTCP2 on the
on the same port. For compatibility, when initiating a connection same port. For compatibility, when initiating a connection to an address
to an address published as "NTCP", Alice must limit the maximum published as "NTCP", Alice must limit the maximum size of this message,
size of this message, including padding, to 287 bytes or less. including padding, to 287 bytes or less. This facilitates automatic protocol
This facilitates automatic protocol identification by Bob. identification by Bob. When published as "NTCP2", there is no size
When published as "NTCP2", there is no size restriction. restriction. See the Published Addresses and Version Detection sections
See the Published Addresses and Version Detection sections below. below.
- The unique X value in the initial AES block ensure that the - The unique X value in the initial AES block ensure that the ciphertext is
ciphertext is different for every session. different for every session.
- Bob must reject connections where the timestamp value is too far off - Bob must reject connections where the timestamp value is too far off from the
from the current time. Call the maximum delta time "D". current time. Call the maximum delta time "D". Bob must maintain a local
Bob must maintain a local cache of previously-used handshake values cache of previously-used handshake values and reject duplicates, to prevent
and reject duplicates, to prevent replay attacks. Values in the replay attacks. Values in the cache must have a lifetime of at least 2*D.
cache must have a lifetime of at least 2*D.
The cache values are implementation-dependent, however the 32-byte X value The cache values are implementation-dependent, however the 32-byte X value
(or its encrypted equivalent) may be used. (or its encrypted equivalent) may be used.
@@ -864,28 +869,28 @@ Notes
implicitly change the meaning of the "KE" flag to use a different KDF or a implicitly change the meaning of the "KE" flag to use a different KDF or a
different truncation size. different truncation size.
- Bob must validate that Alice's ephemeral key is a valid point on the curve here. - Bob must validate that Alice's ephemeral key is a valid point on the curve
here.
- Padding should be limited to a reasonable amount. - Padding should be limited to a reasonable amount. Bob may reject connections
Bob may reject connections with excessive padding. with excessive padding. Bob will specify his padding options in message 2.
Bob will specify his padding options in message 2.
Min/max guidelines TBD. Random size from 0 to 31 bytes minimum? Min/max guidelines TBD. Random size from 0 to 31 bytes minimum?
(Distribution to be determined, see Appendix A.) (Distribution to be determined, see Appendix A.)
- On any error, including AEAD, DH, timestamp, apparent replay, or key validation failure, - On any error, including AEAD, DH, timestamp, apparent replay, or key
Bob must halt further message processing and close the connection without responding. validation failure, Bob must halt further message processing and close the
This should be an abnormal close (TCP RST). connection without responding. This should be an abnormal close (TCP RST).
- To facilitate rapid version detection and handshaking, implementations must ensure - To facilitate rapid version detection and handshaking, implementations must
that Alice buffers and then flushes the entire contents of the first message at once, ensure that Alice buffers and then flushes the entire contents of the first
including the padding. message at once, including the padding. This increases the likelihood that
This increases the likelihood that the data will be contained in a single TCP packet the data will be contained in a single TCP packet (unless segmented by the OS
(unless segmented by the OS or middleboxes), and received all at once by Bob. or middleboxes), and received all at once by Bob. Additionally,
Additionally, implementations must ensure implementations must ensure that Bob buffers and then flushes the entire
that Bob buffers and then flushes the entire contents of the second message at once, contents of the second message at once, including the padding. and that Bob
including the padding. buffers and then flushes the entire contents of the third message at once.
and that Bob buffers and then flushes the entire contents of the third message at once. This is also for efficiency and to ensure the effectiveness of the random
This is also for efficiency and to ensure the effectiveness of the random padding. padding.
Issues Issues
@@ -1003,19 +1008,16 @@ XK(s, rs): Authentication Confidentiality
{% endhighlight %} {% endhighlight %}
The Y value is encrypted to ensure payload indistinguishably The Y value is encrypted to ensure payload indistinguishably and uniqueness,
and uniqueness, which are necessary DPI countermeasures. which are necessary DPI countermeasures. We use AES encryption to achieve
We use AES encryption to achieve this, this, rather than more complex and slower alternatives such as elligator2.
rather than more complex and slower alternatives such as elligator2. Asymmetric encryption to Alice's router public key would be far too slow. AES
Asymmetric encryption to Alice's router public key would be far too slow. encryption uses Bob's router hash as the key and the AES state from message 1
AES encryption uses Bob's router hash as the key and (which was initialized with Bob's IV as published in the network database).
the AES state from message 1 (which was initialized with
Bob's IV as published in the network database).
AES encryption is for DPI resistance only. AES encryption is for DPI resistance only. Any party knowing Bob's router hash
Any party knowing Bob's router hash and IV, which are published in the network database, and IV, which are published in the network database, and captured the first 32
and captured the first 32 bytes of message 1, bytes of message 1, may decrypt the Y value in this message.
may decrypt the Y value in this message.
Raw contents: Raw contents:
@@ -1094,15 +1096,15 @@ Unencrypted data:
Notes Notes
````` `````
- Alice must reject connections where the timestamp value is too far off - Alice must reject connections where the timestamp value is too far off from
from the current time. Call the maximum delta time "D". the current time. Call the maximum delta time "D". Alice must maintain a
Alice must maintain a local cache of previously-used handshake values local cache of previously-used handshake values and reject duplicates, to
and reject duplicates, to prevent replay attacks. Values in the prevent replay attacks. Values in the cache must have a lifetime of at least
cache must have a lifetime of at least 2*D. 2*D. The cache values are implementation-dependent, however the 32-byte Y
The cache values are implementation-dependent, however the 32-byte Y value value (or its encrypted equivalent) may be used.
(or its encrypted equivalent) may be used.
- Alice must validate that Bob's ephemeral key is a valid point on the curve here. - Alice must validate that Bob's ephemeral key is a valid point on the curve
here.
- Padding should be limited to a reasonable amount. - Padding should be limited to a reasonable amount.
Alice may reject connections with excessive padding. Alice may reject connections with excessive padding.
@@ -1110,16 +1112,16 @@ Notes
Min/max guidelines TBD. Random size from 0 to 31 bytes minimum? Min/max guidelines TBD. Random size from 0 to 31 bytes minimum?
(Distribution to be determined, see Appendix A.) (Distribution to be determined, see Appendix A.)
- On any error, including AEAD, DH, timestamp, apparent replay, or key validation failure, - On any error, including AEAD, DH, timestamp, apparent replay, or key
Alice must halt further message processing and close the connection without responding. validation failure, Alice must halt further message processing and close the
This should be an abnormal close (TCP RST). connection without responding. This should be an abnormal close (TCP RST).
- To facilitate rapid handshaking, implementations must ensure - To facilitate rapid handshaking, implementations must ensure that Bob buffers
that Bob buffers and then flushes the entire contents of the first message at once, and then flushes the entire contents of the first message at once, including
including the padding. the padding. This increases the likelihood that the data will be contained
This increases the likelihood that the data will be contained in a single TCP packet in a single TCP packet (unless segmented by the OS or middleboxes), and
(unless segmented by the OS or middleboxes), and received all at once by Alice. received all at once by Alice. This is also for efficiency and to ensure the
This is also for efficiency and to ensure the effectiveness of the random padding. effectiveness of the random padding.
Issues Issues
@@ -1255,30 +1257,35 @@ XK(s, rs): Authentication Confidentiality
-> s, se 2 5 -> s, se 2 5
Authentication: 2. Authentication: 2.
Sender authentication resistant to key-compromise impersonation (KCI). Sender authentication resistant to key-compromise impersonation (KCI). The
The sender authentication is based on an ephemeral-static DH ("es" or "se") sender authentication is based on an ephemeral-static DH ("es" or "se")
between the sender's static key pair and the recipient's ephemeral key pair. between the sender's static key pair and the recipient's ephemeral key
Assuming the corresponding private keys are secure, this authentication cannot be forged. pair. Assuming the corresponding private keys are secure, this
authentication cannot be forged.
Confidentiality: 5. Confidentiality: 5.
Encryption to a known recipient, strong forward secrecy. Encryption to a known recipient, strong forward secrecy. This payload is
This payload is encrypted based on an ephemeral-ephemeral DH as well as encrypted based on an ephemeral-ephemeral DH as well as an ephemeral-static
an ephemeral-static DH with the recipient's static key pair. DH with the recipient's static key pair. Assuming the ephemeral private
Assuming the ephemeral private keys are secure, and the recipient is not being actively impersonated keys are secure, and the recipient is not being actively impersonated by an
by an attacker that has stolen its static private key, this payload cannot be decrypted. attacker that has stolen its static private key, this payload cannot be
decrypted.
"s": Alice writes her static public key from the s variable into the message buffer, "s": Alice writes her static public key from the s variable into the
encrypting it, and hashes the output along with the old h to derive a new h. message buffer, encrypting it, and hashes the output along with the old h
to derive a new h.
"se": A DH is performed between the Alice's static key pair and the Bob's ephemeral key pair. "se": A DH is performed between the Alice's static key pair and the Bob's
The result is hashed along with the old ck to derive a new ck and k, and n is set to zero. ephemeral key pair. The result is hashed along with the old ck to derive a
new ck and k, and n is set to zero.
{% endhighlight %} {% endhighlight %}
This contains two ChaCha/Poly frames. This contains two ChaCha/Poly frames.
The first is Alice's encrypted static public key. The first is Alice's encrypted static public key.
The second is the Noise payload: Alice's encrypted RouterInfo, optional options, and optional padding. The second is the Noise payload: Alice's encrypted RouterInfo, optional
They use different keys, because the MixKey() function is called in between. options, and optional padding. They use different keys, because the MixKey()
function is called in between.
Raw contents: Raw contents:
@@ -1391,15 +1398,16 @@ Notes
- Options should be included, to specify padding parameters. - Options should be included, to specify padding parameters.
- On any error, including AEAD, RI, DH, timestamp, or key validation failure, - On any error, including AEAD, RI, DH, timestamp, or key validation failure,
Bob must halt further message processing and close the connection without responding. Bob must halt further message processing and close the connection without
This should be an abnormal close (TCP RST). responding. This should be an abnormal close (TCP RST).
- To facilitate rapid handshaking, implementations must ensure - To facilitate rapid handshaking, implementations must ensure that Alice
that Alice buffers and then flushes the entire contents of the third message at once, buffers and then flushes the entire contents of the third message at once,
including both AEAD blocks. including both AEAD blocks.
This increases the likelihood that the data will be contained in a single TCP packet This increases the likelihood that the data will be contained in a single TCP
(unless segmented by the OS or middleboxes), and received all at once by Bob. packet (unless segmented by the OS or middleboxes), and received all at once
This is also for efficiency and to ensure the effectiveness of the random padding. by Bob. This is also for efficiency and to ensure the effectiveness of the
random padding.
@@ -1960,7 +1968,8 @@ before connecting using the NTCP2 protocol.
When published as "NTCP" with "n", "s", "i", and "v" options, When published as "NTCP" with "n", "s", "i", and "v" options,
the router must accept incoming connections on that host and port the router must accept incoming connections on that host and port
for both NTCP and NTCP2 protocols, and automatically detect the protocol version. for both NTCP and NTCP2 protocols, and automatically detect the protocol
version.
When published as "NTCP2" with "n", "s", "i", and "v" options, When published as "NTCP2" with "n", "s", "i", and "v" options,
the router accepts incoming connections on that host and port the router accepts incoming connections on that host and port
@@ -1984,7 +1993,8 @@ she must include her Noise static public key in her RouterInfo options.
The option name is N(shortened Noise name)(NTCP2 Version)s. The option name is N(shortened Noise name)(NTCP2 Version)s.
- NNXK2CS2s=(Base64 key) - NNXK2CS2s=(Base64 key)
Name shortened from (N)TCP2 (N)oise_(XK)_(2)5519_(C)haChaPoly_(S)HA256 version (2) (s)tatic key. Name shortened from (N)TCP2 (N)oise_(XK)_(2)5519_(C)haChaPoly_(S)HA256
version (2) (s)tatic key.
Future options will be named similarly, with 6 chars to represent Future options will be named similarly, with 6 chars to represent
the 5 Noise name fields. the 5 Noise name fields.
The current Noise static public key (s) for this Router. The current Noise static public key (s) for this Router.
@@ -1998,43 +2008,45 @@ Public Key and IV Rotation
-------------------------- --------------------------
Due to caching of RouterInfos, routers must not rotate the static public key Due to caching of RouterInfos, routers must not rotate the static public key
while the router is up, whether in a published address or not. Routers must persistently store this key while the router is up, whether in a published address or not. Routers must
for reuse after an immediate restart, so incoming connections will persistently store this key for reuse after an immediate restart, so incoming
continue to work, and restart times are not exposed. connections will continue to work, and restart times are not exposed. Routers
Routers must persistently store, or otherwise determine, must persistently store, or otherwise determine, last-shutdown time, so that
last-shutdown time, so that the previous downtime may be calculated at startup. the previous downtime may be calculated at startup.
Subject to concerns about exposing restart times, Subject to concerns about exposing restart times, routers may rotate this key
routers may rotate this key at startup if the router was previously down at startup if the router was previously down for some time (a couple hours at
for some time (a couple hours at least). least).
If the router has any published NTCP2 RouterAddresses (as NTCP or NTCP2), If the router has any published NTCP2 RouterAddresses (as NTCP or NTCP2), the
the minimum downtime before rotation should be much longer, for example one month, minimum downtime before rotation should be much longer, for example one month,
unless the local IP address has changed or the router "rekeys". unless the local IP address has changed or the router "rekeys".
If the router has any published SSU RouterAddresses, but not NTCP2 (as NTCP or NTCP2) If the router has any published SSU RouterAddresses, but not NTCP2 (as NTCP or
the minimum downtime before rotation should be longer, for example one day, NTCP2) the minimum downtime before rotation should be longer, for example one
unless the local IP address has changed or the router "rekeys". day, unless the local IP address has changed or the router "rekeys". This
This applies even if the published SSU address has introducers. applies even if the published SSU address has introducers.
If the router does not have any published RouterAddresses (NTCP, NTCP2, or SSU), If the router does not have any published RouterAddresses (NTCP, NTCP2, or
the minimum downtime before rotation may be as short as two hours, SSU), the minimum downtime before rotation may be as short as two hours, even
even if the IP address changes, unless the router "rekeys". if the IP address changes, unless the router "rekeys".
If the router "rekeys" to a different Router Hash, it should generate If the router "rekeys" to a different Router Hash, it should generate a new
a new noise key as well. noise key as well.
Implementations must be aware that changing the static public key will prohibit Implementations must be aware that changing the static public key will prohibit
incoming NTCP2 connections from routers that have cached an older RouterInfo. incoming NTCP2 connections from routers that have cached an older RouterInfo.
RouterInfo publishing, tunnel peer selection (including both OBGW and IB closest hop), RouterInfo publishing, tunnel peer selection (including both OBGW and IB
zero-hop tunnel selection, transport selection, and other implementation strategies closest hop), zero-hop tunnel selection, transport selection, and other
must take this into account. implementation strategies must take this into account.
IV rotation is subject to identical rules, except that IVs are not present except in IV rotation is subject to identical rules, except that IVs are not present
published RouterAddresses, so there is no IV for hidden or firewalled routers. except in published RouterAddresses, so there is no IV for hidden or firewalled
routers.
Note: The minimum downtime before rekeying may be modified to ensure network health, Note: The minimum downtime before rekeying may be modified to ensure network
and to prevent reseeding by a router down for a moderate amount of time. health, and to prevent reseeding by a router down for a moderate amount of
time.
@@ -2043,19 +2055,21 @@ Identity Hiding
``````````````` ```````````````
Deniability is not a goal. See overview above. Deniability is not a goal. See overview above.
Each pattern is assigned properties describing the confidentiality supplied to the initiator's static public key, Each pattern is assigned properties describing the confidentiality supplied to
and to the responder's static public key. the initiator's static public key, and to the responder's static public key.
The underlying assumptions are that ephemeral private keys are secure, The underlying assumptions are that ephemeral private keys are secure, and that
and that parties abort the handshake if they receive a static public key from the other party which they don't trust. parties abort the handshake if they receive a static public key from the other
party which they don't trust.
This section only considers identity leakage through static public key fields in handshakes. This section only considers identity leakage through static public key fields
Of course, the identities of Noise participants might be exposed through other means, in handshakes. Of course, the identities of Noise participants might be
including payload fields, traffic analysis, or metadata such as IP addresses. exposed through other means, including payload fields, traffic analysis, or
metadata such as IP addresses.
Alice: (8) Encrypted with forward secrecy to an authenticated party. Alice: (8) Encrypted with forward secrecy to an authenticated party.
Bob: (3) Not transmitted, but a passive attacker can check candidates for the responder's private key Bob: (3) Not transmitted, but a passive attacker can check candidates for the
and determine whether the candidate is correct. responder's private key and determine whether the candidate is correct.
Bob publishes his static public key in the netdb. Alice may or may not? Bob publishes his static public key in the netdb. Alice may or may not?
@@ -2069,8 +2083,9 @@ Issues
Version Detection Version Detection
================= =================
When published as "NTCP", the router must automatically detect When published as "NTCP", the router must automatically detect the protocol
the protocol version for incoming connections. version for incoming connections.
This detection is implementation-dependent, but here is some general guidance. This detection is implementation-dependent, but here is some general guidance.
To detect the version of an incoming NTCP connection, Bob proceeds as follows: To detect the version of an incoming NTCP connection, Bob proceeds as follows:
@@ -2080,12 +2095,11 @@ To detect the version of an incoming NTCP connection, Bob proceeds as follows:
is version 1. is version 1.
- If less than 288 bytes, either - If less than 288 bytes, either
- Wait for a short time for more data - Wait for a short time for more data (good strategy before widespread NTCP2
(good strategy before widespread NTCP2 adoption) adoption) if at least 288 total received, it's NTCP 1.
if at least 288 total received, it's NTCP 1.
- Try the first stages of decoding as version 2, if it fails, wait a short time for more data - Try the first stages of decoding as version 2, if it fails, wait a short
(good strategy after widespread NTCP2 adoption) time for more data (good strategy after widespread NTCP2 adoption)
- Decrypt the first 32 bytes (the X key) - Decrypt the first 32 bytes (the X key)
of the SessionRequest packet using AES-256 with key RH_B. of the SessionRequest packet using AES-256 with key RH_B.
@@ -2099,12 +2113,13 @@ To detect the version of an incoming NTCP connection, Bob proceeds as follows:
Note that changes or additional strategies may be recommended if we detect Note that changes or additional strategies may be recommended if we detect
active TCP segmentation attacks on NTCP 1. active TCP segmentation attacks on NTCP 1.
To facilitate rapid version detection and handshaking, implementations must ensure To facilitate rapid version detection and handshaking, implementations must
that Alice buffers and then flushes the entire contents of the first message at once, ensure that Alice buffers and then flushes the entire contents of the first
including the padding. message at once, including the padding.
This increases the likelihood that the data will be contained in a single TCP packet This increases the likelihood that the data will be contained in a single TCP
(unless segmented by the OS or middleboxes), and received all at once by Bob. packet (unless segmented by the OS or middleboxes), and received all at once by
This is also for efficiency and to ensure the effectiveness of the random padding. Bob. This is also for efficiency and to ensure the effectiveness of the random
padding.
This applies to both NTCP and NTCP2 handshakes. This applies to both NTCP and NTCP2 handshakes.
@@ -2113,14 +2128,16 @@ Variants, Fallbacks, and General Issues
- If Alice and Bob both support NTCP2, Alice should connect with NTCP2. - If Alice and Bob both support NTCP2, Alice should connect with NTCP2.
- If Alice fails to connect to Bob using NTCP2 for any reason, the connection fails. - If Alice fails to connect to Bob using NTCP2 for any reason, the connection
fails.
Alice may not retry using old NTCP 1. Alice may not retry using old NTCP 1.
- Fallback to XX pattern if Bob changes his keys? This would require a type byte prepended? - Fallback to XX pattern if Bob changes his keys? This would require a type
byte prepended?
- "Fall forward" to KK pattern if Alice reconnects, assuming Bob still has her static key? - "Fall forward" to KK pattern if Alice reconnects, assuming Bob still has her
This doesn't save any round trips and uses 4 DH rounds compared to 3 for XK. static key? This doesn't save any round trips and uses 4 DH rounds compared
Probably not. to 3 for XK. Probably not.
.. raw:: html .. raw:: html
@@ -2137,11 +2154,11 @@ Variants, Fallbacks, and General Issues
Appendix A: Padding Scheme Appendix A: Padding Scheme
========================== ==========================
This section discusses an attack on typical padding schemes that allows attackers to This section discusses an attack on typical padding schemes that allows
discover the probability distribution of the length of the unpadded messages, by attackers to discover the probability distribution of the length of the
only observing the length of the padded messages. Let N be a random variable unpadded messages, by only observing the length of the padded messages. Let N
describing the number of unpadded bytes, and P likewise for the number of be a random variable describing the number of unpadded bytes, and P likewise
padding bytes. The total message size is then N + P. for the number of padding bytes. The total message size is then N + P.
Assume that for an unpadded size of n, at least ``P_min(n) >= 0`` and at most Assume that for an unpadded size of n, at least ``P_min(n) >= 0`` and at most
``P_max(n) >= P_min(n)`` bytes of padding are added in a padding scheme. The ``P_max(n) >= P_min(n)`` bytes of padding are added in a padding scheme. The