commit 081e943987fad482786b1fa6fe3653672b22227d Author: Philipp Winter phw@torproject.org Date: Sat Mar 1 22:14:18 2014 +0100

Elaborate on server's behaviour.

In particular, discuss strategies which servers should implement if clients cannot authenticate. Otherwise, malicious clients could run computation-based or memory-based denial-of-service attacks. This problem was reported by Yawning Angel.

This should fix https://bugs.torproject.org/11092. --- doc/scramblesuit/scramblesuit-spec.txt | 11 +++++++---- 1 file changed, 7 insertions(+), 4 deletions(-)

diff --git a/doc/scramblesuit/scramblesuit-spec.txt b/doc/scramblesuit/scramblesuit-spec.txt index de6b778..1de6263 100644 --- a/doc/scramblesuit/scramblesuit-spec.txt +++ b/doc/scramblesuit/scramblesuit-spec.txt @@ -35,10 +35,13 @@ secret should thwart active probing attacks.

As stated in the research paper [1], a server only replies to a client if - the client can prove knowledge of the shared secret. If a client sends - data which lacks this knowledge, the server MUST NOT reply. It MAY - terminate the connection if the client could not prove knowledge of the - shared secret after a timeout has passed. + the client can prove knowledge of the shared secret. As long as clients + cannot prove knowledge of the shared secret, servers MUST NOT reply. If + authentication did not succeed after 1532 bytes have been received, the + server SHOULD stop processing incoming data to prevent denial-of-service + attacks. The server MAY close the TCP connection. Alternatively, the + server MAY proceed to accept data but it SHOULD stop buffering or + processing the data, thus effectively ignoring the client.

2.1 UniformDH Handshake