From ac45737cc253a65022347f19f571a7a1a1c14dba Mon Sep 17 00:00:00 2001
From: zzz <zzz@mail.i2p>
Date: Tue, 27 Sep 2016 14:32:12 +0000
Subject: [PATCH] Proposal 111 update SAMv3 minor clarification

---
 i2p2www/pages/site/docs/api/samv3.html |  3 +++
 i2p2www/spec/proposals/111-ntcp-2.rst  | 19 ++++++++++++++++---
 2 files changed, 19 insertions(+), 3 deletions(-)

diff --git a/i2p2www/pages/site/docs/api/samv3.html b/i2p2www/pages/site/docs/api/samv3.html
index 61b7dea8..c2dc4e7b 100644
--- a/i2p2www/pages/site/docs/api/samv3.html
+++ b/i2p2www/pages/site/docs/api/samv3.html
@@ -1277,6 +1277,9 @@ implementation-specific and outside the scope of this specification.
 Double quotes for user and password are recommended but not required.
 A double quote inside a user or password must be escaped with a backslash.
 On failure the server will reply with an I2P_ERROR and a message.
+
+</p><p>
+AUTH does not require that a session has been created first.
 </p>
 
 
diff --git a/i2p2www/spec/proposals/111-ntcp-2.rst b/i2p2www/spec/proposals/111-ntcp-2.rst
index 1fdb9b26..312cbdf4 100644
--- a/i2p2www/spec/proposals/111-ntcp-2.rst
+++ b/i2p2www/spec/proposals/111-ntcp-2.rst
@@ -5,7 +5,7 @@ NTCP 2
     :author: zzz
     :created: 2014-02-13
     :thread: http://zzz.i2p/topics/1577
-    :lastupdated: 2016-09-17
+    :lastupdated: 2016-09-27
     :status: Open
     :supercedes: 106
 
@@ -44,6 +44,9 @@ Design Goals
   (or not) on their own schedules
 - Add random padding to all NTCP messages including handshake and data messages
   (i.e. length obfuscation so all messages aren't a multiple of 16 bytes)
+  Provide options mechanism for both sides to request min and max padding
+  and/or padding distribution. Specifics of the padding distribution are
+  implementation-dependent and may or may not be specified in the protocol itself.
 - Obfuscate the contents of messages that aren't encrypted (1 and 2), sufficiently
   so that DPI boxes and AV signatures can't easily classify them.
   Also ensure that the messages going to
@@ -82,14 +85,19 @@ Non-Goals
 =========
 
 - Bullet-proof DPI resistance... that would be pluggable transports, proposal #109
-- A TLS-based transport... that would be proposal #104
+- A TLS-based (or HTTPS-lookalike) transport... that would be proposal #104
 - Don't change the symmetric stream crypto, continue to use AES-CBC-256
   (but do add flags in the handshake so we can change later).
   However, why is using the last 16 bytes of the previous message as the IV
   better than just using counter mode? To be researched.
   Salsa 20 also an option (see alternatives below)
+- Timing-based DPI resistance (inter-message timing/delays can be
+  implementation-dependent; intra-message delays can be introduced at
+  any point, including before sending the random padding, for example).
+  Artificial delays (what obfs4 calls IAT or inter-arrival time) are
+  independent of the protocol itself.
 - Post-Quantum (PQ) Crypto resistance
-- Deniability (there's signatures in there)
+- Deniability of participating in a session (there's signatures in there)
 
 
 Related Goals
@@ -119,6 +127,11 @@ Alternative: Make it something easier to parse, where it's the integer
 representation of a bitfield. ver=3 means you support version 1 and 2.
 ver=7 means you support versions 1, 2, and 3.
 
+Alternative 2: If it's not easy to support NTCP2 on the same port,
+use "NTCP2" as the transport in a separate RouterAddress.
+Implementations could use the same or a different port, as implemented.
+
+
 
 Messages
 ========