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

[Lutz Donnerhacke <lutz@iks-jena.de>]

On Mon, Aug 25, 2003 at 12:58:04PM +0200, Andreas Jellinghaus wrote:
> wenn ich das richtig sehe, dann verschickt dein slrn
> utf-8 als iso-8859-1 gekennzeichnet...

Nein, das wäre sehr ungewöhnlich.

> > Köntest Du (mir privat) ausführen, warum Du IPSec derartig mißtraust,
> > gleichzeitig eine technisch equivalente Lösung bevorzugst?
>
> die handhabung dieser beiden ist mit nichten equivalent.

Natürlich. SSL ist ein Applikationstunnel und IPSec ein Netztunnel.
SSL bietet Layer4, IPSec Layer2.

> ssl/tls ist fein abgekapselt, es führt zu keinen probleme mit
> unterliegenden protokollen, und darüber liegende protokolle haben
> keine oder nur leichte anpassungn ("https" im url etc.).

Technisch gesehen, ist https etwas völlig anderes als http. Die Anwendung
muß statt connect(2), ssl_connect(3) aufrufen. Es geht also nur mit
Anwendungen, die explizit ssl beherrschen.

> das macht das debugging recht einfach und angenehm, und
> man kann sich leicht kleine hilfsprogramme zusammenschustern
> (etwa 10 zeilen perl für http proxy mit ssl entzerrung und
> flickerei im html source).

HTTP über IPSec ist noch leichter zu debuggen: Außerhalb des Tunnels mit
einem Sniffer oder normalen Proxy.

> die interaktion von routing und firewall ist kaum da, das kann
> man noch gut verstehen. wenn ip tunnel ins spiel kommen, dann
> wussten selbst rusty russel und harald welte nicht, wie die
> genaue interaktion ist. wenn man es herausfindet, kann man das
> aber auch noch in den griff bekommen und verstehen, es ist
> sogar sinnvoll geregelt (zumindest linux 2.4.*).

IPSec bietet schlicht einen Layer2 Link. Darauf kann man routen oder
sonstwas treiben. Das ist sehr trivial.

> wenn in dieses mix aber noch die spd von IPsec mit hereinkommt
> in der implementation von linux 2.6.*, dann gibt es nicht nur
> eine regeldatenbank (routing) oder zwei (firewalling), sondern
> nun drei, und wie diese interaggieren ist sehr schwer zu verstehen,
> insbesondere wenn IPsec tunnels ohne explizites tunnel interface
> konfiguriert wurden.

Man kann sich natürlich gern und fix in den Fuß schießen, wenn man bei der
Implementation die Layer2 Funktion nicht sehen will. Aber das ist nicht das
Problem von IPSec.

> zudem ist debugging aktuell ein alptraum, und es ist unwahrscheinlich
> das sich daran was ändert.

Ich kann IPSec gut und schnell debuggen.

> beispiel:
> eingehend sieht man ein ipsec packet im firewalling
> zwei mal, ausgehend ins ipsec nur einmal.

Depends. Ich kann es zweimal sehen eingehend sehen.

> oder routing entscheidung: vor oder nach dem einpacken in einem ipsec
> tunnel, oder gar zweimal? (freeswan: zweimal, linux 2.6: je nach
> konfiguration.)

Es sind verschiedene Ebenen. Ein Tunnel ist ein Interface, dessen Pakete
selbst geroutet werden. Einmal verstanden, immer begriffen.

> ipsec als isolierten teil betrachten geht nicht: wird
> ipsec hinzugefügt oder entfernt, so muss oft routing- oder
> firewall tabelle verändert werden, oder beides.

Das ist bei allen Tunneln so.

> ja, es gibt simple, kleine, verständliche ipsec scenarien,
> die ganz einfach sind und in howtos beschrieben sind. dafür
> taugt ipsec. für mehr IMO nicht.

Ich verwende IPSec oft und viel. Ich kann Deine Einschätzung also nicht
teilen. Für jemanden, der ohne Grundkenntnisse an IPSec geht, dabei noch die
grottenschlechten Howtos bekommt, ist es aber sehr wohl ein Problem.

Im übrigen gilt das auch für SSL und SSH. Jedenfalls wenn man wie bei IPSec
hinter die Kulissen schauen will.

> ein ah/espdump programm wäre sehr praktisch zum debugging:

tcpdump exisitiert, tcpdump kann (wenn Schlüssel bekannt) auch reinschauen.

> ah/esp packete wie tcpdump sniffen und speichern, aber aus
> der lokalen sad die schlüssel zum dekodieren ziehen, und
> so den inhalt extrahieren.

Das geht.

> momentan wird der nutzen von diagnose tools wie tcpdump und co durch
> ipsec stark eingeschränkt.

Das ist allerdings der Sinn von Krypto im Netz. Auch ssl/ssh Verbindungen
kann man ohne Schlüssel nicht mitlesen.

> dieser effekt ist bei tls/ssl wesentlich geringer.

Nein. Man hat dort nur durch geschickte serverseitige Konfiguration einen
Großteil der Konfigurationsfreiheiten versteckt. Und man muß für SSL alle
Anwendungen umschreiben. Über IPSec läuft aber selbst Windows mit Broadcasts.

> zudem ist ssl sehr gut in viele anwendungen integriert
> und funktioniert im grossen ganzen. ipsec funktioniert
> im wesentlichen genau dann, wenn die anwendungen davon
> nichts wissen müssen. das ist richtig und auch ganz
> nett für die gesicherten filialnetze und auch den
> roadwarrior.

Eben. Jedes hat seinen Zweck.

> wenn aber spontan irgendwelche verbindungen zu bisher
> unbekannten gegenstellen aufgebaut werden sollen:
> mit tls/ssl kein problem. ipsec?

Mit IPSec würde das auch gehen, ist aber sinnlos. Man will keinen
Kryptotunnel zum Server, sondern eine verschlüsselte Kommunikation. SSL
bietet letzteres unter Verzicht auf ersteres. Das ist für diese Fälle
ausreichend.

> mal eben ipsec konfigurieren um eine webseite anzuschauen oder ein
> formular dort auszufüllen? das macht keinen sinn. web server haben ja
> wenigstens meist statische ip addressen, da könnte man sich mie OE
> helfen. aber ip telefonie?

IP Telefonie macht man über IPSec am schnellsten. Besonders, wenn man
Hardware IP Telefone hat. Der IPSec Tunnel endet aber nicht am Telefon,
sondern am Gateway, daß man eh' zum Wählen braucht. Geht problemlos.

>> Deine Argumentation stößt mir wieder mal auf: Warum hatte ich auch nur
>> angenommen, Du könntest den ernsthaft nachvollziehbaren Gedankengang
>> auch nur sachlich in Erwägung ziehen?
>
> Wer ein Scenario aufstellt, der muss sich auch die Frage gefallen lassen,
> wie das Scenario eintretten kann, welche Voraussetzungen damit möglich
> sind, wie wahrscheinlich es ist.

Sicher. Nur ist Deine Antwort nicht in der Form ausgefallen. Sondern als
Angriff gegen den Fragesteller.

> In dieser Diskussion haben sich viele beteiligt, die solchen
> Überlegungen ausweichen, die nicht begründen können oder wollen,
> warum ihr Scenario mehr Relevanz hat als eines, in dem 1+1=3 ergibt.

Da sind sie in bester Gesellschaft. Denn Du behautest auch nur die
(Nicht)Relevanz von Szenarien.

> zum thema p2p mit tcpa:
>  [ ] du hast die diskussion verfolgt und die referenzierten
>      artikel gelesen.

Korrekt.

> cypherpunks, juli/august 2002, Argh! Anonymous.
> Wenn es probleme beim googeln gibt, so kann ich dir
> die artikel gerne schicken.

Danke, nicht nötig.

> kurzzusammenfassung: es geht nicht um den tausch von DRM
> geschützten dateien, sondern um ein p2p netz, das nicht von
> riaa und mpaa mit falschen daten geflutet werden kann, weil
> nur authorisierte software teilnehmen kann. ebenso kann nicht
> gelogen werden (z.B. bei den freigegebenen dateien).

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.

> tcpa kann nicht nur das knacken von DRM software erschweren,
> sondern auch software für private kommunikation sicherer machen.

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.

> als positives beispiel werden meist chinesische dissidenten
> o.ä. zitiert, als negatives der feind des tages (z.Zt. brauner sumpf,
> terroristen, kinder pornographie).

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. Der Internetzugang
kann mit TCPA so gebaut werden, daß er nur noch bei unmodifiziertem Rechner
funktioniert. Irrelevant? Nicht mehr als Deine unsubstanzierten Vorteile für
den Dissidenten.

> wie werden listen von vertraunswerter hardware und software erstellt
> und verwaltet? Ein paar Leute befürchten, das es nur eine zentrale
> liste gibt, die jeder benutzt. Dann muss aber die Video komponente
> bestandteil sein, damit die Online Videotheken mit DRM zufrieden
> sind. Und dann taucht beschriebens Problem auf.

Die Lobbyarbeit von MPAA und Co. wird diese Lösung vorziehen.

> Wenn dagegen für jeden zweck oder gar jedem anbieter eigene listen
> geführt werden, so ist das erheblich mehr arbeit, erlaubt zwar
> mehr flexibilität, aber ob das noch skaliert oder sicher ist?

Es skaliert nicht (einfache Überlegung) und ist nicht sicher (Gegenbeispiele
sind über Installation fremder CryptoProvider durch Fehler in den NSA Keys
bekannt).

> Ich frage mich, warum Pay per view schlecht ist.

Ich mag es nicht. Mehr schrieb ich auch nicht.

> Mit einem solchen Geschäftsmodell kommt die Filmwelt aber nicht
> klar, und es ist fraglich, ob es dafür viele Kunden gibt.
> Daher braucht die Filmwelt eine Möglichkeit den Preis auf
> viele Kunden zu verteilen. Wenn die Privatkopie nach deutschem
> Verständnis möglich und erlaubt ist, inclusive der Kopie von
> der Kopie, so kann sich ein verkaufter Film rasant auf sehr, sehr
> viele Leute verteilen, und nur sehr wenige müssen den Film kaufen.

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.

> Interessant ist, das nur in der heutigen Welt mit weitgehend
> aufgepresstem Einheitsgeschmack ein solches Problem auftritt.

Richtig. Die sinkenden Verkaufserlöse der Musikindustrie sind in der
schlechten Qualität begründet.

> Wo die Geschmäcker sehr unterschiedlich sind, so bilden sich
> eher kleine Cluster von Leute mit einem bestimmten Geschmack,
> und wenn jeder solcher Cluster eine Kopie kauft, so könnte
> das ausreichen.

So funktioniert das auch. Nur ist es für Nichtmainstream-Geschmäcker (wie
praktisch meine gesamte Umgebung) sehr schwer geworden, überhaupt etwas zu
kaufen, da der Mainstream die Alternativen erdrückt. Also geht praktisch
meine gesamte Umgebung in den Medien- und Kaufboykott. Das hat nichts mit
selbstgemachten Kopien zu tun. Ja, interessante Konzerte und Co. werden
bezahlt.

> Zudem scheitert das ganze modell natürlich an der Möglichkeit,
> das Freunde einen Film durchreichen.

Das Szenario kannst Du knicken. Es ist zu aufwendig. Die Motivation fehlt.

> Wenn jeder nur für direkte Freunde und Bekannte kopien macht,

Bitte höre auf, für die MPAA Gedankenketten zu entwickeln, die der Realität
nicht entsprechen. Es nervt.

> Ich würde mich sehr freuen, wenn es finanziell weiter eine
> tragfähiges Geschäft ist, Filme zu produzieren und damit
> Einnahmen zu bekommen.

Kein Problem. Es würde reichen, wenn die produzierten Filme/Musik meinen
Geschmack auch nur annähernd treffen würden. Ich war das letzte Mal vor der
Jahrtausendwende im Kino (insgesamt vielleicht sechs mal seit 1990) und der
Fernseher ist bei uns daheim etwas eine Stunde pro Woche an. Dann läuft
irgendwas auf arte/3sat oder so. Nebenbei wird gebügelt (Wer bügelt, wählt
das Programm aus). Auf der Kulturarena haben wir dagegen echtes Geld gelassen.

> Das Modell, Filme zu verkaufen, kann scheitern, wenn Kopien möglich
> sind. Welche Alternativen gibt es?

Mehr als den Mainstream bedienen. Ich betrachte das derzeitige industrielle
Angebot an Musik/Film als intellektuelle Beleidigung. Lieber les ich ein Buch.
(Dafür wird auch viel Geld ausgegeben, obwohl es Kopierer/Scanner/eBook gibt.)

> Ein solches Pay per view System muss ja nicht kundenfeindlich sein, es
> kann trotzdem erlauben anzuhalten, zu spulen, denn film gleich ein
> zweites mal zu sehen und so weiter.

Man kann sich vieles ausdenken. Es ist nur irrelevant, solange das Angebot
dahinter schrottig ist. Man wird dem Mainstream zwar mehr Geld aus der
Tasche ziehen können, doch wird es den Rest nicht zur Geldausgabe verleiten.
Im Gegenteil.

> Nur wenn ich zwei monate später einen Film noch einmal
> sehen will, ich habe kein Problem damit, nocheinal
> zu zahlen.

Das Modell heißt Kino.

> Ich habe kein Problem mit Pay per View per se,
> das Problem sind akzeptable Rahmenbedingungen.

Ich habe ein Problem mit Pay per View. Und?

> Ich kann mit vorstellen, das am Ende ein Pay
> per View System sich durchsetzt, das für Kunden
> angenehme Konditionen hat, die weltweite Vielfalt
> der Musik und Filme bieted und Künstler und
> Produzenten einen vernünftigen Ertrag bringt.

Ich möchte das bezweifeln. Alle Erfahrungen mit industrieller
Rechteverwertung in der Unterhaltung zeigen, daß das Niveau bei steigenden
Entgelten immer weiter abrutscht. Pay per View wird das nur noch verstärken.

> Wie man dahin kommen kann ist schwierig. Im wesentlichen
> fällt mir auf, das in der Vision die Distribution keine
> wichtige Rolle mehr spielt. Damit ist klar, wer viel zu
> verlieren hat.

Die 'Verleiher'? Täusche Dich da bitte nicht.
Die 'Raubkopierer'? *Lach* Üble Industriepropaganda.

> So, zurück zu TCPA:
> > >> Naja - so unportabel wie mit TCPA waren Daten noch nie;-)
> > >
> > > Ach? Daten aus einem IBM Sicherheitsmodul für Geldautomaten
> > > auszulesen ist einfacher? Erkläre mir das bitte.
> > 
> > Geheime Schlüsseldaten sind schon etwas anderes als die privaten Briefe.
>
> Verschlüsselte emails sind portabel - egal ob der schlüssel nun
> vom Typ PGP oder TCPA ist.

TCPA ist KEIN Verschlüsselungssystem. Es ist ein Authentifizierungssystem
für Datenumgebungen. TCPA ist dafür da, die Portabilität zu unterbinden.

> Aber erklär mir doch bitte, wie du auf private Briefe kommst?

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.

Der Umkehreffekt von TPCA, nämlich der, daß umgekehrt Dokumente, die nicht
von mir stammen, bei mir Restriktionen unterliegen, macht mir Bauchschmerzen.

> Warum sollte jemand private Briefe mit TCPA verschlüsseln wollen? In der
> Diskussion mit Peter dachte ich so etwas wie einen Konsenz zu entdecken,
> das TCPA auf dem Server nur Probleme macht, und das es auf dem Client nur
> für Daten ist, die der Server nochmal im klar text hat.

Deine Vorstellung von TCPA deckt sich mit den Informationen, die ich über
TCPA habe, in keiner Weise. TCPA ist keine portable Verschlüsselung.

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