Beiträge von thomas303

Laut Heise müssen CA's die CAA RRs seit 08.09.2017 bindend beachten:

https://www.heise.de/security/…A-Richtlinie-3827725.html

Nachdem der Mechanismus offenbar greift bzw. bei Fehlverhalten ausreichend Druck auf die CA's aufgabaut wird, wäre es noch schön, wenn man CAA RR endlich auch bei netcup im DNS einpflegen dürfte. Aktuell scheint das immer noch nicht der Fall zu sein (soeben nachgeschaut).

Wird das nun wieder so ein RFC, der mittels moderner Wegelagerei auf Seiten der Domain-/DNS-Anbieter an der Ausbreitung behindert wird?

Wie schwer kann es sein, den CAA Eintrag zu unterstützen?

Gerade ein Anbieter, der DNSSEC anbietet, was selten genug ist, sollte eigentlich erpicht darauf sein, seinen Vorsprung (gegenüber Ewiggestrigen, nur um hier keine Euphorie aufkommen zu lassen) weiter auszubauen und den Mehrwert von DNSSEC zur Geltung kommen zu lassen.

Für meine Begriffe ist der 08.09.2017 der Tag, an dem man als Diensteanbieter endlich einen CAA Eintrag haben möchte. Und sinnvollerweise sollte dieser CAA-Eintrag DNSSEC-verifizierbar sein. Für netcup eigentlich ein Heimspiel.

Google setzt den CAA record bereits, weil sie den CA's, so zumindest mal mitteilen können, welchen CA's sie die Ausstellung von Zertifikaten für Google-Domains anvertrauen.

CAA Mandated by CA/Browser Forum – Network Security Blog | Qualys, Inc.

Wie der Artikel nochmal klarstellt (und wie oben bereits mehrfach geschrieben wurde), hat der CAA record exakt nichts mit Browsern und sonstiger Client-Software zu tun. Beteiligt sind nur

- ein Domaininhaber, der ein Zertifikat anfordert
- die CA, die prüfen muss, ob sie ein Zertifikat ausstellen darf (insbesondere anhand des CAA records)

Hat der Domaininhaber die CA mittels CAA record als ausstellungsberechtigt ausgewiesen, vergibt die CA das Zertifikat. Ansonsten (hoffentlich) nicht.

Ich würde mir wünschen, dass man CAA resource records im VCP von netcup einpflegen kann. Aktuell ist dies nicht der Fall.

Da immer mal wieder neue DNS RR's in Mode kommen, wäre es praktisch, wenn Netcup wenigstens Unterstützung von RFC3597 anbieten würde, damit ein Workaround besteht.

https://tools.ietf.org/html/rfc3597

Mir ist nicht ganz klar, wie das Formular zu bedienen wäre, damit RFC3597 nutzbar wäre.

Aktuell fällt mir auf, dass ein Backslash nicht im Formular gespeichert werden kann. Damit ist die Unterstützung von RFC3597 derzeit wohl nicht gegeben.

Anwendungsfall: Workaround für den fehlenden CAA RR, z. B. mit CAA Record Generator (erzeugt Einträge auch im Format von RFC3597).

Die SSL/TLS-Testseite von Qualys schlägt neuerdings vor, einen CAA RR im DNS anzulegen, (und rfc6844 schlägt natürlich vor, DNSSEC zu aktivieren).

https://tools.ietf.org/rfc/rfc6844.txt

Der CAA Eintrag dient, um für eine Domain angeben zu können, welche CA für diese Domain Zertifikate ausstellen darf.

CA's können somit vor Ausstellung eines Zertifikats prüfen, ob der Domaininhaber vorgesehen hat, dass diese CA ein Zertifikat ausstellen darf.

Der CAA RR ist damit an die CA's gerichtet, nicht an Clients (für Clients gibt es DANE).

Am 08.08.2016 wurde RFC 7929 veröffentlicht und ermöglicht das Verteilen öffentlicher PGP-Schlüssel über DNS. Hierzu ist ein OPENPGPKEY RR im DNS notwendig.

DNS-Based Authentication of Named Entities (DANE) Bindings for OpenPGP
RFC 7929
RFC 7929

Um das ganze bei netcup pflegen zu können, bräuchte man
- die Möglichkeit, den RR OPENPGPKEY im DNS pflegen zu können
- die Veröffentlichung des Eintrags im DNS

DNSSEC/DANE ist ja bereits möglich bei netcup, insofern liegt es auf der Hand, DANE um weitere Anwendungsmöglichkeiten zu erweitern. Die hierzu nötige Änderung beschränkt sich im Wesentlichen auf die Einführung des neuen RR.

Heise pflegt eine Liste mit DNSSEC-fähigen Anbietern:

Hoster und Registrare mit DNSSEC-Diensten |
heise Netze

netcup fehlt hier noch, wäre kostenlose Eigenwerbung.

Zitat von m_ueberall

Noch eine "Wunscherweiterung" (Posting bitte ggf. verschieben): Wenngleich die Standardisierung noch andauert, wäre es sicherlich interessant, mit Verfügbarkeit von DNSSEC auch die DNS-Einträge des Typs 53 (SMIMEA) und 61 (OPENPGPKEY) im CCP eintragen zu können, und sei es im Rahmen einer nächsten Betatestphase.

Ergänzend hierzu die beiden drafts (beide experimental, aber schon weit gediehen):
https://tools.ietf.org/html/draft-ietf-dane-openpgpkey-12
https://tools.ietf.org/html/draft-ietf-dane-smime-11

Für meine Begriffe sind das die bislang geeignetsten Vorschläge, eine Schlüsselverteilung für E-Mail-Verschlüsselung skalierfähig auszurollen.

Endlich S/MIME ohne CA bzw übergangsweise mit CA und DANE-abgesichert. Endlich PGP mit brauchbarer Schlüsselverteilung. Dazu DNSSEC-abgesichert.

Fehlt noch Verbreitung in Software, aber das wird wieder ein Henne-/Ei-Thema. Netcup könnte hier schon mal ein Ei legen.

Ich kann es kaum erwarten, PGPOPENKEY und SMIMEA in Aktion zu sehen. Nicht nur für E-Mails, sondern auch z. B. für Code-Signing. Ich würde es am liebsten gleich einsetzen. Schadet ja nicht.