Discussion:
Steuernachrichten
(zu alt für eine Antwort)
Werner Holtfreter
2018-01-07 00:05:08 UTC
Permalink
Hallo,

Wer darf eigentlich Steuernachrichten senden,
wie werden sie gesendet, d.h. auf welchem Weg und
wie wird Missbrauch verhindert?
--
Gruß Werner

www.presseportal.de/blaulicht/pm/110971/3762457
Noch 1984 mussten Flüchtlinge ihre Toiletten selbst reinigen!
Nomen Nescio
2018-01-07 00:41:49 UTC
Permalink
Post by Werner Holtfreter
Wer darf eigentlich Steuernachrichten senden,
Prinzipiell jeder, dessen Newsserver Control-Header in geposteten Artikeln
zulässt.
Post by Werner Holtfreter
wie werden sie gesendet, d.h. auf welchem Weg und
Du fügst einen entsprechenden Control-Header in deinem Posting ein.
Post by Werner Holtfreter
wie wird Missbrauch verhindert?
Das entscheidet jeder Newsserver anhand seiner Konfiguration,
Für Cancel-Nachrichten werden häufig Cancel-Key und Cancel-Lock verlangt.

newgroup und rmgroup erforden meist eine Signatur mit einem festgelegten
Schlüssel. https://www.eyrie.org/~eagle/software/inn/docs/control.ctl.html
Werner Holtfreter
2018-01-07 14:11:26 UTC
Permalink
Post by Nomen Nescio
newgroup und rmgroup erforden meist eine Signatur mit einem
festgelegten Schlüssel.
https://www.eyrie.org/~eagle/software/inn/docs/control.ctl.html
Eine schöne Lösung. Aber wie ist organisiert, dass die und nur
die "hierarchy maintainers" den Schlüssel haben, der von allen
Newsservern akzeptiert wird?
--
Gruß Werner
http://youtu.be/ByzwOBeKD-c
www.presseportal.de/blaulicht/pm/110971/3762457
Noch 1984 mussten Flüchtlinge ihre Toiletten selbst reinigen!
Peter J. Holzer
2018-01-07 14:44:12 UTC
Permalink
Post by Werner Holtfreter
Post by Nomen Nescio
newgroup und rmgroup erforden meist eine Signatur mit einem
festgelegten Schlüssel.
https://www.eyrie.org/~eagle/software/inn/docs/control.ctl.html
Eine schöne Lösung. Aber wie ist organisiert, dass die und nur
die "hierarchy maintainers" den Schlüssel haben, der von allen
Newsservern akzeptiert wird?
Der Schlüssel wurde seit 1996 nicht mehr geändert. Den dürfte jeder
haben, der in diesem 20+ Jahren zu den Hierarchy Maintainern gehört hat
(es gibt Verfahren, wo n Leute gemeinsam einen Schlüssel nützen können,
aber n-1 Leute nicht; aber so ein Aufwand wird für dana wohl eher nicht
betrieben worden sein - OTOH, bei einigen der Leute, die da beteiligt
waren, kann ich mir durchaus vorstellen, dass die sowas umgesetzt haben).
Ich nehme an, dass ihn von diesen eher keiner den Schlüssel an
Unberechtigte weitergegeben hat. Da der Schlüssel nur 1024 Bit hat,
dürfte er heute allerdings mit überschaubarem Aufwand zu knacken sein.

hp
--
_ | Peter J. Holzer | Fluch der elektronischen Textverarbeitung:
|_|_) | | Man feilt solange an seinen Text um, bis
| | | ***@hjp.at | die Satzbestandteile des Satzes nicht mehr
__/ | http://www.hjp.at/ | zusammenpaßt. -- Ralph Babel
Werner Holtfreter
2018-01-07 16:14:47 UTC
Permalink
Post by Peter J. Holzer
Der Schlüssel wurde seit 1996 nicht mehr geändert. Den dürfte
jeder haben, der in diesem 20+ Jahren zu den Hierarchy Maintainern
gehört hat
Nach welchem Verfahren könnte der geändert werden?

Ist das ein asymmetrischer Schlüssel, d.h. bleiben die (einst
zahlreichen) Newserver-Betreiber außen vor?
--
Gruß Werner
http://youtu.be/ByzwOBeKD-c
www.presseportal.de/blaulicht/pm/110971/3762457
Noch 1984 mussten Flüchtlinge ihre Toiletten selbst reinigen!
Peter J. Holzer
2018-01-07 16:40:08 UTC
Permalink
Post by Werner Holtfreter
Post by Peter J. Holzer
Der Schlüssel wurde seit 1996 nicht mehr geändert. Den dürfte
jeder haben, der in diesem 20+ Jahren zu den Hierarchy Maintainern
gehört hat
Nach welchem Verfahren könnte der geändert werden?
Die DANA-Administration müsste ein neues Schlüsselpaar erzeugen und den
Public Key verteilen.
Post by Werner Holtfreter
Ist das ein asymmetrischer Schlüssel, d.h. bleiben die (einst
zahlreichen) Newserver-Betreiber außen vor?
Es ist natürlich ein asymmetrischer Schlüssel (wie sollte das mit einem
symmetrischen Schlüssel gehen?) und genau aus diesem Grund bleiben die
Newserver-Betreiber *nicht* außen vor. Key-Id und Fingerprint werden
monatlich in de.admin.news.announce gepostet, Jeder Newserver-Betreiber
kann den Public Key also installieren und so die Echtheit der
Steuernachrichten überprüfen (lassen).

Ich nehme allerdings an, dass die Befürchtung, dass etliche Newserver-
Betreiber das nicht tun würden, die DANA-Administration davon abgehalten
hat, den Schlüssel zu ändern.

hp
--
_ | Peter J. Holzer | Fluch der elektronischen Textverarbeitung:
|_|_) | | Man feilt solange an seinen Text um, bis
| | | ***@hjp.at | die Satzbestandteile des Satzes nicht mehr
__/ | http://www.hjp.at/ | zusammenpaßt. -- Ralph Babel
Michael Bäuerle
2018-01-07 16:56:23 UTC
Permalink
Post by Peter J. Holzer
Post by Werner Holtfreter
Post by Peter J. Holzer
Der Schlüssel wurde seit 1996 nicht mehr geändert. Den dürfte
jeder haben, der in diesem 20+ Jahren zu den Hierarchy Maintainern
gehört hat
Nach welchem Verfahren könnte der geändert werden?
Die DANA-Administration müsste ein neues Schlüsselpaar erzeugen und den
Public Key verteilen.
Post by Werner Holtfreter
Ist das ein asymmetrischer Schlüssel, d.h. bleiben die (einst
zahlreichen) Newserver-Betreiber außen vor?
Es ist natürlich ein asymmetrischer Schlüssel (wie sollte das mit einem
symmetrischen Schlüssel gehen?) und genau aus diesem Grund bleiben die
Newserver-Betreiber *nicht* außen vor. Key-Id und Fingerprint werden
monatlich in de.admin.news.announce gepostet, Jeder Newserver-Betreiber
kann den Public Key also installieren und so die Echtheit der
Steuernachrichten überprüfen (lassen).
Ich nehme allerdings an, dass die Befürchtung, dass etliche Newserver-
Betreiber das nicht tun würden, die DANA-Administration davon abgehalten
hat, den Schlüssel zu ändern.
Oder das Problem, dass alte Versionen von PGP mit aktuellen Crypto-
Algorithmen nicht umgehen können - man hätte vermutlich nicht nur die
Länge des Schlüssels erhöht, sondern alles auf einen zeitgemäßen Stand
gebracht.
Peter J. Holzer
2018-01-07 17:00:33 UTC
Permalink
Post by Michael Bäuerle
Post by Peter J. Holzer
Ich nehme allerdings an, dass die Befürchtung, dass etliche Newserver-
Betreiber das nicht tun würden, die DANA-Administration davon abgehalten
hat, den Schlüssel zu ändern.
Oder das Problem, dass alte Versionen von PGP mit aktuellen Crypto-
Algorithmen nicht umgehen können - man hätte vermutlich nicht nur die
Länge des Schlüssels erhöht, sondern alles auf einen zeitgemäßen Stand
gebracht.
Das auch (und umgekehrt: Aktuelle Versionen von GPG können nicht mehr
mit PGP2-Schlüsseln umgehen).

hp
--
_ | Peter J. Holzer | Fluch der elektronischen Textverarbeitung:
|_|_) | | Man feilt solange an seinen Text um, bis
| | | ***@hjp.at | die Satzbestandteile des Satzes nicht mehr
__/ | http://www.hjp.at/ | zusammenpaßt. -- Ralph Babel
Thomas Hochstein
2018-01-07 18:23:14 UTC
Permalink
[X-Post, Fup2 de.admin.news.misc]
Post by Peter J. Holzer
Post by Michael Bäuerle
Oder das Problem, dass alte Versionen von PGP mit aktuellen Crypto-
Algorithmen nicht umgehen können - man hätte vermutlich nicht nur die
Länge des Schlüssels erhöht, sondern alles auf einen zeitgemäßen Stand
gebracht.
Das auch (und umgekehrt: Aktuelle Versionen von GPG können nicht mehr
mit PGP2-Schlüsseln umgehen).
Ja, auch das ist ein Problem, das möglicherweise früher oder später
einen Schlüsseltausch erforderlich machen kann.

Vor knapp zwei Jahren war das schonmal Thema in
d.c.software.newsserver, der Thread beginnt bei
<n9r9rr$3pl$***@einschein.formularfetischisten.de>, mein Beitrag, der
das Problem etwas anreißt, war
<***@landroval.ancalagon.de>.

Ich würde mich über eine technische Diskussion der Problematik sehr
freuen, gerade auch deshalb, weil ich keinen wirklich tiefen Einblick
in die hinter gpg stehende Technik habe und ebenso wenig abschätzen
kann, wie verbreitet "alte" Installationen sind, die mit neueren Keys
nicht klarkommen. Interessant wäre auch, ob es bereits eine Hierarchie
gibt, die mit einem Schlüsseltausch Erfahrung hat.

Irgendwann[tm] werden wir diese Diskussion führen müssen.

(Oder die dana-Moderation führt sie intern und macht dann das, was
dabei herauskommt - ob das ein gutes Ergebnis ist, wage ich nicht
vorherzusehen.)

Grüße,
-thh

PS: Da es bei der Diskussion nicht um die Einrichtung oder Löschung
von Gruppen pp. geht, sonden um allgemeine Fragen rund um die
Adminstration - nicht nur - von de.*, leite ich mal nach
de.admin.news.misc um. Alternativ könnte man die technischen Fragen in
de.comm.software.newsserver diskutieren, aber es scheint mir nicht nur
um die bloße Technik zu gehen.
Thomas Hochstein
2018-01-07 18:23:14 UTC
Permalink
[X-Post, Fup2 de.admin.news.misc]
Post by Peter J. Holzer
Die DANA-Administration müsste ein neues Schlüsselpaar erzeugen
Das ist einfach ...
Post by Peter J. Holzer
und den Public Key verteilen.
... und das wäre theoretisch (!) auch einfach. Man müßte ihn im
Default-control.ctl unterbringen und an passender Stelle, d.h. in
news.admin.hierarchies, d.a.n.a und dana.de, auf den Tausch hinweisen.

In der Praxis steht allerdings zu befürchten, dass eine erhebliche
Zahl von Newsservern schlicht im Autopilot läuft, weil irgendjemand
die mal eingerichtet hat, aber sie niemand mehr pflegt. Vom Rest wird
ein ganz erheblicher Teil Änderungen dieser Art nicht von sich aus
mitbekommen. Man müsste also in einer konzertierten Aktion die
Newsserverbetreiber einzeln kontaktieren.

Nicht nur, dass das aufwändig wäre; ich würde auch befürchten, dass
die Reaktion auf "wir müssten etwas am Newsserver ändern" wäre, zu
hinterfragen, warum man so etwas überhaupt noch betreibt, und statt
einer Änderung lieber den Betrieb einzustellen.

Einen prophylaktischen Schlüsseltausch halte ich daher für keine
brauchbare Vorgehensweise. Im Falle der Fälle wird man eben schauen
müssen, wie man damit umgeht.
Post by Peter J. Holzer
Ich nehme allerdings an, dass die Befürchtung, dass etliche Newserver-
Betreiber das nicht tun würden, die DANA-Administration davon abgehalten
hat, den Schlüssel zu ändern.
So ist es.

(Man könnte das Für und Wider in de.admin.news.misc oder
d.c.s.newsserver diskutieren, aber ich zweifele, ob es da viel Input
gäbe.)

Grüße,
-thh

PS: Da es bei der Diskussion nicht um die Einrichtung oder Löschung
von Gruppen pp. geht, sonden um allgemeine Fragen rund um die
Adminstration - nicht nur - von de.*, leite ich mal nach
de.admin.news.misc um. Alternativ könnte man die technischen Fragen in
de.comm.software.newsserver diskutieren, aber es scheint mir nicht nur
um die bloße Technik zu gehen.
Werner Holtfreter
2018-01-07 19:57:13 UTC
Permalink
Post by Peter J. Holzer
Post by Werner Holtfreter
Ist das ein asymmetrischer Schlüssel, d.h. bleiben die (einst
zahlreichen) Newserver-Betreiber außen vor?
Es ist natürlich ein asymmetrischer Schlüssel (wie sollte das mit
einem symmetrischen Schlüssel gehen?) und genau aus diesem Grund
bleiben die Newserver-Betreiber *nicht* außen vor. Key-Id und
Fingerprint werden monatlich in de.admin.news.announce gepostet,
Jeder Newserver-Betreiber kann den Public Key also installieren
und so die Echtheit der Steuernachrichten überprüfen (lassen).
Mit außen vor bleiben meinte ich, dass die Newsserver-Betreiber
keine Möglichkeit haben, solche Steuernachrichten zu versenden.
Diese Frage ist nun beantwortet, nachdem es sich um einen
asymmetrischer Schlüssel handelt.
--
Gruß Werner
http://youtu.be/ByzwOBeKD-c
www.presseportal.de/blaulicht/pm/110971/3762457
Noch 1984 mussten Flüchtlinge ihre Toiletten selbst reinigen!
Marc Haber
2018-01-07 21:12:15 UTC
Permalink
Post by Werner Holtfreter
Mit außen vor bleiben meinte ich, dass die Newsserver-Betreiber
keine Möglichkeit haben, solche Steuernachrichten zu versenden.
Natürlich kann jeder Betreiber Änderungen an seinem eigenen Newsserver
vornehmen, ohne irgendwelche Steuernachrichten signieren zu müssen.
--
-------------------------------------- !! No courtesy copies, please !! -----
Marc Haber | " Questions are the | Mailadresse im Header
Mannheim, Germany | Beginning of Wisdom " |
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834
Loading...