Diskussion:DNS-based Authentication of Named Entities

Die Löschung der Seite „DNS-based Authentication of Named Entities“ wurde ab dem 21. April 2014 diskutiert und abgelehnt. Für einen erneuten Löschantrag müssen gemäß den Löschregeln neue Argumente vorgebracht werden.

Tools

Ich habe eine Software zum automatischen Erneuern des Schlüsselmaterials geschrieben:

https://www.entroserv.de/de/offene-software/cryptdomainmgr

Besteht Interesse an einem kurzen Artikel bzw. Verlinkungen? (nicht signierter Beitrag von Entroserv.de (Diskussion | Beiträge) 15:49, 11. Jun. 2019 (CEST))

Verständlichkeit

M. M. n. kann man den Text ohne fachliche Vorerfahrungen nicht verstehen. Für einen Laien unverständlich, worum es hier überhaupt geht. --Icy2008 (Schreib mir!) 14:05, 9. Apr. 2014 (CEST)

Stimme Dir zu. Ich versuche, mich an der Verbesserung zu beteiligen. --Peter Ulber (Diskussion) 19:55, 11. Mai 2014 (CEST)

Vielleicht hilfreich zur besseren Strukturierung und Formulierung, ohne platt abzukupfern :-):

http://www.heise.de/newsticker/meldung/Verschluesselter-Mail-Transport-Posteo-setzt-als-erster-Provider-DANE-ein-2187144.html

AnBuKu (Diskussion) 00:24, 13. Mai 2014 (CEST)

Außerdem noch ein heise-Artikel ohne Provider-Bezug: [1]

Es wäre vielleicht für den Leser hilfreich, wenn nicht gleich der erste Abschnitt so fachspezifisch wäre. Erstmal so etwas in der Art wie: "DANE ist ein Verfahren, mit dem Datenübertragungen im Internet verschlüsselt werden können. Anders als bei bisherigen Verfahren muss der Anbieter dazu nicht erst bei einer Zertifizierungsstelle ein Sicherheitszertifikat erwerben, sondern kann selbst eins hinterlegen..." oder so ähnlich. Dann wissen die Lesenden gleich, worum es geht (Ah, Verschlüsselung, Datensicherheit), ohne mit Fachbegriffen zugeschmissen zu werden. Im Absatz über Funktionsweise etc. kann es dann ja ausführlich und auch für Laien unverständlich werden. Christian (Diskussion) 07:29, 13. Mai 2014 (CEST)

Das wäre aber eine grundsätzlich falsche Erlärung. DANE ist ein Schutz gegen Man in the Middle Attacken bei verschlüsselten Verbindungen. Also wenn sich jemand dazwischengeschaltet hat um deinen Netzwerkverkehr abzugreifen und dir dabei ein gefälschtes oder geklautes Zertifikat unterschieben will.

Das ist z.B. in folgenden Fällen hilfreich:

http://www.heise.de/security/meldung/Neuer-SSL-Gau-Falsches-Google-Zertifikat-blieb-fuenf-Wochen-unentdeckt-1333070.html
http://www.heise.de/netze/meldung/Der-Diginotar-SSL-Gau-und-seine-Folgen-1423893.html

--RipClaw2971 (Diskussion) 10:14, 13. Mai 2014 (CEST)

Ich hab mal den Begriff "Vertrauensanker" rausgenommen. Trust Anchor wird zwar so übersetzt, aber in der Fachliteratur ist, wenn der Fachbegriff überhaupt eingedeutscht wird, meist der Begriff "Vertrauensursprung" bei PKIs üblich und IMO auch verständlicher.--Mrothyr (Diskussion) 11:27, 15. Mai 2014 (CEST)

Ja, da hast Du Recht. War auch eher ein Versuch der Eindeutschung. Für mich ist es immer ein (trust) anchor. Danke für's Mitarbeiten, bin schon mal froh, dass der Löschantrag weg ist :) --Peter Ulber (Diskussion) 00:50, 16. Mai 2014 (CEST)

Zum Begriff Vertrauensanker / Vertrauensursprung siehe bitte unter Diskussion:Vertrauensanker. --Matthäus Wander 16:01, 26. Mai 2023 (CEST)

Bezüge zum Artikel Domain Name System Security Extensions

In dem Artikel Domain Name System Security Extensions gibt es einen Abschnitt "Ausblick", der ganz nach DANE klingt. Könnte jemand mit etwas mehr Ahnung das bitte bestätigen und dort einen Link auf diesen Artikel über DANE setzen? Oder gibt es noch konkurrierende Verfahren? (Übrigens behandelt die katalonische Wikipedia das Thema DANE inerhalb des DNSSEC-Artikels.) --DufterKunde (Diskussion) 14:13, 13. Mai 2014 (CEST)

Ja, betrifft zum Teil DANE. Und natürlich gab und gibt es weitere Verfahren. DANE im Kontext von DNSSEC zu behandeln geht IMO fehl. DNS ist der Hammer, der den Nagel DANE in die kaputte Wand "Öffentliche X.509-Zertifikatshierarchien" schlägt. DNSSEC wäre da nur der Hammerkopf. Prinzipiell kannst du auch ohne DNSSEC einen TLSA-Record anlegen - macht aber keinen wirklichen Sinn, da du damit für deinen TLSA-Record keine Vertrauensbasis hast (zur Erinnerung: DNSSEC sichert DNS-Einträge gegen mutwillige oder zufällige Änderungen durch Dritte ab). Wenn man DANE irgendwo integrieren wöllte, dann wohl in X.509 - denn Probleme dieses Standards bzw. dessen öffentlicher Nutzung (genauer der öffentlichen Roots) adressiert es. Dazu ist aber zuerst IMO der Artikel zu X.509 stark überarbeitungsbedürftig.--Mrothyr (Diskussion) 10:06, 15. Mai 2014 (CEST)

Danke! Aber stimmst du mir zumindest soweit zu, dass die Formulierungen im Abschnitt Abschnitt "DNSSEC/Ausblick" nicht mehr ganz up to date sind? Ich denke "Ausblick" ist auch kein besonders passender Name, spätestes seit es DANE gibt. Wie wäre es mit "Grenzen von DNSSEC"? Vielleicht sollte das besser auf der dortigen Diskussionsseite besprochen werden, aber bin im Zuge der Löschdiskussion hier darauf aufmerksam geworden. Ich schlage vor, dass der Abschnitt dort umbenannt und gekürzt wird und ein Link auf DANE als Lösungsansatz gesetzt wird. --DufterKunde (Diskussion) 18:26, 15. Mai 2014 (CEST)

Sivher ist er uberarbeitungsbedürftig. Ich würde DNSSEC aber eher reduzieren und das Thema dann in den allgemeinen DNS-Artikel verlinkten. DNSSEC hat genau einen Zweck: Das Absichern der jeweiligen DNS-Zone gegen unautorisierte Änderungen. Dass im Zug dessen das DNS mehr Aufgaben übernehmen kann und auch übernimmt gehört IMO in den DNS-Artikel und nicht in DNSSEC.--Mrothyr (Diskussion) 12:10, 16. Mai 2014 (CEST)

Ich hab den Abschnitt dort umbenannt in "Grenzen von DNSSEC", gekürzt und hierher (auf DANE) verwiesen. Ich hoffe, ich habe nicht zu viel gekürzt. Würde mich freuen, wenn jemand den Abschnitt weiter verbessern würde. --DufterKunde (Diskussion) 15:40, 16. Mai 2014 (CEST)

DANE Zukunft fehlt im Wiki-Artikel

Ich habe gerade einen Artikel gelesen auf Heise.de . Damit wird gerade das DANE-Protokoll um einige nützliche Funktionen erweitert:

1. Absicherung der TLS-Verbindung ohne CA 2. Verwendung eigener Zertifikate ohne Nutzung einer CA Quelle: Transitschutz - Schlüsselverteilung über DANE für Linux-Server (Anleitung) auf Heise.de 3. Verteilung von Schlüsselmaterial über DANE für z.B. OpenPGP und S/MIME und in Zukunft anderer Dienste. Quelle: Artikel über Verwendung von DANE und DNSSEC zur Schlüsselverteilung (Entwurf IETF)auf Heise.de

Ich finde dieser Ausblick, sollte in diesen Artikel rein. Wenn ich Zeit habe werde ich versuchen was dazu zu schreiben. Nur aktuell habe ich viel im privatem Umfeld und kann deswegen dies nicht versprechen.

--Juppaqa (Diskussion) 17:25, 5. Jan. 2017 (CET)

CA constraint fehlt

Laut RFC 6698 gibt es nicht 3 sondern 4 mögliche Werte für certificate usage. Der Artikel unterschlägt die 0 "CA constraint". (nicht signierter Beitrag von Blahfasel (Diskussion | Beiträge) 18:31, 8. Sep. 2018‎ (CEST))

Erledigt. Der Abschnitt basierte auf einer hoffnungslos veralteten Quelle, wo es nur 3 Werte gab. --Matthäus Wander 16:50, 12. Jan. 2020 (CET)