I2P Entwicklertreffen - 04. Oktober 2013

20:09:33 <str4d> Zeit fürs Meeting. Wer ist hier? 20:09:53 * psi ist hier 20:10:04 * dg hier 20:11:34 * topiltzin . 20:11:51 <str4d> hottuna, zzz, welterde, kytv: ping 20:12:17 * orion ist hier 20:13:01 * str4d lädt die Meeting-Agenda 20:14:01 <str4d> Ich kann zzz.i2p nicht erreichen. Kommt sonst jemand auf http://zzz.i2p/topics/1480 ? 20:14:35 <str4d> Hab's. 20:14:43 <str4d> 1) Bedrohungsmodell 20:14:44 <str4d> 1a) Vor- und Nachteile des DREAD-Klassifikationsschemas diskutieren (und ggf. ein anderes wählen). 20:14:44 <str4d> 1b) Bedrohungsmodell diskutieren (und bei Bedarf aktualisieren). 20:14:44 <str4d> 1c) DREAD (oder anderes Schema) auf die Angriffsvektoren im Bedrohungsmodell anwenden. 20:14:44 <str4d> 2) Website-Überarbeitung – zur Vorbereitung auf den Launch durchsehen. 20:14:53 <str4d> 3) Roadmapping. 20:15:22 <str4d> 4) Diskussion der Dokumentation. 20:15:41 <str4d> 0) haben wir schon erledigt: Hallo sagen ;-P 20:15:42 <str4d> 1) Bedrohungsmodell 20:15:53 <str4d> 1a) Vor- und Nachteile des DREAD-Klassifikationsschemas diskutieren (und ggf. ein anderes wählen). 20:17:07 <str4d> Wie ich im Forenbeitrag gesagt habe, ist eine der Maßnahmen, mit denen wir die Außenwahrnehmung von I2P verbessern können, das Bedrohungsmodell zu verbessern und zu präzisieren. 20:17:29 <str4d> Im Moment ist es eine Textwand, und es ist für Nutzer (und wenig motivierte Devs) schwer, die Hauptpunkte zu finden. 20:17:45 <dg> Es ist auch schwer, es zu priorisieren. 20:17:47 <dg> Dringlichkeit einschätzen usw. 20:18:03 <str4d> Und ohne vernünftiges Risikomodell haben wir eigentlich keine Ahnung, ob wir die richtigen Aspekte in den Fokus nehmen. 20:18:13 <psi> Es wäre super, zuerst eine Kurzfassung des Bedrohungsmodells zu haben und darauf aufzubauen 20:18:23 <str4d> dg: genau. 20:18:59 <str4d> Ich habe etwas recherchiert, und https://www.owasp.org/index.php/Threat_Risk_Modeling hat ein gutes „Layout“ für Threat/Risk Modeling, das z. B. von Cryptocat für deren Bedrohungsmodell verwendet wird. 20:19:04 <iRelay> Titel: Threat Risk Modeling - OWASP (auf www.owasp.org) 20:19:53 <str4d> Das dort beschriebene DREAD-Schema identifiziert Risiken nicht immer korrekt; so das Feedback in einem späteren Beitrag des Designers des Modells – https://blogs.msdn.com/b/david_leblanc/archive/2007/08/13/dreadful.aspx 20:20:49 <str4d> Ich schlage vor, dass wir das im obigen Beitrag vorgeschlagene, modifizierte DREAD-Modell verwenden, um Schwere und Priorität unserer Angriffsvektoren zu modellieren. 20:20:50 <str4d> Diskussion! 20:21:13 <dg> Gib mir etwas Zeit, mir die Modelle anzuschauen? :) 20:21:40 <str4d> dg: Das hättest du eigentlich schon tun sollen, ich habe im Forenbeitrag darauf verlinkt... 20:21:44 <str4d> :P 20:21:50 <dg> sorry 20:22:24 <str4d> (aber ich habe die Leute tatsächlich nicht darum gebeten, mein Fehler) 20:23:08 <str4d> DREAD tl;dr – eine Bedrohung wird auf fünf Skalen von 1–10 bewertet, die Ergebnisse addiert und durch 5 geteilt. 20:23:12 <str4d> Damage Potential 20:23:29 <str4d> Reproducibility 20:23:29 <str4d> Exploitability 20:23:29 <str4d> Affected Users 20:23:30 <str4d> Discoverability 20:24:12 <str4d> modifiziertes DREAD tl;dr – dieselben fünf Parameter, aber eine 1–3-Skala (low, med, high) und eine „gewichtete“ Berechnung. 20:25:09 <dg> Ich überfliege es kurz; ich kenne offensichtlich nicht alle Details, aber jedes strukturierte System ist besser. 20:25:18 <str4d> Das modifizierte DREAD-Modell ergibt für mich mehr Sinn als das Original. 20:26:06 <dg> Ich habe auch großen Respekt vor OWASP. :P 20:26:10 <str4d> „Wenn wir uns die fünf Komponenten ansehen, sehen wir, dass keine davon stark korreliert – eine impliziert nicht die andere. Das bedeutet, wir haben unabhängige Faktoren, was eines der stärksten Kriterien für ein belastbares Modell ist. Unsere Aufgabe ist also, die Eingaben richtig zu gewichten. In WSC haben wir euch gesagt, ihr sollt sie von 1–10 bewerten, aufsummieren und durch 5 teilen. Wendet man ein paar offensichtliche Tests an, stellt man fest, dass ein Schaden von 1 und alle anderen Faktoren 10 (eine bekannte Belästigung 20:26:10 <str4d> , z. B. Pop-ups) genauso gewichtet wird wie eine Discoverability von 1 und alles andere 10 (schwer zu erkennen, führt aber zum Wärmetod des Universums). Das ist ein offensichtlicher Fehler.“ 20:27:10 <str4d> dg: ich auch. Sie haben dort viele andere potenziell nützliche Modelle und Dokus. 20:27:31 <str4d> Hat sonst noch jemand Anmerkungen? 20:29:50 <str4d> Wenn sonst niemand Anmerkungen hat, gehen wir derweil zum nächsten Thema über, während ihr darüber nachdenkt. 20:30:05 <psi> keine Anmerkungen 20:31:03 <str4d> 1b) Bedrohungsmodell diskutieren (und bei Bedarf aktualisieren). 20:31:17 <str4d> http://vekw35szhzysfq7cwsly37coegsnb4rrsggy5k4wtasa6c34gy5a.b32.i2p/en/docs/how/threat-model 20:31:18 * psi überfliegt das Bedrohungsmodell 20:31:39 <iRelay> Titel: I2P's Threat Model - I2P (auf vekw35szhzysfq7cwsly37coegsnb4rrsggy5k4wtasa6c34gy5a.b32.i2p) 20:31:47 <dg> Ich sehe eine Bewertung? 20:31:50 <dg> Ist das neu? 20:32:04 <str4d> dg: Ich habe das modifizierte DREAD-System hinzugefügt. 20:32:12 <str4d> (in der Erwartung, dass niemand Einwände hat) 20:32:31 <str4d> (aber nicht in der Erwartung, dass es überhaupt keine Kommentare gibt :-P ) 20:32:53 <str4d> Die Bewertungen sind ungültig. 20:33:03 <dg> Es scheint nicht zu passen– 20:33:05 <dg> ja 20:33:09 <str4d> (das ist es, was ich in diesem Meeting ändern will) 20:33:25 <str4d> Während wir das Bedrohungsmodell selbst diskutieren, bitte über mögliche Bewertungen nachdenken (für das nächste Thema) 20:33:28 <dg> Das Design sieht gut aus, mit echten Werten würde es mir gefallen. Wir sollten auch nach Schweregrad sortieren. 20:34:48 <str4d> Unsere Bedrohungsmodell-Seite folgt nicht dem „Standard“-Layout für Bedrohungsmodelle (z. B. der OWASP-Seite) 20:35:04 <str4d> Sicherheitsziele identifizieren 20:35:05 <str4d> Die Anwendung erfassen 20:35:05 <str4d> Sie zerlegen 20:35:05 <str4d> Bedrohungen identifizieren 20:35:05 <str4d> Schwachstellen identifizieren 20:35:08 <psi> Besprechen wir die Werte dieser Bewertungen jetzt ... oder später? 20:35:50 <str4d> psi: beim nächsten Thema. Im Moment diskutieren wir das Bedrohungsmodell selbst – wir können Bedrohungen nicht bewerten, wenn es veraltet ist. 20:35:58 <psi> richtig 20:36:17 <str4d> (Und FYI: Das Meeting endet um 22:00 Uhr UTC) 20:36:29 <str4d> (Ich jedenfalls gehe dann) 20:37:18 <str4d> Die Bedrohungsmodell-Seite benennt unsere Sicherheitsziele nicht klar. 20:37:21 <dg> Wo ist denn alle Welt? 20:37:29 <dg> Mit 3 Leuten können wir nicht arbeiten. 20:37:54 <str4d> topiltzin, hottuna, zzz, welterde, kytv: ping 20:37:55 <zzz> Zum „Formalisieren“ des Modells gehört mehr, als nur jedes Element zu bewerten 20:37:56 <equinox> Ich finde, die in den heutigen Guardian-Artikeln beschriebenen Methoden sollte man berücksichtigen. Die NSA hat versucht, den Dev-Prozess ins Visier zu nehmen 20:38:16 <str4d> zzz: Ich weiß, aber wir müssen irgendwo anfangen. 20:38:18 <zzz> Insbesondere ist der Hauptkritikpunkt an unserem Modell, dass wir nicht klar festlegen, was drin ist und was draußen bleibt 20:38:40 <dg> Was betrifft uns und was nicht? 20:38:43 <zzz> Das ist ein Schritt, der vor der Bewertung erfolgen müsste, wenn wir auf die Kritiker eingehen wollen 20:39:23 <str4d> zzz: Genau das tun wir jetzt. 20:39:23 <str4d> <str4d> Die Bedrohungsmodell-Seite benennt unsere Sicherheitsziele nicht klar. 20:39:29 <zzz> Der Hauptzweck eines Bedrohungsmodells ist festzulegen, was NICHT darin ist, z. B. die NSA. Projekte nutzen das, um mit den Händen zu wedeln und zu sagen „nicht unser Problem, nicht in unserem Bedrohungsmodell“ 20:39:44 <zzz> Das haben wir nicht getan. 20:40:07 <idog98@freenode> . 20:40:10 <str4d> Richtig. Also lasst uns das tun. 20:40:29 <zzz> Wenn wir ein formales Modell erstellen und die NSA auslassen, können wir aufhören, an Protokoll-Obfuskation zu arbeiten, und vielleicht sogar an stärkerer Kryptografie. 20:40:42 <zzz> Oder wir nennen das Ausflucht. 20:41:18 <dg> Von Anfang an ist klar, dass Tor dich nicht vor einem GPA (Global Passive Adversary, global passiver Angreifer) retten kann. Machen wir das und andere Vorbehalte deutlich? 20:41:26 <dg> und schützen wir gegen die NSA? 20:41:59 <str4d> Globale Gegner (die das gesamte Internet überwachen können) sind schon von der Natur des Onion-Routing-Designs her außen vor. 20:42:18 <str4d> Die NSA ist, so groß sie ist, kein globaler Gegner. 20:42:37 <psi> Die NSA hat so, wie sie ist, schon eine enorme Reichweite 20:42:38 <zzz> Vieles am aktuellen Modell ist aspirativ, da wir zu klein sind, um derzeit viele Punkte realistisch zu kontern 20:42:50 <dg> Würden wir mit einigen Punkten auf unserer Roadmap gegen GPA schützen? ;) 20:42:52 <equinox> str4d: vielleicht, aber sie arbeiten mit anderen zusammen 20:43:01 <zzz> Die übliche Terminologie ist „state-level“ adversary (Gegner auf Staatsebene), z. B. die NSA 20:43:03 <orion> GPA? 20:43:11 <str4d> equinox: vermutlich. 20:43:13 <str4d> zzz: danke. 20:43:18 <dg> Global Passive Adversary 20:43:56 <zzz> Wenn du also ein strenges Modell machen und „state-level“ ausschließen willst und es zur Dev-Steuerung nutzt, würde es uns z. B. sagen, nicht an Obfuskation zu arbeiten 20:44:47 <orion> Es ist schon schwer genug, Anonymität zu erhalten, ganz zu schweigen von Obfuskation. 20:45:43 <zzz> Kritiker lieben formale Bedrohungsmodelle ... beflügelt es damit nur die Trolle, oder hilft es uns wirklich bei Öffentlichkeitsarbeit und Entwicklung? 20:45:53 <str4d> Wir haben stets gesagt, dass I2P keine Obfuskation macht (aber nicht explizit im Bedrohungsmodell) 20:46:19 <str4d> Das ist ein fairer Punkt. 20:46:28 <Mathiasdm> Ein Bedrohungsmodell hilft beim Fokus 20:46:34 <dg> Die Trolle finden genug, wenn sie trollen wollen. Scheiß drauf. 20:46:41 <Mathiasdm> Trolle gibt es immer, die würde ich nicht berücksichtigen 20:46:43 <Mathiasdm> (sorry fürs Reingrätschen) 20:46:51 <str4d> Mein Ziel mit diesem Meeting war nicht, ein striktes Bedrohungsmodell zu haben, dem wir buchstabengetreu folgen müssen. 20:47:02 <str4d> Selbst wenn wir das wollten, wäre das in einem einzigen Meeting nicht möglich. 20:47:25 <dg> Kein Problem. Schön, dich zu sehen, Mathiasdm. 20:47:28 <dg> Ein formales Bedrohungsmodell hilft uns übrigens zu definieren, wogegen wir uns schützen wollen 20:47:37 <dg> Ich bin seit fast einem Jahr dabei und bin mir immer noch nicht sicher, wogegen genau. 20:47:40 <str4d> Die Website-Seite, die wir „Bedrohungsmodell“ nennen, ist ein riesiges WoT und schwer zu „greppen“. Das ist es, was ich wirklich beheben will. 20:48:20 <str4d> Ich möchte, dass Nutzer es anschauen und schnell verstehen können, was wir versuchen zu erreichen. 20:48:50 <equinox> Wir wissen, staatliche Behörden und Akteure im Namen des Staates werden ihren Radius mit der Zeit nur ausweiten (wenn man sie nicht bremst). Ich denke, es ist besser, dafür zu planen, als nur darauf zu reagieren. 20:49:16 <str4d> Denn Fehl- und Missverständnisse sind bei I2P schon lange ein Problem. 20:50:28 <zzz> Ich finde die Seite ziemlich gut. Vielleicht braucht es aber noch eine extra Seite als Zusammenfassung. 20:51:12 <str4d> Das Threat-/Risk-Modeling (mit DREAD) ist etwas, das leicht umzusetzen ist und leicht wieder zu entfernen, falls wir entscheiden, dass es uns keine validen Informationen liefert. 20:51:57 <str4d> zzz: Es ist gut für jemanden, der bereit ist, sich die Zeit zum Lesen zu nehmen. Für „Skimmer“ ist es nicht gut. 20:52:36 <str4d> Wie der oben verlinkte Beitrag sagt: „Warnung! Wendet dieses System, oder irgendein anderes System, NICHT an, ohne darüber NACHZUDENKEN. Dieses System kann euch helfen, zur richtigen Schlussfolgerung zu kommen – oder auch nicht. Und wenn nicht, bedenkt, was es euch wert sein sollte: genau so viel, wie ihr dafür bezahlt habt, nämlich null.“ 20:53:26 <zzz> Meiner Meinung nach habt ihr drei orthogonale Ziele für die eine Seite: 1) Vereinfachung für die Masse, 2) Formalisierung und 3) Risikomodellierung 20:54:38 <str4d> 1) und 3) sind verknüpft – mit den Bewertungen kann die Masse „drüberskimmen“, die für sie „wichtigen“ Punkte finden und lesen. 20:54:49 <str4d> Aber ich stimme zu, dass 2) orthogonal ist (und auch mit 3) verknüpft) 20:56:04 <str4d> Wenn ein formales Bedrohungsmodell zum Blocker für andere Dinge wird, müssen wir es angehen. Als ich ursprünglich „formalisieren“ sagte, hätte ich „klarstellen“ sagen sollen. 20:57:43 <str4d> Kurze Umfrage: Hält hier jemand dafür, dass es sinnvoll bzw. eine gute Idee ist, DREAD auf die Angriffsvektoren auf unserer „Bedrohungsmodell“-Seite anzuwenden? 20:58:28 <str4d> Wenn ja, gehen wir zum nächsten Thema über und machen es; dann können wir das Ergebnis diskutieren. Wenn nein, vergessen wir es und machen weiter. 20:58:44 <topiltzin> ja-solange-es-jemand-anderes-macht 20:58:46 <dg> Was ist die Alternative? 20:59:09 <dg> hahaha 20:59:21 <topiltzin> Ehrlichkeit :) 21:02:00 <hottuna> Keine schlechte Idee, aber ich bin nicht sicher, dass das die endgültige Lösung für das Bedrohungsmodell ist. 21:02:06 <psi> hmm <str4d> hottuna: So ist es nicht gedacht, aber ich halte es für einen nützlichen Schritt. Und sonst hat niemand etwas vorgeschlagen oder getan :-P <psi> kommt darauf an, ob mehr Leute helfen <psi> wenn es nur 1 Person ist, auf keinen Fall <psi> wenn es Mitstreiter gibt, möglicherweise <str4d> psi: Ich wollte es direkt im Meeting machen, solange mehr als eine Person da ist. <zzz> „Formalisierung“ ist für manche wichtig – OpenITP, Kritiker, Reviewer, Auditoren, Geldgeber, andere in unserem Feld usw. <hottuna> Wäre es wirklich ausreichend und gut genug strukturiert, es einfach jetzt in diesem Meeting zu machen? <hottuna> Ich bin allerdings nicht sehr mit dem ganzen DREAD-Prozess vertraut. <str4d> hottuna: Wir gehen jeden Angriffsvektor durch und bewerten die fünf Kategorien als low, medium oder high. Das ist alles. <psi> ich bin mit DREAD auch nicht vertraut <str4d> Ich habe das gewählt, weil es sehr einfach anzuwenden ist. <psi> ah <str4d> (Die fünf Kategorien habe ich direkt oberhalb des Index auf der Bedrohungsmodell-Seite skizziert) <psi> lass uns ein Beispiel probieren <hottuna> jeder bekannte Angriffsvektor? <hottuna> psi, klar <str4d> Ich habe absichtlich alles im Vorfeld vorbereitet, um es einfach zu machen, weil ich wusste, dass es schwer sein würde, irgendjemanden hier dazu zu bringen, dem zuzustimmen :P <str4d> Okay, „Timing-Angriffe“ <hottuna> klar. <str4d> Damage Potential: Wenn ein Exploit der Bedrohung auftritt, wie groß ist der Schaden? <str4d> Wenn er dazu genutzt wird, einen Nutzer zu identifizieren, ist dieser deanonymisiert -> high? <hottuna> Statistische Exploits basierend auf Timing und Paketgrößen wurden gegen Tor eingesetzt, um erfolgreich herauszufinden, welche Seite besucht wurde <hottuna> mit sehr hohen Erfolgsraten (~90 %, wenn ich mich richtig erinnere) <str4d> (nutzt z. B. https://www.owasp.org/index.php/Threat_Risk_Modeling#DREAD, um ein Gefühl für die Skalen zu bekommen – dort sind bereits drei Stufen beschrieben) <str4d> Reliability: Wie zuverlässig ist der Angriff? - low? med? Er ist im Allgemeinen von der Netzwerklast abhängig. 21:12:28 <psi> was genau soll man timen können? 21:13:26 <hottuna> alles allgemein? 21:14:11 <psi> okay 21:14:27 <hottuna> Ich weiß es nicht. 21:14:47 <hottuna> Aber die Beschreibungen scheinen nachrichtenorientiert zu sein. 21:14:52 <str4d> (nutzt z. B. https://www.owasp.org/index.php/Threat_Risk_Modeling#DREAD, um ein Gefühl für die Skalen zu bekommen – dort sind bereits drei Stufen beschrieben) 21:14:54 <iRelay> Titel: Threat Risk Modeling - OWASP (auf www.owasp.org) 21:14:56 <str4d> Reliability: Wie zuverlässig ist der Angriff? - low? med? Er ist im Allgemeinen von der Netzwerklast abhängig. 21:15:33 <str4d> psi: guter Punkt – der Abschnitt „Timing-Angriffe“ sollte wahrscheinlich in Angriffe auf die Nachrichtenübermittlung und Angriffe auf den Nachrichteninhalt aufgeteilt werden 21:15:36 <hottuna> damage potential: 5? 21:15:51 <str4d> Gehen wir fürs Erste von Nachrichtenübermittlung aus. 21:15:55 <psi> „ Complete system or data destruction “ heißt, die Kiste explodiert, nehme ich an? 21:16:08 <hottuna> Was die Reliability angeht, haben sich statistische Modelle im Fall von Tor als zuverlässig erwiesen.. 21:18:00 <str4d> hottuna: wir verwenden eine 1–3-Skala 21:19:08 <str4d> die bei OWASP beschriebene 1–10-Skala ist schwerer zu begründen. 21:19:08 <str4d> „Was ist der Unterschied zwischen einer Discoverability von 6 und 7? Wer zum Teufel weiß das?“ 21:19:08 <str4d> Verwendet die OWASP-Skala als Indikator, wie man low/med/high zuordnet 21:19:11 <str4d> psi: In unserem Fall würde ich sagen, „high“ ist die vollständige Korrelation zwischen einem bestimmten Nutzer und seiner Aktivität. 21:19:13 <psi> Timing würde ich sagen 5 oder 6 21:19:13 <psi> (für den Schaden) 21:19:14 <str4d> (für Damage) 21:19:17 <str4d> https://blogs.msdn.com/b/david_leblanc/archive/2007/08/13/dreadful.aspx erklärt die Kategorien möglicherweise besser. 21:20:00 <psi> verstehe 21:20:16 <hottuna> aber der Schaden wäre die Offenlegung irgendeiner Information, was schlecht sein kann .. theoretisch könnte es offenlegen, dass ich eine bestimmte Anwendung betreibe oder mit einem bestimmten Ziel spreche 21:20:20 <hottuna> ist das eine 5–6? 21:20:34 <str4d> Exploitability: Was wird benötigt, um diese Bedrohung auszunutzen? - med? Der Angreifer muss mehrere Stellen entlang des möglichen Pfads überwachen. 21:20:36 <str4d> low? 21:20:49 <psi> es hängt vom Angreifer ab 21:20:55 <psi> und es hängt auch von der Netzwerkgröße ab 21:21:34 <str4d> Exploitability sind die Voraussetzungen vor dem Start des Angriffs. Reliability ist, wie gut er funktioniert, sobald er ausgelöst ist. 21:21:48 <psi> ah 21:21:49 <str4d> psi: ja, daher werden sich diese Bewertungen im Laufe der Zeit ändern. 21:22:05 <str4d> (Und das ist ein Beispiel für eine Einschränkung des Modells und ein großer Mangel im ursprünglichen DREAD) 21:22:06 <psi> Exploitability wäre med 21:22:18 <str4d> Exploitability wird nur zur Berechnung der Priorität verwendet, nicht der Schwere. 21:22:25 <psi> nur einen Standard-I2P router zu betreiben, wäre nicht genug 21:22:54 <str4d> psi: richtig, also nicht high. 21:23:15 <str4d> Aber auch nicht low, weil es keine hohe Rechenleistung usw. braucht. 21:23:20 <str4d> Affected Users: Wie viele Nutzer sind betroffen? 21:23:27 <hottuna> Du müsstest Teil eines tunnel sein und dir dann einfach das Nachrichtenprofil ansehen. Wenn du der ibgw für einen Dienst bist, könntest du ein paar Nutzer vom Rest separieren. Oder sie zumindest in verschiedene Nutzergruppen clustern 21:23:40 <hottuna> into* 21:24:23 <psi> mid könnte für Exploitability etwas viel sein 21:24:29 <psi> bit* 21:24:36 <psi> mid-low 21:24:40 <hottuna> im ibg-Fall würde ich sagen, es ist ziemlich einfach, aber man bekäme nicht viele Informationen 21:24:45 <hottuna> ibgw* 21:25:06 <str4d> psi: mid oder low. Es wirkt sich nur auf den Prioritätswert aus. 21:25:48 <hottuna> Was die Exploitability angeht, halte ich es für sehr machbar. Besonders im Vergleich zu anderen Exploits. 21:25:55 <str4d> Discoverability: Wie leicht ist es, diese Bedrohung zu entdecken? - mid? Es erfordert zumindest ein gewisses Wissen darüber, wie I2P funktioniert. 21:25:59 <psi> hottuna: einverstanden 21:26:10 <str4d> „Etwas mit hoher Discoverability ist öffentlich bekannt oder sehr ähnlich zu etwas, das öffentlich bekannt ist. Niedrige Discoverability heißt, dass es ein tiefes Verständnis der internen Funktionsweise deiner App braucht, um es herauszufinden.“ 21:26:22 <psi> mid 21:26:51 <hottuna> Wir würden nie von dem Angriff erfahren, da er passiv ist 21:26:55 <str4d> hottuna: genau. Die Klassifizierung hängt teilweise davon ab, was für andere Angriffe gewählt wird. Es ist alles relativ. 21:27:26 <hottuna> str4d, notierst du irgendeinen Wert basierend auf dem Gesagten? 21:27:44 <str4d> hottuna: ja. 21:29:02 <hottuna> gut. 21:29:02 <hottuna> D: low 21:29:19 <psi> hmm 21:29:29 <hottuna> Affected users: High (alle, die tatsächlich etwas tun) 21:29:37 <str4d> Das ist, worauf wir uns meiner Meinung nach geeinigt haben und was es ergibt: 21:29:37 <str4d> Damage Potential: medium 21:29:37 <str4d> Reliability: medium 21:29:37 <str4d> Exploitability: medium 21:29:51 <str4d> Affected Users: high 21:29:52 <str4d> Discoverability: medium 21:29:53 <str4d> Severity: 4/5 21:29:54 <str4d> Priority: 5/9 21:30:23 <psi> Timing-Angriffe sind ziemlich übel, aber sie scheinen nicht praktikabel 21:30:29 <psi> zumindest im Moment 21:30:41 <str4d> Klingt das nach einem sinnvollen Ergebnis? Entsprechen die von mir gesetzten Stufen dem, was wir tatsächlich entschieden haben? 21:30:58 <hottuna> Ich stimme der Discoverability nicht zu. 21:31:01 <str4d> Und wir sollten mindestens einen weiteren Angriffsvektor machen, um ein Gefühl dafür zu bekommen, wie sich das vergleichen lässt. 21:31:09 <hottuna> Ein passiv protokollierender Node würde nie entdeckt werden. 21:31:17 <str4d> hottuna: du meinst, es sollte high sein? 21:31:17 <hottuna> Klar. 21:31:29 <str4d> hottuna: falsche „Discoverability“. 21:31:47 <hottuna> wie auch immer sich „nicht entdeckbar“ übersetzen lässt 21:31:53 <str4d> Dies ist ein defensives Modell. Es geht um die Discoverability der Schwachstelle durch den Angreifer. 21:32:00 <psi> Die Ressourcen zum Starten eines Angriffs wären ziemlich offensichtlich, es sei denn, sie haben alle Kisten gepwnd 21:32:12 <hottuna> oh. Verstehe. 21:32:18 <dg> Timing-Angriffe sind speziell und vielleicht sowieso nicht so gut auf uns anwendbar.. 21:32:25 <hottuna> Oh, in dem Fall stimme ich zu. 21:33:28 <psi> Für einen Timing-Angriff bräuchte man entweder den Überblick von oben oder den Besitz vieler Nodes (wie viele? kA) 21:33:38 <str4d> Severity ist, wie schlimm wir den Angriff einschätzen; Priority ist die Reihenfolge, auf die wir uns konzentrieren sollten. 21:33:55 <dg> Oh. 21:33:55 <psi> nicht sicher, ob eine Vogelperspektive auch reichen würde 21:33:57 <dg> Ja, 4/5. 21:34:10 <str4d> Lassen wir diese Klassifizierung fürs Erste stehen und machen eine weitere zum Vergleich. 21:34:30 <psi> wenn man über 4/5 nachdenkt: WENN sie Timing-Angriffe machen können, ist praktisch alles mit geringer Latenz betroffen 21:34:33 <psi> affected* 21:34:54 <psi> Priority ... nicht sicher, ob 5/9 passend ist 21:35:15 <str4d> „Tagging-Angriffe“ sollten leicht zu klassifizieren sein. 21:35:32 <str4d> psi: Wir werden nicht wissen, was Priority bedeutet, bis wir mehr klassifiziert haben. Klassifizierung ist ein iterativer Prozess. 21:35:38 <psi> okay 21:35:48 <str4d> Also, Tagging-Angriffe. 21:36:15 <psi> Nachrichten taggen? router taggen? 21:36:48 <str4d> Nachrichten 21:36:59 <str4d> (so ungefähr) 21:37:07 <str4d> Bestimmen, welchem Pfad eine Nachricht folgt. 21:37:17 <str4d> Damage potential: mid? 21:37:30 <psi> mid einverstanden 21:37:38 <psi> in gewissem Sinne low 21:37:43 <hottuna> Damage potential: lo 21:37:47 <hottuna> low-mid 21:37:58 <str4d> Tagging (falls möglich) wird nur Informationen innerhalb eines bestimmten tunnel offenlegen 21:37:58 <psi> es hängt von der Situation ab 21:38:01 <str4d> Reliability: low. 21:38:01 <psi> ja 21:38:08 <str4d> Oder ... 21:38:10 <str4d> Hmmm. 21:38:41 <psi> auf welchem Scope würde das Tagging gemessen? 21:38:58 <hottuna> Wenn sie in einer Situation verwendet würden, in der man die tunnel-Teilnehmer identifizieren könnte, würden sie jedes Mal funktionieren, oder? 21:39:00 <str4d> Exploitability und Discoverability sind low – es sollte unmöglich sein, die Nachrichten selbst zu taggen, und Kollusion erfordert die exakte Platzierung von routers. 21:39:20 <hottuna> E:low 21:39:21 <str4d> psi: eine Nachricht, die zwischen zwei Endpunkten geht (ein Client oder Server). 21:39:23 <hottuna> D: low 21:39:39 <psi> ich stimme zu LOW 21:39:45 <psi> E und D 21:39:50 <str4d> hottuna: genau. Wenn ein Tagging-Angriff entdeckt würde, würde er jedes Mal funktionieren. 21:40:13 <hottuna> also, R: high? 21:40:21 <str4d> Aber eine solche Entdeckung sollte unmöglich sein, weil alles signiert ist. 21:40:51 <str4d> Aber das hängt vom Tagging-Angriff ab. 21:40:56 <str4d> Message Tagging: high. 21:40:57 <psi> wenn sie deine Keys haben, können sie auch signieren 21:41:06 <str4d> Collusion Tagging: mid. 21:41:07 <hottuna> str4d, klar, aber Discoverability ist eine andere Metrik 21:41:13 * str4d sagt für den Moment high. 21:41:28 * hottuna ist zufrieden 21:41:44 <str4d> Affected users: Nur Nutzer mit bösartigen Nodes in ihren tunnel sind betroffen. 21:42:02 <psi> low 21:42:16 <hottuna> A: höchstwahrscheinlich low 21:42:26 <str4d> Okay: 21:42:26 <str4d> Damage Potential: low 21:42:27 <str4d> Reliability: high 21:42:27 <str4d> Exploitability: low 21:42:27 <str4d> Affected Users: low 21:42:27 <str4d> Discoverability: low 21:42:28 <str4d> Severity: 2/5 21:42:29 <str4d> Priority: 2/9 21:42:52 <hottuna> sieht gut aus 21:42:59 <psi> klingt gut 21:43:22 <str4d> fühlt sich gut an 21:43:57 <hottuna> weiter zu einer echten Bedrohung? 21:44:28 <str4d> Sollen wir schnell die restlichen Meeting-Themen durchgehen und dann hierzu zurückkommen? 21:44:37 <hottuna> ok 21:44:56 * str4d streicht 4) Diskussion der Dokumentation, das wird zu lange dauern. 21:45:12 <str4d> 2) Website-Überarbeitung – zur Vorbereitung auf den Launch durchsehen. 21:45:35 <psi> Bei der Site-Überarbeitung geht es um besseres CSS, oder gibt es mehr? 21:45:48 <str4d> Abgesehen von diesem Klassifizierungsprozess (oder dem Entfernen der Klassifizierungen), was muss noch getan werden, bevor welterde die Site-Überarbeitung „launcht“? 21:46:12 <hottuna> Ich weiß es nicht. 21:46:21 <str4d> psi: „besseres“ CSS, aber viele strukturelle Änderungen und am Layout. 21:46:32 <str4d> Ich denke, strukturell ist alles bereit. 21:46:50 <hottuna> Wie automatisch ist der Prozess zum Aktualisieren der Übersetzungen? 21:46:50 <str4d> Vollständig. 21:47:06 <hottuna> Wie häufig ist er? 21:47:28 <str4d> Immer wenn ich ihn aktualisiere. 21:47:45 <hottuna> Ok. 21:47:48 <str4d> Bisher: Immer wenn ich String-Änderungen sehe, lasse ich die Skripte laufen, um die Übersetzungsstrings zu extrahieren und zu aktualisieren. 21:47:50 <psi> ich muss los, bin in 30 Minuten wieder da 21:47:56 <hottuna> Ich denke, das ist gut genug. 21:48:01 * str4d wird bis dahin weg sein. 21:48:30 <str4d> psi: Du kannst die DREAD-Diskussion dann gerne fortsetzen :) 21:48:44 <hottuna> oh, str4d: Der riesige Download-Button auf der Startseite scheint sich nicht automatisch auf die neueste Version zu aktualisieren 21:48:45 <str4d> Es gibt bekannte CSS-Probleme in IE 7 und 8, IIRC 21:49:00 <str4d> hottuna: Das ist ein weiterer Bug, über den ich mit welterde sprechen muss. 21:49:09 <hottuna> ok. gut. 21:49:25 <str4d> Immer wenn sich eine .py-Datei ändert, soll ein Skript den Server neu starten (und wenn sich Übersetzungen ändern, werden sie neu kompiliert) 21:49:49 <str4d> Aber aus irgendeinem Grund werden Änderungen an .py-Dateien auf welterdes Server nicht erkannt ... 21:49:49 <str4d> (Früher wurden sie es) 21:50:24 <str4d> Okay, wenn es sonst nichts gibt, dann I 21:50:43 <str4d> bin ich mit der Überarbeitung zufrieden, und sobald der .py-Bug behoben ist, kann sie live gehen. 21:50:52 <hottuna> Alles klar! 21:51:11 <str4d> (IE-7/8-CSS wird entschärft, sobald ich dazu komme, aber ich betrachte es nicht als Blocker) 21:51:23 <hottuna> Klingt vernünftig. 21:51:42 <str4d> „live“ == welterde wird es unter https://geti2p.net live schalten (die URL haben wir vor mehreren Meetings beschlossen), aber www.i2p2.de bleibt wie es ist. 21:51:52 <iRelay> Titel: I2P Anonymous Network - I2P (auf geti2p.net) 21:52:00 <hottuna> Warum bleibt i2p2.de so wie es ist? 21:52:03 <str4d> Dann werde ich Tests fahren, prüfen, ob Google etc. damit zufrieden sind. 21:52:30 <str4d> hottuna: Falls etwas Katastrophales passiert und wir zurückrollen müssen. 21:52:42 <hottuna> ok, also nur vorübergehend 21:52:51 <str4d> Erst wenn wirklich alles geprüft und bereit ist, werden wir i2p2.de per 301 auf geti2p.net umleiten 21:53:15 <hottuna> das ergibt Sinn 21:53:23 <str4d> Weil 301 eine permanente Verschiebung ist und Suchmaschinen ihre Links aktualisieren lässt. 21:54:08 <str4d> Der Legacy-Redirect-Code verwendet vorerst 302-Weiterleitungen, wird aber auf 301 umgestellt, sobald alles passt (damit wir keinen PageRank durch alte Links verlieren) 21:54:28 <str4d> Okay, weiter geht's: 21:54:28 <str4d> 3) Roadmapping. 21:54:42 <str4d> hottuna: du bist dran. 21:55:44 <str4d> Ihr habt etwa zehn Minuten meiner Zeit (vielleicht mehr für alle anderen, die noch hier sind) 21:55:45 <hottuna> Roadmap? Alles, was ich weiß, ist, dass ich in letzter Zeit etwas mehr Zeit habe und mir wieder den DHT-Code anschaue. Besonders den Code zur Reply-Verarbeitung. 21:56:08 <hottuna> Ich habe sonst nicht viel hinzuzufügen. 21:56:48 <str4d> Die aktuelle Roadmap für 0.9: 21:56:48 <str4d> Ein paar Seed-Daten in die Distribution aufnehmen, damit kein zentrales reseed benötigt wird? 21:56:48 <str4d> Reachability Mapping / teilweise erreichbare Peers handhaben / erweiterte restricted routes 21:56:49 <str4d> Hilfeseiten und Website verbessern 21:56:49 <str4d> Mehr Übersetzungen 21:56:56 <str4d> SSU-Disconnect-Nachricht 21:56:57 <str4d> Iterative floodfill-Lookups 21:57:13 <str4d> Ich habe keine Ahnung, wo wir bei manchem davon stehen oder wann es zuletzt aktualisiert wurde. 21:57:54 <hottuna> Die floodfill-Lookups sind, soweit ich sie verstehe, iterativ. 21:57:59 <str4d> 1.0–3.0 wurden zuletzt 2008 aktualisiert. 21:58:14 <str4d> 0.9 wurde 2010 hinzugefügt. 21:58:14 <dg> restricted routes ist unwahrscheinlich 21:58:37 <hottuna> Ich muss in ein bis zwei Minuten los 21:58:42 <str4d> Ich denke, eine vernünftige Bewertung der Roadmap braucht ein weiteres Meeting mit mehr Beteiligung. 21:59:01 <hottuna> Einverstanden. 21:59:14 <str4d> hottuna: gut zu hören, dass du wieder in den DHT-Code einsteigst. 21:59:29 <str4d> Verschoben auf später. 21:59:33 <hottuna> Und das eigentliche Bedrohungsmodell sollte auch angegangen werden. 21:59:43 <str4d> Okay. 21:59:47 <hottuna> Könnten wir dafür beim nächsten Mal ein langes Meeting machen? 22:00:35 <str4d> hottuna: Ich hatte gehofft, 2 Stunden würden reichen, aber wir haben mindestens eine Stunde damit verbracht zu diskutieren, ob es überhaupt lohnt, es zu tun>_< 22:00:36 <hottuna> Ich muss los, aber danke fürs Meeting, str4d. Du bist ein Naturtalent! 22:01:19 <str4d> Wir haben keine Zeit, zu 1c) zurückzukehren, also: 22:01:23 <str4d> str4d *baf*t das Meeting ab