[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [FYI] "Trusted Computing' Frequently Asked Questions" by Ross



* Andreas Jellinghaus wrote:
> ich wundere mich das du erst eine private Antwort möchtest
> "(mir privat)" und dann die private Antwort mit CC: an
> die Liste beantwortest. Im vorliegenden Fall aber ok.

Ob der Generalität der Antwort, ja.

> Es zeigt sich jedoch auch, das deine Sicht teilweise etwas
> begrenzt ist: beim Thema IP Telefonie fällt dir die IPsec
> Verbindung zum Gateway ein, eine Telefonie ganz ohne POTS 
> und Telefonnummern bleibt aussen vor.

Ich schrieb von IPSec Tunnel ab dem Gateway, nicht bis zum Gateway.
Der Lokal Loop sei unverschlüsselt, weil das das Hardware-Phone nicht kann.

> Deine Kenntnisse von IPSec scheinen mir aber leider unvollständig.
>> IPSec bietet schlicht einen Layer2 Link.
>
> Ist zum Beispiel falsch.

Es ist richtig. Layer2 Links sind nicht notwendig an Interfaces gekoppelt.
Diese Implementationsfreiheit als Vor-/Nachteil von IPSec zu werten, zeugt
von Unverständnis der zugrunde liegenden Technik.

> Deine Aussagen zu den routing und firewall tabellen gehen am Problem
> vorbei: wird der Endpunkt eines Tunnels geschwenkt, so sollte IMO keine
> Änderung der Firewall und Routing Tabellen notwendig werden.

Abgesehen von der Umkonfiguration des Tunnelendes sind keine weiteren
Änderungen nötig. Jedenfalls nicht in meinen Installationen.

> Das Problem mit der Firewall scheint an dir vorübergegangen sein.
> Der Kommentar
>> Depends. Ich kann es zweimal sehen eingehend sehen.
> lässt nicht erkennen, das es ein Problem sein kann,
> wenn Packete vor der Verschlüsselung nicht durch die
> Firewall Regelwerke greifbar sind.

Ich kann aus Deiner Interpretation nicht herauslesen, daß Du verstanden
hast, was ich schrieb. Denn da steht (von Dir zitiert), daß ich sehr wohl
an allen Stellen filtern kann. Wenn Du es nicht kannst, ist Deine
Implementation oder Konfiguration kaputt. Das ist aber kein generelles
Problem von Protokollen.

> Weiter ist deine Vorstellung
>> Ein Tunnel ist ein Interface
> im IPSec kontext nicht korrekt: ein blick auf die dokumentation
> zu setkey zeigt, wie IPsec im tunnel modus arbeiten kann,
> ohne das Interfaces dadurch erzeugt werden.

Bitte verwechsle nicht Implementation und Protokoll. Ich bin mit der
Formulierung 'Interface' auf Deine Ausführungen eingegangen, obwohl ich auch
einige IPSec Tunnel ohne explizite Tunnelinterfaces in Betrieb habe.

> Das die Howtos zu IPsec grottenschlecht sein sollen kann
> ich nicht nachvollziehen, z.B. die NetBSD Dokumentation
> fand ich sehr hilfreich. Problem ist, das es kaum
> weitergehende Dokumentation gibt, zur Kombination
> Routing, Firewall, Tunnel und IPsec gibt es nicht viel.

Die Ansprüche an Doku unterscheiden sich bei uns. Was Du als gute Doku
empfindest, ist mit zu trivial. Was Dir an fortgeschrittener Doku fehlt,
habe ich in Schulungsunterlagen, Literatur, etc. pp. Meine Einschätzung der
Howtos unterscheidet sich somit nicht von Deiner.

> Weitere kritik an der IPSec Implementierung in linux 2.6.*
> wäre noch, das die SAD packete verwirft, details bekommt
> man leider nicht.

Ich möchte aus gutem Grunde nicht über Implementierungen von Protokollen
reden, wenn es um die Protokolle als solche geht. Bitte respektiere meine
Ablehnung dieser billigen Nebenkriegsschauplätze.

>> Da sind sie in bester Gesellschaft. Denn Du behautest auch nur die
>> (Nicht)Relevanz von Szenarien.
>
> Welchen Sinn macht der Einschub "(Nicht)"? Wer ein Scenario vertritt, der
> muss es begründen können. Der anderen Seite reicht es, nach einer
> Begründung zu fragen. Und wenn keine Begründung kommt, so kann man das
> Scenario doch wohl ignorieren?

Dann werde ich Deine Scenarien in Zukunft schlicht ignorieren. Danke.

>> Dazu hatte ich bereits in dem vorigen Artikel etwas geschrieben. TCPA kann
>> das nicht leisten. TCPA kann eben nicht die Mentalität und Motivation des
>> Anwenders zertifizieren. Deswegen kann die RIAA problemlos an solchen Netzen
>> teilnehmen und die bösen Buben ermitteln.
>
> Nun, rechner wissen nichts über böse Buben, soweit sind wir
> uns wohl einig. Die RIAA kann jene P2P anwendung laufen lassen
> und auf netzwerk ebene sehen, mit welchen IP kommuniziert wird.

Damit ist die Begründung, warum TCPA den P2P Tauschbörsen helfen sollte, von
der Rechteindustrie nicht länger verfolgt werden zu können, als unsinnig
entlarvt.

Das war Dein Szenario für TCPA, es ist hiermit widerlegt.

> Überall wo eine indirekte Kommunikation benutzt wird, ist nur
> der erste Hop ersichtlich. Tritt der Rechner der RIAA selbst
> als vermittler auf, so kann die RIAA nur die Kommunikationspartner
> sehen, nicht aber den Datenstrom.

Was hat das damit zu tun? Wir reden über P2P, nicht über Mixnetze.
Bitte versuche nicht Dein Szenario zu einem moving Target zu machen.
Damit handeltst Du Dir nur Plonks ein.

> [tcpa für sichere private kommunikation]
>> Sicher, allerdings begründest Du auch hier nicht die Relevanz dieses
>> Szenarios. Ich könnte es unter 1+1=3 einsortieren und neige auch dazu.
>
> Frage und ich antworte. Zum Beispiel ein p2p netz oder ein System
> zur verschlüsselten Kommunikation.

Dieses Szenario ist soeben von Dir als zerlegt bestätigt worden. Es gibt
nichts weiter zu diskutieren.

> Der Vorteil gegenüber PGP und SMTP(-TLS) ist, das man vor übermitteln
> sicherstellen kann, das der Zielrechner keine unsichere Software oder
> Hardware enthält, etwa Software die nach entschlüsseln der Nachricht
> diese dritten quellen zugänglich macht.

Ja, und? Das hält die Rechteindustrie nicht davon ab, teilzunehmen.
Also taugt TCPA nicht zum Schutz von P2P. Im Gegenteil, es stärkt die
Rechteindustrie zu Lasten der normalen Benutzer. Dieses wird hier kritisiert.
Zu Recht.

> TCPA für sichere private Kommunikation ist aber nur sinnvoll,
> wenn TCPA auf Rechnern für Privatpersonen verbreitet ist. Daran
> glaube ich nicht, und gebe das als Schwäche gerne zu.

Mir ist der Hintergrund dieses neuen Szenarios unklar. Aber laß mal, ich
kann mir vorstellen, was da jetzt kommt und habe keinen Bock darauf, Dir
nochmals zu erklären, was der Unterschied zwischen TCPA und GPG ist.

>> Chinesische Dissidenten werden mit TCPA eher Schwierigkeiten bekommen, weil
>> auf den ausgelieferten Systemen sichergestellt werden kann, daß eine
>> Nachinstallation von Fremdsoftware nicht zulässig ist.
>
> Nun, einen Rechner auszuliefern auf dem die Software nicht verändert
> werden kann, das ist auch heute schon möglich. Wird das heute schon
> gemacht, und warum wird gewartet, bis TCPA verfügbar ist? Ist
> der vorteil von TCPA in punkto Sicherheit notwendig?

Out of Context Error: Paragraph ignored.

> Zudem schreibst du: kann. Muss also nicht? Wenn die Rechner also
> mit beliebiger Software laufen, wäre dann nicht TCPA ein Vorteil?
>
> Werden die Rechner der Masse der Benutzer auf eine Software 
> fest eingestellt, und warum?

Context: Chinesische Dissidenten. Du hattest behauptet, die hätten einen
Vorteil von TCPA. Das war unsunstanziert. Ich hatte ausgeführt, warum TCPA
für einen Dissidenten nachteilig ist.

Entweder Du begründest endlich mal eins Deiner Szenarien sinnvoll, oder ich
breche die Diskussion ab, weil Du trollst.

>> Der Internetzugang kann mit TCPA so gebaut werden, daß er nur noch
>> bei unmodifiziertem Rechner funktioniert.
>
> Ja. Netzwerkzugriff auf einen Proxy beschränken, und der will eine
> TCPA authentifikation. Vergleichen wir das mit der Situation ohne
> TCPA: Netzwerkzugriff auf einem Proxy beschränken.

Context: Chinesische Dissidenten. Mit TCPA kann China nun sicherstellen, daß
während der Internetverbindung auf dem Dissidentensystem nichts läuft, was
zur Verschleierung der Kommunikation oder zur Verschlüsselung dient, so daß
der chinesische Staat keinen Zugriff mehr hätte.

Wo siehst Du da einen Vorteil für den Dissidenten?

> Wo ist also der genaue Vorteil?

Es ist *Dein* Szenario, warum TCPA so gut ist. Ich betrachte diese Frage als
Bankrotterklärung Deiner Argumentationskette.

> HTTPtunnel kann gestoppt werden, da die Client Software bekannt
> ist. Wenn der Proxy aber eh sehr restriktiv den Zugriff auf
> wohl ausgesuchte Webseiten erlaubt, dann da nicht viel gewonnen.

Die Weißliste von für gut befundenen Systemen muß gepfegt werden. Mit TCPA
weiß man, daß auch bei Kontakten zu 'bösen' Gegenstellen, die Überwachung
nicht eingeschränkt wird.

Wo siehst Du da einen Vorteil für den Dissidenten?

> [tcpa: eine zentrale hardware/software liste]
>> Die Lobbyarbeit von MPAA und Co. wird diese Lösung vorziehen.
>
> Das wäre fein, damit bleibt meiner Ansicht nach aus geschilderten
> Probleme die Industrie um Computerspiele aussen vor. Damit wird
> nicht TCPA taugliche hardware weiterhin weit und breit erhältlich
> sein und viele Leute werden keine TCPA taugliche hardware haben.

Dein Optimismus ist mit unverständlich. Völlig.

Ich sehe keinen Grund, warum Computerspiele nicht auf TCPA System laufen
sollten. Wegen modernere Hardware? Treiber für TCPA System zertifizieren zu
lassen ist einfach und schnell möglich. Soviele Hersteller gibt es nicht.

> Oder natürlich ein Zwang von MPAA und Co zu TCPA, der die
> Spieleindustrie stark beeinflusst. Ich weis das MPAA eine
> viel bessere Lobby hat, aber ist die Spieleindustrie 
> nicht inzwischen größer im Umsatz als die MPAA?

Man sagt der Spieleindustrie, daß mit TCPA Raubkopien der Spiele verhindert
oder beschränkt werden können. Mit einigen gezielten Werbestrategien ist der
Umschwung da. Dann verdient die Spieleindustrie noch mehr und wird sich
nicht sträuben.

> [tcpa liste selbst führen]
>> Es skaliert nicht (einfache Überlegung) und ist nicht sicher
>> (Gegenbeispiele sind über Installation fremder CryptoProvider durch
>> Fehler in den NSA Keys bekannt).
>
> Nun, es mag für den allgemeinen Fall nicht skalieren etc.

Was diskutierst Du dann noch?

> Aber für geschlossene Systeme (mir fällt auch hier nur wieder
> der olle Geldautomat ein), da ist Skalierung kein Problem und
> durch die eigene Liste wird die Sicherheit erheblich erhöht,
> da klar abgegrenzt wird was erlaubt ist.

Das Szenario Geldautomat wurde bereits mehrfach zerlegt.
Bitte laß es endlich fallen. Es zieht nicht.

> Umgekehrt ist sogar der Einsatz einer allgemeinen Liste für solche
> geschlossene Systeme kaum rechtzufertigen, hat eine Bank doch erheblich
> mehr durch ein virtualisiertes System zu verlieren, als etwa eine Online
> Videothek.

Richtig. Also?

> [pay per view / filmindustrie]
>> Korrekt. Trotzdem existiert die Industrie seit Jahren. Trotz Video- und
>> Kassettenrekorder die beide als Untergang der Kultur betrachtet wurden.
>> Internet ist nichts weiter als ein weiterer Aufschrei der Industrie.
>
> Die Reichweite einer Kopie ist wichtig: wieviele Leute können
> in einem Vorgegebenen Zeitraum eine Kopie guter Qualität erhalten.

Ich möchte meine Meinung zur Privatkopie nicht weiter diskutieren. Es gehört
nicht in diese Mailingliste.

> Mit analogen Systemen und dem Tausch im Kreis der Freunde
> und bekannten ist die Reichweite sehr gering. Analog, aber
> industrielle Anlagen für Raubkopien und ein passendes
> Distributionsnetz führen zu einer wesentlich höheren Reichweite.

Also gab es nie Musikkopien auf Kassette und auch nie Filmkopien auf VHS?
Interessant. Nungut, ich habe eine andere Welt kennengelernt.
BTW: Dein Rechteindustrie-Vokabular nervt.

> Der Kritik am Mainstream möchte ich mich gerne anschliessen,
> aber dich nicht ganz davonkommen lassen:
> Wer nicht sucht, der gibt sich mit dem zufrieden, was an
> Ihn herangetragen wird. Ein Gejammer, das nur Schrott an
> dich herangetragen wird, dafür habe ich kein Verständnis.

Ich habe nicht gejammert, sondern das Gejammer der Rechteindustrie
kommentiert. Außerdem habe ich angegeben, wo ich gute Unterhaltung
herbekomme. Deine durchsichtige persönliche Kritik verfängt also nicht.

>> Bitte höre auf, für die MPAA Gedankenketten zu entwickeln, die der
>> Realität nicht entsprechen.
>
> "für" ist deine Interpretation.

Dann hast Du Deine Position selten dämlich vertreten.

>> TCPA ist KEIN Verschlüsselungssystem. Es ist ein
>> Authentifizierungssystem für Datenumgebungen.
>
> Soweit ich informiert bin eher klassifizierung,

Sinnleere Wortklauberei.

>> Ich komme von der Idee eines Dokumentenaustausches und vom Backup.
>> TCPA gestattet mir, meine Dokumente auf fremden Systemen immer noch zu
>> kontrollieren. Das ist gut, denn das befördert den Datenschutz.
> 
> s/TCPA gestattet mir,/TCPA gestattet mir, Anwendungen zu schreiben, die/

Nein.

>> Der Umkehreffekt von TPCA, nämlich der, daß umgekehrt Dokumente, die
>> nicht von mir stammen, bei mir Restriktionen unterliegen, macht mir
>> Bauchschmerzen.
>
> Wenn du das Dokument und damit die Notwendigkeit einen Rechner mit
> TCPA und jener Anwendung zu nutzen akzeptierst, dann ja. Wer
> zwingt dich dazu?

Alle Leute, die mir heute wider besseres Wissen proprietäre Datenformate
zusenden, obwohl sie wissen, daß ich die betreffende Software weder habe
noch laufen lassen kann. Das geht hoch bis zu EU-abgesegneten
Zertifizierungen in der Branche. Kurz die Gedankenlosigkeit der Nutzer, die
ihre lokale Umgebung in alle Welt projezieren.

>> Deine Vorstellung von TCPA deckt sich mit den Informationen, die ich
>> über TCPA habe, in keiner Weise. TCPA ist keine portable
>> Verschlüsselung.
>
> Widersprichst du der Darstellung von TCPA wie von Argh Annonymous
> aufgestellt oder mit meinem Verständnis dieser?

Ich widerspreche deinem Verständnis.

> Bisher habe ich keinen Grund zu glauben, das du richtig über
> TCPA informiert bis und ich nicht.

Es herrscht Religionsfreiheit. Also darfst Du glauben, was Du willst.

-- 
To unsubscribe, e-mail: debate-unsubscribe@lists.fitug.de
For additional commands, e-mail: debate-help@lists.fitug.de