DNSSEC: KSK-Rollover in der root-Zone verschoben

Ich erwähnte ja schon, dass eigentlich geplant war, am 10. Oktober den KSK der root-Zone zu tauschen. Die ICANN hat jetzt angekündigt das zu verschieben: Durch die relativ neue Erweiterung Signaling Trust Anchor Knowledge aus RFC8145 hat man jetzt wohl herausgefunden, dass irgendwo zwischen fünf und sieben Prozent der validierenden Resolver weltweit immer noch nur dem Schlüssel aus dem Jahr 2010 vertrauen. Bei der Menge an Leuten, die das betreffen würde, haben sie sich dann überlegt, das lieber bleiben zu lassen. [Mehr]

TLSA-Records in Ruby, online

Wie viele andere verwende ich für private Seiten Let’s Encrypt, um SSL-Zertifikate zu beziehen. Gleichzeitig publiziere ich im DNS sog. TLSA-Records, um zusätzlich die Sicherheit zu erhöhen. Wenn jetzt ein automatisches Update der Zertifikate statt findet, dann ändert sich ja zumindest mal der Record vom Typ 3 1 1 (End Entity, Public Key, SHA-256). Der Eintrag vom Typ 2 1 1 (Trust Anchor, i.e. CA, Public Key, SHA-256) bliebt wahrscheinlich gleich. [Mehr]

DNSSEC: KSK in der root-Zone

Es steht ja nun schon einige Zeit im Raum, aber langsam wird es konkret: In der DNS Root Zone wird es einen KSK Rollover geben. KSK Rollover sind jetzt nichts so besonderes - ich habe selbst durchaus schon einige davon mitgemacht, aber wenn das die weltweit wichtigste DNS-Komponente überhaupt betrifft, dann ist das natürlich eine etwas andere Hausnummer. Nachdem sich der Trust Anchor ändert, ist es natürlich auf allen DNSSEC-fähigen Resolvern notwendig, sich darum zu kümmern, diesen neuen Trust Anchor auch lokal einzupflegen. [Mehr]

SMTP: Schlechtere Verschlüsselung kann besser sein

In einer perfekten Welt würden nach Bekanntwerden einer Sicherheitslücke alle Server innerhalb weniger Stunden gepatched werden. Neue Verschlüsselungsalgorithmen wären nach wenigen Wochen überall verfügbar und Änderungen an unterstützender Infrastruktur wie z.B. die Implementierung von DANE wären in ein paar Monaten durch. Und dann wacht man auf und stellt fest, dass die Welt leider alles andere als perfekt ist. Und so muss ich nun leider, schweren Herzens und verschämt, eine Aussage invalidieren, die ich in diesem Blog-Eintrag getroffen habe. [Mehr]

Mehr Crypto: DANE TLSA, SSHFP

Was könnte man eigentlich noch machen, wenn man dem eigenen DNS etwas mehr Sicherheit verpasst hat? Na ja, eine Idee wäre z.B., im DNS bestimmte Aussagen über den sonstigen Einsatz von Kryptographe zu treffen. Dabei gibt es zwei Dinge, die mir sinnvoll erscheinen: Zum einen SSHFP-Records, mit denen man den Host-Key eines SSH-Servers im DNS verewigen kann, und zum anderen DANE TLSA, mit dem man selbiges etwas universeller tun kann. [Mehr]

Jedem seine eigene Verschwörungstheorie

Ohne Kommentar (es ging um das hier, und wir alle dachten, wir hätten Kaminski ausgestanden) - Kudos to Vernon: Now we (including me) have known the dangers and limitations, so should we set max-udp-size to 1220 on every authoritative servers? Sometimes crazy conspiracy theories make too much sense. Please make up one of your own from some facts: Some known major PKI failures were ostensibly in support of nation states. [Mehr]

bind9: Views, DNSSEC, AD, AA, DO, RA, RD

Ich fange diesen Artikel bewusst mit einem Zitat von Stephane Bortzmeyer an, einem der Betreiber der TLD-DNS-Server für die .fr-Zone: Views are brittle and complicated and should be avoided. Fühlt Euch also gewarnt. Es gibt (für mich) zwei gute Gründe, Views einzusetzen. Der Erste ist das Bedürfnis, gewisse interne Zonendaten (z.B. die RFC1918-IPs meiner virtuellen Maschinen sowie die Adressen der Point-to-Point-Links, die selbige verbinden, jeweils vor- wie auch rückwärts) auch wirklich nur den Clients zur Verfügung zu stellen, die sie benötigen. [Mehr]