Mögliche Lösung

Wenn das Schlüsselaushandeln so kritisch ist, dass damit der Server
lahmgelegt werden kann, dann muss auf der Serverseite das eben
berücksichtigt werden.

Die Threads, die gerade einen Schlüssel aushandeln (sei es neu oder
während einer Verbindung), dürfen in Summe nur einen gewissen
Prozentsatz der Rechenleistung erhalten, der wiederum abhängig davon
ist, wieviel an normaler Ver/Entschlüsselungs-Last läuft. Und
Verbindungen, bei denen ein neuer Schlüssel angefordert wird, kommen
ganz zum Schluss dran. Auch das wieder dynamisch abhängig von der
sonstigen Last am Server.

Außerdem kann man versuchen aufgrund des Verhaltens zu erkennen, ob
so eine Anfrage von einem normalen Client oder einem Angreifer kommt.
Je öfter auf einer Verbindung ein neuer Schlüssel angefordert wird
umso verdächtiger. Wenn von einer IP-Adresse plötzlich viele
Anforderungen kommen, .... Je verdächtiger eine Verbindung ist, umso
kleiner ist die Priorität gegenüber allen anderen Verbindungen.

Dann kann der Server deswegen nicht blockieren und normale Anwender
können immer neue Verbindungen aufbauen (im Falle eines laufenden
Angriffes, dauert der Verbindungsaufbau halt länger). Und Angreifer
können nicht mehr tausende Schlüssel pro Zeiteinheit aushandeln
sondern nur mehr ein paar Dutzend.

Ich weiß nicht, ob ich da richtig liege. Kenne die Materie zu wenig.
Antworten gerne gesehen.

Aber wenn das so oder so ähnlich stimmt, dann ist es weniger ein
systematisches Problem des Protokolls, sondern der Implementierung
der Serverseite.

LG Holan