Cookie Hinweis

Diese Webseite verwendet Cookies. Wenn Sie diese Webseite weiterhin besuchen, stimmen Sie der Nutzung von Cookies zu.

Zur Kenntnis genommen
News | 16.08.2016

DNSSEC: Neue Hardware, neuer Schlüssel

Nach fünf Jahren Produktionsbetrieb mit DNSSEC und vorangegangenem Testbed war die Zeit gekommen, die für die Signierung der .de-Zone eingesetzte kryptographische Hardware (Hardware Security Module, HSM) abzulösen. Weil die privaten DNSSEC-Schlüssel – bestimmungsgemäß – nicht aus dem HSM ausgelesen werden können, kommen mit neuem HSM auch neue Schlüssel – hier: ein neuer Key Signing Key (KSK) – zum Einsatz. Während die Schlüsselwechsel der Zone Signing Keys (ZSK) schon jetzt regelmäßig alle fünf Wochen erfolgen, haben wir nun den ersten vollständigen KSK-Rollover durchgeführt. Künftige KSK-Wechsel werden entsprechend nach Bedarf vorgenommen.

Handlungsbedarf: Keiner
Diesen für die validierenden Resolver vollständig transparenten Vorgang haben wir mit dem „Double DS“-Schema nach RFC 6781 durchgeführt. Dadurch sind noch für eine Übergangszeit zwei DS-Records für DE in der Rootzone hinterlegt. „Double DS“ ist insbesondere beim gleichzeitigen Wechsel von KSK und HSM von Vorteil, weil es ohne doppelte KSK-Signaturen auskommt.

Zukunftsmusik: Elliptische Kurven
Die kryptographischen Parameter, insbesondere den Algorithmus (RSA) und die Schlüssellänge (2048 Bit), haben wir beibehalten. Auch wenn neue Verfahren wie „elliptische Kurven“ (EC) Vorteile durch deutlich kürzere Signaturen bieten, halten wir einen Umstieg auf TLD-Ebene derzeit noch für verfrüht. An den entsprechenden Diskussionen in der Standardisierung und in der operativen Community ist DENIC beteiligt.

Seit September 2015 unterstützt DENIC für Second Level Domains die Registrierung von ECDSA- und GOST-Schlüsseln. Von den aktuell etwa 50.000 signierten .de-Domains nutzen ca. 250 diese EC-Verfahren.

Übrigens:
Auch für die Rootzone steht ein Wechsel des KSK ins Haus, geplant ist derzeit ein bis Anfang 2018 laufendes Verfahren. Dabei ist eine Aktualisierung der Root-Trust-Anchor in jedem validierenden Resolver zwingend notwendig. Betreiber solcher Resolver sollten sich rechtzeitig etwa über ICANN informieren und gegebenenfalls notwendige Aktualisierungen durchführen.