Neuer Draft für Cancel-Lock

[Michael Baeuerle]

Damit das nach 20 Jahren vielleicht doch endlich eine offizielle Norm
wird:
<https://tools.ietf.org/html/draft-baeuerle-netnews-cancel-lock-00>

Siehe hierzu auch in <news:news.software.nntp>:
<news:***@WStation5.stz-e.de>

Deutsche Kommentare in dieser Gruppe sind natürlich auch willkommen.


[Xpost und Fup2 nach de.comm.software.newsreader]

[Holger Marzen]

["Followup-To:" nach de.comm.software.newsserver gesetzt.]

Post by Michael Baeuerle
Damit das nach 20 Jahren vielleicht doch endlich eine offizielle Norm
<https://tools.ietf.org/html/draft-baeuerle-netnews-cancel-lock-00>

Solange keiner was ändert und das existierende, funktionierende
Verfahren kaputtmacht, soll’s mir recht sein.

Bei https können wir ja schon sehen, wie es durch eigenmächtige, harte
Abschaltung (in Browsern, in Schnüffelproxys a la Bluecoat) einzelner
Algorithmen („die sind aber unsicher!11elf“) unbrauchbar gemacht wird,
weil man auf einmal nicht mehr auf manche Seiten zugreifen kann.

[Michael Bäuerle]

Post by Holger Marzen

Post by Michael Baeuerle
Damit das nach 20 Jahren vielleicht doch endlich eine offizielle Norm
<https://tools.ietf.org/html/draft-baeuerle-netnews-cancel-lock-00>

Solange keiner was ändert und das existierende, funktionierende
Verfahren kaputtmacht, soll’s mir recht sein.

An der Funktionsweise hat sich nichts geändert. In eine neue Norm (die
vielleicht wieder 20 Jahre lang keiner mehr anfasst) möchte ich aber
nicht mehr SHA1 als "mandatory algorithm" für neue Implementierungen
reinschreiben - wenn da schon hinten und vorne der Putz abbröckelt.

Post by Holger Marzen
Bei https können wir ja schon sehen, wie es durch eigenmächtige, harte
Abschaltung (in Browsern, in Schnüffelproxys a la Bluecoat) einzelner
Algorithmen („die sind aber unsicher!11elf“) unbrauchbar gemacht wird,
weil man auf einmal nicht mehr auf manche Seiten zugreifen kann.

In Kapitel 6 habe ich zu MD5 und SHA1 geschrieben:
|
| [...] The following values for <scheme> are now
| deprecated and SHOULD not be generated anymore. Serving agents
| SHOULD still accept them for a transition period as long as the
| corresponding hash function is not considered unsafe.

Damit soll existierende Software weiter funktionieren, bis die heute
gängigen Algorithmen nicht mehr tragbar sind.

[Holger Marzen]

Post by Michael Bäuerle
|
| [...] The following values for <scheme> are now
| deprecated and SHOULD not be generated anymore. Serving agents
| SHOULD still accept them for a transition period as long as the
| corresponding hash function is not considered unsafe.
Damit soll existierende Software weiter funktionieren, bis die heute
gängigen Algorithmen nicht mehr tragbar sind.

Genau das habe ich befürchtet. Da hab ich doch schon wieder „die Scheiße
im Dunkeln gerochen“. Denn „nicht mehr tragbar“ ist ein dehnbarer
Begriff und kann schon morgen sein.

Post by Michael Bäuerle
| [...] The following values for <scheme> are now
| deprecated and SHOULD not be generated anymore. Serving agents

MUST accept them to retain compatibility.

Wir reden vom Usenet, nicht vom Homebanking. Da werden keine süßen,
kleinen Kätzchen sterben, wenn jemand ein paar Tausend kWh verbrät, um
einen meiner Artikel zu canceln oder zu superseden. Es kann eh jeder
unter meinem Namen posten.

[Michael Bäuerle]

Post by Holger Marzen

Post by Michael Bäuerle
|
| [...] The following values for <scheme> are now
| deprecated and SHOULD not be generated anymore. Serving agents
| SHOULD still accept them for a transition period as long as the
| corresponding hash function is not considered unsafe.
Damit soll existierende Software weiter funktionieren, bis die heute
gängigen Algorithmen nicht mehr tragbar sind.

Genau das habe ich befürchtet. Da hab ich doch schon wieder „die Scheiße
im Dunkeln gerochen“. Denn „nicht mehr tragbar“ ist ein dehnbarer
Begriff und kann schon morgen sein.

Sicher nicht. Bevor nicht eine nennenswerte Zahl von Servern eine
Alternative unterstützt, ist eine Umstellung doch gar nicht möglich. Da
werden mindestens einige Jahre vergehen, so langsam wie sich das USENET
weiterentwickelt. Und solange SHA1 gut genug ist muss das auch niemand
abschalten.

[Holger Marzen]

Post by Michael Bäuerle

Post by Holger Marzen

Post by Michael Bäuerle
|
| [...] The following values for <scheme> are now
| deprecated and SHOULD not be generated anymore. Serving agents
| SHOULD still accept them for a transition period as long as the
| corresponding hash function is not considered unsafe.
Damit soll existierende Software weiter funktionieren, bis die heute
gängigen Algorithmen nicht mehr tragbar sind.

Genau das habe ich befürchtet. Da hab ich doch schon wieder „die Scheiße
im Dunkeln gerochen“. Denn „nicht mehr tragbar“ ist ein dehnbarer
Begriff und kann schon morgen sein.

Sicher nicht. Bevor nicht eine nennenswerte Zahl von Servern eine
Alternative unterstützt, ist eine Umstellung doch gar nicht möglich. Da
werden mindestens einige Jahre vergehen, so langsam wie sich das USENET
weiterentwickelt. Und solange SHA1 gut genug ist muss das auch niemand
abschalten.

Ich hätte bei meinem Vorschlag

Post by Michael Bäuerle

Post by Holger Marzen

Post by Michael Bäuerle
| MUST still accept them to retain backwards compatibility.

ein besseres Gefühl. Wenn der Nutzer seinen alten Client unbedingt
weiternutzen will, tut das nicht weh. Man kann doch froh um jeden
Usenet-Nutzer sein.

[Stefan+ (Stefan Froehlich)]

Post by Holger Marzen

Post by Michael Bäuerle
| [...] The following values for <scheme> are now
| deprecated and SHOULD not be generated anymore. Serving agents
| SHOULD still accept them for a transition period as long as the
| corresponding hash function is not considered unsafe.
Damit soll existierende Software weiter funktionieren, bis die heute
gängigen Algorithmen nicht mehr tragbar sind.

[...] solange SHA1 gut genug ist muss das auch niemand abschalten.

Ich hätte bei meinem Vorschlag

Post by Michael Bäuerle
| MUST still accept them to retain backwards compatibility.

ein besseres Gefühl. Wenn der Nutzer seinen alten Client unbedingt
weiternutzen will, tut das nicht weh. Man kann doch froh um jeden
Usenet-Nutzer sein.

Ich sehe das auch so - wenn jemand SHA1 verwendet, dann gräbt er
sich damit auch in ferner Zukunft ja nur selbst eine Grube. Die
prinzipielle Unterstützung von md5 bzw. sha1 wird softwareseitig
ja eher nicht verschwinden, so dass das serverseitig kein Problem
darstellen sollte.

Servus,
Stefan

[Michael Bäuerle]

Post by Stefan+ (Stefan Froehlich)

Post by Holger Marzen

Post by Michael Bäuerle
| [...] The following values for <scheme> are now
| deprecated and SHOULD not be generated anymore. Serving agents
| SHOULD still accept them for a transition period as long as the
| corresponding hash function is not considered unsafe.
Damit soll existierende Software weiter funktionieren, bis die heute
gängigen Algorithmen nicht mehr tragbar sind.

[...] solange SHA1 gut genug ist muss das auch niemand abschalten.

Ich hätte bei meinem Vorschlag

Post by Michael Bäuerle
| MUST still accept them to retain backwards compatibility.

ein besseres Gefühl. Wenn der Nutzer seinen alten Client unbedingt
weiternutzen will, tut das nicht weh. Man kann doch froh um jeden
Usenet-Nutzer sein.

Ich sehe das auch so - wenn jemand SHA1 verwendet, dann gräbt er
sich damit auch in ferner Zukunft ja nur selbst eine Grube. Die
prinzipielle Unterstützung von md5 bzw. sha1 wird softwareseitig
ja eher nicht verschwinden, so dass das serverseitig kein Problem
darstellen sollte.

Wenn diese Lösung auch sonst den meisten Zuspruch finden sollte, dann
werde ich den obigen Absatz entsprechend ändern.

Ursprünglich hatte ich schonmal MUST drinstehen gehabt, das dann aber
wieder abgeschwächt (gerade um dem Benutzer der Software die Ent-
scheidung zu überlassen).

[Emil Schuster]

Post by Stefan+ (Stefan Froehlich)

Post by Holger Marzen
ein besseres Gefühl. Wenn der Nutzer seinen alten Client unbedingt
weiternutzen will, tut das nicht weh. Man kann doch froh um jeden
Usenet-Nutzer sein.

Ich sehe das auch so - wenn jemand SHA1 verwendet, dann gräbt er
sich damit auch in ferner Zukunft ja nur selbst eine Grube. Die
prinzipielle Unterstützung von md5 bzw. sha1 wird softwareseitig
ja eher nicht verschwinden, so dass das serverseitig kein Problem
darstellen sollte.

Ich sehe serverseitig eher das Problem, dass es dauern wird, bis überall
SHA-256 implementiert ist. Mich jedenfalls hat es schon genervt, als ich mal
sha durch sha1 ersetzen musste, weil Debian mir ein Update untergejubelt
hatte, das ich erst bemerkte, als betreffs Cancel nichts mehr funktionierte.

Also bitte in allen Server-Newgroups mehrfach deutlich darauf hinweisen,
wenn die Geschichte offiziell wird. Ansonsten sehe ich das wie Holger und
Stefan: md5 und sha1 sollten auf jeden Fall bleiben.

[Thomas Hochstein]

Post by Holger Marzen
Ich hätte bei meinem Vorschlag

Post by Michael Bäuerle
| MUST still accept them to retain backwards compatibility.

ein besseres Gefühl. Wenn der Nutzer seinen alten Client unbedingt
weiternutzen will, tut das nicht weh. Man kann doch froh um jeden
Usenet-Nutzer sein.

Backwards compatibilty auf Jahr(zehnt)e als zwingend vorzuschreiben
ist IMNSHO sicherlich der falsche Weg.

[Stefan+ (Stefan Froehlich)]

Post by Thomas Hochstein

Post by Holger Marzen
Ich hätte bei meinem Vorschlag

Post by Michael Bäuerle
| MUST still accept them to retain backwards compatibility.

ein besseres Gefühl. Wenn der Nutzer seinen alten Client unbedingt
weiternutzen will, tut das nicht weh. Man kann doch froh um jeden
Usenet-Nutzer sein.

Backwards compatibilty auf Jahr(zehnt)e als zwingend vorzuschreiben
ist IMNSHO sicherlich der falsche Weg.

Wen stört's im konkreten Fall? Implementieren wird sich das in alle
Ewigkeit ohne jeden Zusatzaufwand lassen. Und wenn ich ein mäßig sicheres
Verfahren für meine Cancel-Locks verwende, kann damit im schlimmsten Fall
mir selbst geschadet werden.

Servus,
Stefan

[Michael Bäuerle]

Post by Thomas Hochstein

Post by Holger Marzen
Ich hätte bei meinem Vorschlag

Post by Michael Bäuerle
| MUST still accept them to retain backwards compatibility.

ein besseres Gefühl. Wenn der Nutzer seinen alten Client unbedingt
weiternutzen will, tut das nicht weh. Man kann doch froh um jeden
Usenet-Nutzer sein.

Backwards compatibilty auf Jahr(zehnt)e als zwingend vorzuschreiben
ist IMNSHO sicherlich der falsche Weg.

Ack, das war der Grund warum ich es so formuliert hatte.
Und selbst wenn man es erzwingen wollte, es kann sich prinzipiell ja
jeder darüber hinwegsetzen, wenn er es nicht einsieht. Das Ziel sollte
IMHO sein, die Bedeutung der Abwärtkompatibilität deutlich herauszu-
stellen (und dass SHA1 - heute und für diesen Zweck - noch nicht kaputt
ist).

Nach folgendem Satz:
|
| [...] Serving agents
| SHOULD still accept them for a transition period as long as the
| corresponding hash function is not considered unsafe.

könnte man beispielsweise noch deutlicher formulieren, dass die Abwärts-
kompatibilität wichtig ist und nicht ohne Grund vorschnell entfernt
werden sollte. Zum Beispiel mit folgender Ergänzung:

It is important for backward compatibility that there should be
real problems that justify to not accept them anymore!

Das SHOULD bedeutet ja an sich schon "nicht ohne Grund was anderes,
und nicht ohne die Konsequenzen zu bedenken":
<https://tools.ietf.org/html/rfc2119#section-3>

[Holger Marzen]

Post by Michael Bäuerle

Post by Thomas Hochstein

Post by Holger Marzen
Ich hätte bei meinem Vorschlag

Post by Michael Bäuerle
| MUST still accept them to retain backwards compatibility.

ein besseres Gefühl. Wenn der Nutzer seinen alten Client unbedingt
weiternutzen will, tut das nicht weh. Man kann doch froh um jeden
Usenet-Nutzer sein.

Backwards compatibilty auf Jahr(zehnt)e als zwingend vorzuschreiben
ist IMNSHO sicherlich der falsche Weg.

Ack, das war der Grund warum ich es so formuliert hatte.
Und selbst wenn man es erzwingen wollte, es kann sich prinzipiell ja
jeder darüber hinwegsetzen, wenn er es nicht einsieht. Das Ziel sollte
IMHO sein, die Bedeutung der Abwärtkompatibilität deutlich herauszu-
stellen (und dass SHA1 - heute und für diesen Zweck - noch nicht kaputt
ist).
|
| [...] Serving agents
| SHOULD still accept them for a transition period as long as the
| corresponding hash function is not considered unsafe.
könnte man beispielsweise noch deutlicher formulieren, dass die Abwärts-
kompatibilität wichtig ist und nicht ohne Grund vorschnell entfernt

Warum jetzt schon einschränken? Wenn es für die Menschheit
überlebenswichtig ist, alte Clients auszusperren, kann man den Draft
ändern.

Stabilität und Interoperabilität sind hohe Güter. Man sollte es nicht
sinnloser Schnelllebigkeit opfern. Nutzer wollen nicht in erster Linie
Veränderung, sondern Systeme und Tools, die nicht einfach aufhören zu
funktionieren, nur weil ein paar Leute eine vermeintlich geniale Idee
hatten.

Es ist schon schlimm genug, welche Blüten die Bevormundung bei https
treibt. Ich kann aus der Firma heraus Seiten von Behörden nicht
erreichen, weil sie noch TLS 1.0 verwenden. Ich kann zwar http-Seiten
aufrufen, nicht aber https mit selbstsignierten Zertifikaten, "der
Sicherheit wegen" (obwohl sie vom Proxy per MiTM aufgebrochen werden).

Wenn ich durch mein Gemaule auch nur ein klein wenig dazu beitragen
kann, solche Entgleisungen von Superexperten zu verzögern, mache ich das
mit Begeisterung.

Geht einfach davon aus: Was unter dem Vorwand von Security kaputtgemacht
werden kann, wird auch kaputtgemacht.

[Peter Faust]

Post by Holger Marzen

Post by Michael Bäuerle

Post by Thomas Hochstein

Post by Holger Marzen
Ich hätte bei meinem Vorschlag

Post by Michael Bäuerle
| MUST still accept them to retain backwards compatibility.

ein besseres Gefühl. Wenn der Nutzer seinen alten Client unbedingt
weiternutzen will, tut das nicht weh. Man kann doch froh um jeden
Usenet-Nutzer sein.

Backwards compatibilty auf Jahr(zehnt)e als zwingend vorzuschreiben
ist IMNSHO sicherlich der falsche Weg.

Ack, das war der Grund warum ich es so formuliert hatte.
Und selbst wenn man es erzwingen wollte, es kann sich prinzipiell ja
jeder darüber hinwegsetzen, wenn er es nicht einsieht. Das Ziel sollte
IMHO sein, die Bedeutung der Abwärtkompatibilität deutlich herauszu-
stellen (und dass SHA1 - heute und für diesen Zweck - noch nicht kaputt
ist).
|
| [...] Serving agents
| SHOULD still accept them for a transition period as long as the
| corresponding hash function is not considered unsafe.
könnte man beispielsweise noch deutlicher formulieren, dass die Abwärts-
kompatibilität wichtig ist und nicht ohne Grund vorschnell entfernt

Warum jetzt schon einschränken? Wenn es für die Menschheit
überlebenswichtig ist, alte Clients auszusperren, kann man den Draft
ändern.

Alte Clients, die nur MD5 im Cancel-Lock verwenden, haben Alfred Peters
und ich gestern vergeblich im de.Usenet gesucht.

Lediglich Testpostings mit MD5, SHA256 und SHA512 wurden in de.alt.test
im Januar 2016 gefunden:

<***@mid.individual.net>
<d64a59d2-889f-7973-24e6-***@peter.faust-stockholm.user.spray.se>
<726b89e0-2840-aa22-0e85-***@peter.faust-stockholm.user.spray.se>
(Alle aus de.test von gestern und heute.)

Post by Holger Marzen
Stabilität und Interoperabilität sind hohe Güter. Man sollte es nicht
sinnloser Schnelllebigkeit opfern. Nutzer wollen nicht in erster Linie
Veränderung, sondern Systeme und Tools, die nicht einfach aufhören zu
funktionieren, nur weil ein paar Leute eine vermeintlich geniale Idee
hatten.

Alte NUAs, die nur MD5 als Cancel-Key nutzen, finde ich keine: Gerade
eben erneut gesucht, Datenbestand de.ALL zurück bis 2000 - Nichts.

Und selbst wenn es welche geben sollte, können die problemlos dem
annehmenden Newsserver das setzen des Cancel-Lock überlassen.
Das machen fast alle modernen NUAs so; fast alle Newsserver setzen auch
einen sha1-Cancel-Lock. Oder gar keinen ...

Post by Holger Marzen
Es ist schon schlimm genug, welche Blüten die Bevormundung bei https
treibt. Ich kann aus der Firma heraus Seiten von Behörden nicht
erreichen, weil sie noch TLS 1.0 verwenden. Ich kann zwar http-Seiten
aufrufen, nicht aber https mit selbstsignierten Zertifikaten, "der
Sicherheit wegen" (obwohl sie vom Proxy per MiTM aufgebrochen werden).
Wenn ich durch mein Gemaule auch nur ein klein wenig dazu beitragen
kann, solche Entgleisungen von Superexperten zu verzögern, mache ich das
mit Begeisterung.

Das liest sich so, als ob du dich immer noch nicht bei den Betreibern
diverser, veralteter und kaputter Seiten beschwert hast. Warum nicht?

Insbesondere Behördenseiten haben eine Verpflichtung zu barrierefreiem
"Internet". Aber das weißt du ja schon ...

Post by Holger Marzen
Geht einfach davon aus: Was unter dem Vorwand von Security kaputtgemacht
werden kann, wird auch kaputtgemacht.

MD5-Cancel-Lock ist unwichtig, weil nicht genutzt. Nirgends. Also muss
da auch nichts unterstützt werden.

[Emil Schuster]

Post by Peter Faust
MD5-Cancel-Lock ist unwichtig, weil nicht genutzt. Nirgends. Also muss
da auch nichts unterstützt werden.

Den Beweis zu führen, dass es etwas nicht gibt, ist schwierig. Wem tut es
eigentlich weh, wenn es trotzdem unterstützt wird? Irgendwie erinnert mich
das an die Diskussionen zum Löschen von leeren Newsgruppen...

[Michael Bäuerle]

Post by Emil Schuster

Post by Peter Faust
MD5-Cancel-Lock ist unwichtig, weil nicht genutzt. Nirgends. Also muss
da auch nichts unterstützt werden.

Den Beweis zu führen, dass es etwas nicht gibt, ist schwierig. Wem tut es
eigentlich weh, wenn es trotzdem unterstützt wird?

Ich erinnere daran, dass MD5 für diesen Zweck noch nie spezifiziert war
(auch in den Drafts aus dem letzten Jahrtausend nicht). Wenn es bisher
jemand verwendet hat, dann eigenmächtig - und das kann jeder ja auch
weiterhin tun - nach eigenem Ermessen.

Ich hatte MD5 in der neuen Liste nur aufgeführt, um einer potentiellen,
relevanten "real world"-Verbreitung Rechnung zu tragen - diese gibt es
gemäß den Statistikdaten aber nicht.
Ich denke es macht daher Sinn MD5 wieder rauszunehmen und sich auf SHA1
zu konzentrieren. Das wird heute verwendet und muss erstmal weiterhin
funktionieren.

[Emil Schuster]

Post by Michael Bäuerle
Ich erinnere daran, dass MD5 für diesen Zweck noch nie spezifiziert war
(auch in den Drafts aus dem letzten Jahrtausend nicht). Wenn es bisher
jemand verwendet hat, dann eigenmächtig - und das kann jeder ja auch
weiterhin tun - nach eigenem Ermessen.

Ok, das wusste ich nicht, dann ist das natürlich etwas ganz anderes. Ich
werde es hier rausschmeissen und solche Cancels nicht mehr ausführen, falls
sie noch vorkommen. Wäre nicht schlecht gewesen, wenn du das auch für
unwissende wie mich gleich in deiner Eingangsmail erwähnt hättest ;.)

@Peter Faust: Einen entspr. Test in de.test würde ich begrüßen, du bist doch
der große Testcrack :-)

[Michael Bäuerle]

Post by Emil Schuster

Post by Michael Bäuerle
Ich erinnere daran, dass MD5 für diesen Zweck noch nie spezifiziert war
(auch in den Drafts aus dem letzten Jahrtausend nicht). Wenn es bisher
jemand verwendet hat, dann eigenmächtig - und das kann jeder ja auch
weiterhin tun - nach eigenem Ermessen.

Ok, das wusste ich nicht, dann ist das natürlich etwas ganz anderes. Ich
werde es hier rausschmeissen und solche Cancels nicht mehr ausführen, falls
sie noch vorkommen. Wäre nicht schlecht gewesen, wenn du das auch für
unwissende wie mich gleich in deiner Eingangsmail erwähnt hättest ;.)

Sorry, ich dachte die alte Version ist bekannt.

Hier ist ein geänderter Entwurf:
<https://tools.ietf.org/html/draft-baeuerle-netnews-cancel-lock-01>
Links oben bei "Versions" kann man auch die alte Version von Simon
Lyall anklicken.

In Kapitel 6 habe ich nun MD5 entfernt und einen Absatz hinzugefügt,
dass SHA1 nicht grundlos entfernt (und auch bei potentiellen neuen
Implementierungen nicht weggelassen) werden soll, um die Abwärts-
kompatibilität zu erhalten.

@Holger:
Das sollte wirklich ausreichend sein. Es handelt sich um eine Norm,
nicht um ein Gesetz. Wer es möchte kann das immer falsch implementieren.
Wie es vorgesehen ist sollte nun aber sowohl formal, als auch von der
Beschreibung im Text her eindeutig sein.

[Peter Faust]

Post by Emil Schuster

Post by Michael Bäuerle
Ich erinnere daran, dass MD5 für diesen Zweck noch nie spezifiziert war
(auch in den Drafts aus dem letzten Jahrtausend nicht). Wenn es bisher
jemand verwendet hat, dann eigenmächtig - und das kann jeder ja auch
weiterhin tun - nach eigenem Ermessen.

Ok, das wusste ich nicht, dann ist das natürlich etwas ganz anderes. Ich
werde es hier rausschmeissen und solche Cancels nicht mehr ausführen, falls
sie noch vorkommen. Wäre nicht schlecht gewesen, wenn du das auch für
unwissende wie mich gleich in deiner Eingangsmail erwähnt hättest ;.)
@Peter Faust: Einen entspr. Test in de.test würde ich begrüßen, du bist doch
der große Testcrack :-)

Ohje, so groß bin ich doch gar nicht im testen. Es ist halt nur das, was
ich sehr gerne mache: Programme ausreizen, bis zum Äüßersten. 0;->
War früher beim zocken auch nicht anders: Hacken bis der PunkBuster mal
anfängt zu meckern oder rauswirft.

Das erinnert gerade daran, ich müsste nochmal news.freedyn.net testen,
ob die immer noch keinen Cancel-Lock haben - dann könnte man darüber ja
prima einen Cancel-Lock mit MD5-Key schicken und ein wenig canceln.

Egal, später. Jetzt ist noch etwas arbeiten angesagt ...

[Peter Faust]

Post by Michael Bäuerle

Post by Emil Schuster

Post by Peter Faust
MD5-Cancel-Lock ist unwichtig, weil nicht genutzt. Nirgends. Also muss
da auch nichts unterstützt werden.

Den Beweis zu führen, dass es etwas nicht gibt, ist schwierig. Wem tut es
eigentlich weh, wenn es trotzdem unterstützt wird?

Ich erinnere daran, dass MD5 für diesen Zweck noch nie spezifiziert war
(auch in den Drafts aus dem letzten Jahrtausend nicht). Wenn es bisher
jemand verwendet hat, dann eigenmächtig - und das kann jeder ja auch
weiterhin tun - nach eigenem Ermessen.
Ich hatte MD5 in der neuen Liste nur aufgeführt, um einer potentiellen,
relevanten "real world"-Verbreitung Rechnung zu tragen - diese gibt es
gemäß den Statistikdaten aber nicht.
Ich denke es macht daher Sinn MD5 wieder rauszunehmen und sich auf SHA1
zu konzentrieren. Das wird heute verwendet und muss erstmal weiterhin
funktionieren.

So (MD5 raus, SHA1 weiter unterstützen) hatte ich das auch verstanden.
Die Unterscheidung SHA0, SHA1, SHA2, SHA3 ist nicht einfach.

Ein verstärkter Hinweis bzw. eine dringende Empfehlung zu mindestens
SHA2 (SHA-224, SHA-256, SHA-384 und SHA-512) im Cancel-Lock wäre mMn
ein Anfang.

Wie schon geschrieben: Alte Software, die das einfach noch nicht kann,
muss dann eben dem Newsserver die Generierung überlassen.

[Michael Bäuerle]

Post by Peter Faust
[...]
Ein verstärkter Hinweis bzw. eine dringende Empfehlung zu mindestens
SHA2 (SHA-224, SHA-256, SHA-384 und SHA-512) im Cancel-Lock wäre mMn
ein Anfang.

So steht es bereits drin: SHA2-256 als "mandatory" für die Zukunfts-
sicherheit und SHA1 für die Kompatibilität (soll solange akzeptiert
werden, wie das sicherheitstechnisch keine Probleme macht).

[Michael Bäuerle]

Post by Peter Faust

Post by Holger Marzen
[...]
Geht einfach davon aus: Was unter dem Vorwand von Security kaputtgemacht
werden kann, wird auch kaputtgemacht.

MD5-Cancel-Lock ist unwichtig, weil nicht genutzt. Nirgends. Also muss
da auch nichts unterstützt werden.

Es ging Holger aber auch darum, dass in Zukunft SHA1 nicht unnötiger-
weise zu schnell nicht mehr akzeptiert wird (zu Gunsten von SHA2).
Die Sorge ist prinzipiell schon berechtigt und die Formulierung sollte
klarstellen, dass das nicht sinnvoll und nicht beabsichtigt ist.

In der Praxis wird es aber mit hoher Wahrscheinlichkeit wohl eher anders
herum laufen: Andere für USENET relevante RFCs haben üblicherweise
5-10 Jahre gebraucht um überhaupt breitere Anwendung zu finden. Dass da
nun Morgen jeder auf SHA2 umstellt und den Support für SHA1 entfernt
halte ich für weniger wahrscheinlich als vom Blitz getroffen zu werden.

[Thomas Hochstein]

Post by Holger Marzen
Warum jetzt schon einschränken?

Jetzt *schon*?

Post by Holger Marzen
Wenn es für die Menschheit
überlebenswichtig ist, alte Clients auszusperren, kann man den Draft
ändern.

Das Usenet krankt, ganz vorsichtig ausgedrückt, eher nicht daran, dass
sich jede Woche, jeden Monat, jedes Jahr oder auch nur jedes Jahrzehnt
etwas ändert. Genau genommen ist die fehlende und stagnierende
technische Weiterentwicklung eines der Probleme.

Daher: wenn man etwas tut, sollte man es direkt richtig machen - und
ein Standard, der für die nächsten 10-20 Jahre zwingend (!) vorgibt,
jetzt bereits nicht mehr aktuelle Technik zu unterstützen, führt
entweder zu weiterem Stillstand oder - wahrscheinlicher - dazu, dass
die Implemtationen den Standard ignorieren.

Post by Holger Marzen
Stabilität und Interoperabilität sind hohe Güter. Man sollte es nicht
sinnloser Schnelllebigkeit opfern.

"Schnelllebigkeit" ist nicht direkt der Begriff, den ich mit dem
Usenet verbinden würde.

Post by Holger Marzen
Es ist schon schlimm genug, welche Blüten die Bevormundung bei https
treibt. Ich kann aus der Firma heraus Seiten von Behörden nicht
erreichen, weil sie noch TLS 1.0 verwenden.

Die richtige Reaktion darauf wäre IMNSHO, dass "die Behörden" in die
Gänge kommen, nicht aber, dass man TLS 1.0 für Jahrzehnte als
"zwingend zu unterstützen" vorschreibt. Dann ändert sich nämlich
nichts.

Post by Holger Marzen
Ich kann zwar http-Seiten
aufrufen, nicht aber https mit selbstsignierten Zertifikaten, "der
Sicherheit wegen" (obwohl sie vom Proxy per MiTM aufgebrochen werden).

Das liegt aber, AFAIS, an der lokalen Konfiguration, nicht am Standard
oder der Implementation.

-thh

[Michael Bäuerle]

Post by Holger Marzen
[...]
Bei https können wir ja schon sehen, wie es durch eigenmächtige, harte
Abschaltung (in Browsern, in Schnüffelproxys a la Bluecoat) einzelner
Algorithmen („die sind aber unsicher!11elf“) unbrauchbar gemacht wird,
weil man auf einmal nicht mehr auf manche Seiten zugreifen kann.

BTW: Zum Thema TLS hat Julien gerade folgendes in Arbeit:
<https://tools.ietf.org/html/draft-elie-nntp-tls-recommendations-05>

Das wird ein Update für RFC4642 wo u.a. drinsteht:
|
| NNTP client and server implementations MUST implement the
| TLS_RSA_WITH_RC4_128_MD5 [TLS] cipher suite [...]

Das fliegt dann tatsächlich raus, ist aber mittlerweile auch offiziell
BCP:
<https://tools.ietf.org/html/rfc7525#section-4.1>
|
| Implementations MUST NOT negotiate RC4 cipher suites.

(also nicht die Meinung „unsicher!11elf“ einzelner Personen)