DNSSEC und DANE - DNSSEC Key-Rollover

DNS Workshop

Created: 2019-08-29 Thu 09:55

DNSSEC Keyrollover

Agenda

  1. Warum Keyrollover
  2. ZSK Rollover 'pre-publish'
  3. KSK Rollover 'double-signing'
  4. Algorithmus Rollover
  5. Notfall-Rollover

Warum Keyrollover

  • DNSSEC Schlüsselmaterial ist öffentlich
    • inkl. Signaturen und der dazugehörige Klartext (DNS-Record-Sets)
  • der private Schlüssel kann in falsche Hände fallen
    • Versehen
    • Angriffe
    • für "online" Signing liegen die privaten Schlüssel auf jedem authoritative DNS-Server der Zone
  • die Schlüsselgrösse oder der benutzte Algorithmus gilt nicht für längere Zeit als sicher

die Herausforderungen

  • DNS ist nicht konsistent
    • verschiedene authoritative DNS-Server können verschiedene Versionen der Zone ausliefern (Zonentransfer)
    • DNS-Daten werden in Resolvern, Betriebssystemen und Anwendungen gecached
  • bei einem DNSSEC Key-Rollover muss sichergestellt sein, das die Vertrauenskette zu jeder Zeit und von jedem Punkt des Internet vollständig sichtbar sein

DNSSEC Keyrollover Dokumentation

  • RFC 6781 - "DNSSEC Operational Practices, Version 2"
  • RFC 7583 - "DNSSEC Key Rollover Timing Considerations"

Keyrollover, wann und wie-oft?

  • DNSSEC Schlüssel haben keine technische Lebenszeit
    • die operative Lebenszeit wird von den DNS Administratoren festgelegt und kann jederzeit geändert werden

Keyrollover, wann und wie-oft?

  • In der DNS-Community gibt es verschiedene Ansätze zum Wechsel des KSK:
    • oft und regelmäßig
    • oft aber unregelmäßig (um Angreifern keine Information zu liefern, wann Rollover stattfinden)
    • nur, wenn es den Verdacht gibt, das die Schlüssel kompromittiert wurden

ZSK Rollover

  • der Zone-Signing-Key hat keine Abhängigkeiten zu externen Ressourcen
  • der Rollover kann jederzeit durchgeführt werden
  • für den ZSK-Rollover wird oft das 'pre-publication' Verfahren benutzt

ZSK - pre-publication - Schritt 1

  • neues ZSK-Schlüsselpaar erstellen
  • den öffentlichen Schlüssel (DNSKEY) des neuen ZSK in der Zone publizieren
  • der aktuelle ZSK verbleibt in der Zone
  • die Zonendaten werden mit dem aktuellen ZSK neu signiert

ZSK - pre-publication - Schritt 2

  • warten das die Zone mit dem ZSK auf allen authoritativen DNS-Servern sichtbar ist (Zonentransfer)
  • die TTL des DNSKEY RRSet (+ Sicherheitsbuffer) abwarten
  • nun ist der neue ZSK in allen DNS-Resolver Caches

ZSK - pre-publication - Schritt 3

  • der Zoneninhalt wird mit dem neuen ZSK signiert
  • der neue ZSK ist nun "aktiv", der alte ZSK ist nun "retired"
  • der alte ZSK bleibt in der Zone (er wird noch benötigt, um Signaturen aus Caches zu validieren)

ZSK - pre-publication - Schritt 4

  • warten das die Zone mit dem ZSK auf allen authoritativen DNS-Servern sichtbar ist (Zonentransfer)
  • die grösste TTL der Zone (+ Sicherheitsbuffer) abwarten
  • nun sind die neuen Signaturen des neuen ZSK in allen DNS-Resolver Caches

ZSK - pre-publication - Schritt 5

  • den alten ZSK aus der Zone entfernen
  • die Zone mit dem neuen ZSK neu signieren

ZSK - pre-publication in Bildern 01/12

zsk-roll01.png

ZSK - pre-publication in Bildern 02/12

zsk-roll02.png

ZSK - pre-publication in Bildern 03/12

zsk-roll03.png

ZSK - pre-publication in Bildern 04/12

zsk-roll04.png

ZSK - pre-publication in Bildern 05/12

zsk-roll05.png

ZSK - pre-publication in Bildern 06/12

zsk-roll06.png

ZSK - pre-publication in Bildern 07/12

zsk-roll07.png

ZSK - pre-publication in Bildern 08/12

zsk-roll08.png

ZSK - pre-publication in Bildern 09/12

zsk-roll09.png

ZSK - pre-publication in Bildern 10/12

zsk-roll10.png

ZSK - pre-publication in Bildern 11/12

zsk-roll11.png

ZSK - pre-publication in Bildern 12/12

zsk-roll12.png

KSK Rollover

  • der KSK hat die Abhängigkeit vom DS-Record in der Elternzone
  • für den KSK-Rollover wird das 'double-signing' Verfahren verwendet (der DNSKEY-Set bekommt 2 Signaturen, von beiden KSKs)

KSK - double-signing - Schritt 1

  • ein neues KSK-Schlüsselpaar erstellen
  • den neuen öffentlichen DNSKEY Record in der Zone publizieren
  • den DNSKEY RRSet mit beiden KSKs (alt und neu) signieren

KSK - double-signing - Schritt 2

  • warten das die Zone mit dem KSK auf allen authoritativen DNS-Servern sichtbar ist (Zonentransfer)
  • die TTL des DNSKEY RRSet (+ Sicherheitsbuffer) abwarten
  • nun ist der neue KSK in allen DNS-Resolver Caches

KSK - double-signing - Schritt 3

  • den neuen DS-Record an den Betreiber der Elternzone senden
  • warten, das der DS-Record in der Elternzone erscheint
  • TTL des DS-Records in der Elternzone abwarten (+ Sicherheitsbuffer)

KSK - double-signing - Schritt 4

  • den alten KSK aus der Zone entfernen
  • den DNSKEY-Records-Set mit dem neuen KSK signieren

KSK - double-signing in Bildern (1/12)

ksk-roll01.png

KSK - double-signing in Bildern (2/12)

ksk-roll02.png

KSK - double-signing in Bildern (3/12)

ksk-roll03.png

KSK - double-signing in Bildern (4/12)

ksk-roll04.png

KSK - double-signing in Bildern (5/12)

ksk-roll05.png

KSK - double-signing in Bildern (6/12)

ksk-roll06.png

KSK - double-signing in Bildern (7/12)

ksk-roll07.png

KSK - double-signing in Bildern (8/12)

ksk-roll08.png

KSK - double-signing in Bildern (9/12)

ksk-roll09.png

KSK - double-signing in Bildern (10/12)

ksk-roll10.png

KSK - double-signing in Bildern (11/12)

ksk-roll11.png

KSK - double-signing in Bildern (12/12)

ksk-roll12.png

Algorithmus Rollover

  • bei einem Wechsel des DNSSEC-Algorithmus wird ein Algorithmus-Rollover durchgeführt
    • z.B. bei einem Wechsel von RSASHA256 zu ECDSA256
  • bei einem Algorithmus-Rollover werden der KSK und der ZSK mit einem "double-signing" Rollover gewechselt

Notfall Rollover

  • um Schritt 1 eines KSK (oder ZSK) Rollover zu sparen, kann ein "Standby"-Schlüssel in der Zone publiziert sein
  • dieser Schlüssel wird im Normalbetrieb nicht benutzt
  • muss einer der aktiven Schlüssel gewechselt werden, wird auf den "Standby"-Schlüssel umgeschaltet
  • "Standby"-Schlüssel sollten beim normalen Schlüssel-Rollover ausgetauscht werden

Fragen?