DKIM und DANE

  • Du hast Dir Dein Unverständnis bereits selbst erklärt;


    darum hier von der anderen Seite:


    angenommen Du bist der erste der DNSSEC/DANE implementiert,

    welches Zertifikat erwarten alle anderen, die es weder implementiert haben noch mangels Möglichkeit

    es auch nicht validieren zu können?

    Richtig: KEIN selbstsigniertes Zertifikat


    d.h. so lange es nicht in ALLEN Browsern, Clients¹, ... entsprechend validiert wird,

    sind in Bezug auf DANE selbstsignierte Zertifikate fehl am Platz;


    ¹ dazu zählen auch ausgehende Mailserver in Form von z.B. Postfix, EXIM, Sendmail, ...

    ebenso Mailclients in Form von z.B. Outlook, Thunderbird, ...


    nebenbei die DNSSEC-RFCs stammen aus den Jahren 2005/06,

    wir reden hier also von 12-13 Jahren nach den RFCs ...

    Grüße / Greetings

    Walter H.


    RS, VPS, Webhosting - was man halt so braucht;)

  • [...] d.h. so lange es nicht in ALLEN Browsern, Clients¹, ... entsprechend validiert wird, [...]

    Nach dieser Argumentation dürfte man Neuerungen überhaupt nur umsetzen, wenn es alle anderen machen (ARC, MTA-STS, ...)

    Hier ist meine Sichtweise: "Frage nicht, was Nutzer/Kommunikationspartner für Dich tun können, frage dich selbst, welche Unterstützung Du ihnen gewähren kannst". Wer meint, die hinterlegten OPENPGPKEY-/SMIMEA-Einträge und alle anderen Sicherheitsstandards nicht überprüfen zu müssen, soll das tun. Das bedeutet allerdings nicht, dass ich schon aus Prinzip durch konsequente Nutzung der Standards keine (teilweise) einseitige Absicherung betreiben kann und werde. (Und Prinzipien sind seit jeher mit eigenen Kosten verbunden.)

    VServer IOPS Comparison Sheet: https://docs.google.com/spreadsheets/d/1w38zM0Bwbd4VdDCQoi1buo2I-zpwg8e0wVzFGSPh3iE/edit?usp=sharing

  • Nach dieser Argumentation dürfte man Neuerungen überhaupt nur umsetzen, wenn es alle anderen machen (ARC, MTA-STS, ...)

    das hast falsch verstanden, hier gings um die Verwendung von Self-signed Zertifikaten, und das setzt nun mal voraus, daß alle Browser/Clients nach DANE validieren, weil sonst SSL Fehler kommen ...

    und in Zeiten von Let's Encrypt gibt es keine Ausrede auf Self-Signed Zertifikate zurückzugreifen;

    Grüße / Greetings

    Walter H.


    RS, VPS, Webhosting - was man halt so braucht;)

  • das hast falsch verstanden, hier gings um die Verwendung von Self-signed Zertifikaten, und das setzt nun mal voraus, daß alle Browser/Clients nach DANE validieren, weil sonst SSL Fehler kommen ...

    und in Zeiten von Let's Encrypt gibt es keine Ausrede auf Self-Signed Zertifikate zurückzugreifen;

    wehe, wenn Let's Encrypt eines Tages wieder von der Bildfläche verschwinden sollte. Ich habe das Gefühl, wir machen uns alle abhängig.

  • das hast falsch verstanden, hier gings um die Verwendung von Self-signed Zertifikaten, und das setzt nun mal voraus, daß alle Browser/Clients nach DANE validieren, weil sonst SSL Fehler kommen ...

    und in Zeiten von Let's Encrypt gibt es keine Ausrede auf Self-Signed Zertifikate zurückzugreifen;

    Für (Standard-)Browser-Zertifikate stimmt das für die meisten Anwender. Let's Encrypt signiert aber keine Mail-Zertifikate. Und der Hinweis mit der Abhängigkeit von eripek ist zumindest für Unternehmen auch nicht von der Hand zu weisen.

    VServer IOPS Comparison Sheet: https://docs.google.com/spreadsheets/d/1w38zM0Bwbd4VdDCQoi1buo2I-zpwg8e0wVzFGSPh3iE/edit?usp=sharing

  • Let's Encrypt signiert aber keine Mail-Zertifikate.

    stimmt, S/MIME hat aber auch mit SSL/TLS bzw. mit TLSA nichts zu tun ...


    und auch hier gilt, so lange Dein gegenüber keine S/MIME Zertifikate mittels DANE validiert

    kannst Du keine Selbst-signierten S/MIME Zertifikate verwenden;

    diese sollten Stufe 2 validiert sein, und das darf etwas kosten;

    z.B. 70 EUR f. 3 Jahre ...

    es gibt auch hier keine Ausrede f. die Verwendung selbstsignierter S/MIME-Zertifikate

    Grüße / Greetings

    Walter H.


    RS, VPS, Webhosting - was man halt so braucht;)

  • [...]

    Für (Standard-)Browser-Zertifikate stimmt das für die meisten Anwender. Let's Encrypt signiert aber keine Mail-Zertifikate.

    stimmt, S/MIME hat aber auch mit SSL/TLS bzw. mit TLSA nichts zu tun ...

    [...]


    Man kann die Let's Encrypt-Zertifikate aber - was vielleicht einige Leute noch völlig nicht beherzt haben - auch zur Transportverschlüsselung für die Mailprotokolle und SFTP - also generell für alles was (SSL und) TLS unterstützt, verwenden. Ich habe manchmal den Eindruck, einige User denken, das könne man nur für's Web verwenden.

  • Man kann die Let's Encrypt-Zertifikate aber - was vielleicht einige Leute noch völlig nicht beherzt haben - auch zur Transportverschlüsselung für die Mailprotokolle und SFTP - also generell für alles was (SSL und) TLS unterstützt, verwenden. Ich habe manchmal den Eindruck, einige User denken, das könne man nur für's Web verwenden.

    siehe #28

  • Das bekommt man mit einem eigenen Server aber hin, also no Problem. Siehe z.B. >> https://www.kuketz-blog.de/cer…tifikate-fuer-mailserver/

    Das sind ganz offensichtlich Äpfel und Birnen im Kontext von SMIMEA/OPENPGPKEY, welche der Signierung des *Inhalts* dienen, nicht der Absicherung des Transports. (Ein selbsterstelltes Führungszeugnis oder andere unbeglaubigte Dokumente werden von Vertragspartnern ja auch nicht anerkannt, nur weil es ihnen von einer Sicherheitsfirma in meinem Auftrag überreicht wird.)

    VServer IOPS Comparison Sheet: https://docs.google.com/spreadsheets/d/1w38zM0Bwbd4VdDCQoi1buo2I-zpwg8e0wVzFGSPh3iE/edit?usp=sharing

  • Eigentlich ging es, meinem Verständnis nach, bei den letzten Antworten um Transportverschlüsselung und eigentlich niemals um Ende-zu-Ende Verschlüsselung. Von dem her ist Lets Encrypt der richtige Ansatz. Und die Abhängigkeit gab es vorher auch bei anderen Zertifikatsanbietern, nur das es eine ganze Stange gekostet hat und auch nicht sicher war (siehe Vorfälle bei Symantec).

  • Eigentlich ging es, meinem Verständnis nach, bei den letzten Antworten um Transportverschlüsselung und eigentlich niemals um Ende-zu-Ende Verschlüsselung. Von dem her ist Lets Encrypt der richtige Ansatz. Und die Abhängigkeit gab es vorher auch bei anderen Zertifikatsanbietern, nur das es eine ganze Stange gekostet hat und auch nicht sicher war (siehe Vorfälle bei Symantec).

    Dann ist der Kritikpunkt wohl, dass LE nur die faktische Domainverfügungsmacht überprüft, nicht aber die Identität des Antragstellers. Das ist aber für Transportverschlüsselung eher zweitrangig.

  • Das sind ganz offensichtlich Äpfel und Birnen im Kontext von SMIMEA/OPENPGPKEY, welche der Signierung des *Inhalts* dienen

    das ist falsch bzw. unvollständig; selbstsigniert abgesichert mit SMIMEA knall ich garantiert retour; und nebenbei ist SMIMEA der SuperGAU schlechthin;

    wer SMIMEA verwendet der hat damit ohnehin eine Einladung auf's Schwarze Brett geschrieben, daß er mit Malware, Phishing, und sonstigem Plunder in verschlüsselter Form zugemüllt werden will; viel Spaß mit SPAM-Filtern im klassischen Sinn :D

    Grüße / Greetings

    Walter H.


    RS, VPS, Webhosting - was man halt so braucht;)

  • Dann ist der Kritikpunkt wohl, dass LE nur die faktische Domainverfügungsmacht überprüft, nicht aber die Identität des Antragstellers. Das ist aber für Transportverschlüsselung eher zweitrangig.

    Richtig. Ich glaube aber auch nicht, dass vorher Inhabervalidierte Zertifikate für die Transportverschlüsselung genutzt wurden, wenn überhaupt signierte Zertifikate genutzt wurden. Ich habe meine in der Anfangszeit auch selbstsigniert, bis ich dann auch Lets Encrypt umgestiegen bin.


    PGP ist für den normalen Nutzer nicht benutzerfreundlich, wenn Ende-zu-Ende, da eventuell s/MIME, wenn auch mit Schwachstellen.

  • Richtig. Ich glaube aber auch nicht, dass vorher Inhabervalidierte Zertifikate für die Transportverschlüsselung genutzt wurden, wenn überhaupt signierte Zertifikate genutzt wurden. Ich habe meine in der Anfangszeit auch selbstsigniert, bis ich dann auch Lets Encrypt umgestiegen bin.


    PGP ist für den normalen Nutzer nicht benutzerfreundlich, wenn Ende-zu-Ende, da eventuell s/MIME, wenn auch mit Schwachstellen.

    Ich bin den Zwischenschritt über CaCert.org gegangen.

    PGP +1 been there, done that - als es noch voll neu und in Mode war. Wobei bei WoT auch public server im Spiel sind und man durch die wechselseitige Zertifizierung eigentlich den Vorläufer heutiger sozialer Netze hat - von dem man im Grunde auch E-Mailadressen abgreifen kann. Möglichkeiten zum Social Engineering (etwa durch Domainwechsel oder Fakeprofile) eingeschlossen.