Roll-over voor root zone vraagt om attentie van DNSSEC -beheerders
Afgelopen najaar heeft ICANN de roll-over van het (KSK) sleutelpaar voor de root zone in gang gezet. Dat betekent dat het cryptografische sleutelpaar dat aan de basis ligt van de hele DNSSEC-infrastructuur wordt ververst (dat wil zeggen vervangen).
Er kleven belangrijke risico's aan deze update. Hoewel de kans daarop klein is, kan een fout betekenen dat het hele internet (inclusief de niet-ondertekende domeinen) onbereikbaar wordt voor alle gebruikers/applicaties die gebruik maken van validerende resolvers.
Hetzelfde speelt op lokaal niveau. Beheerders van validerende resolvers zullen moeten zorgen dat eerst de nieuwe (publieke) sleutel aan de trust anchors op hun servers wordt toegevoegd, en later dat de oude sleutel van hun systemen wordt verwijderd. Laten zij dat na, dan kunnen de digitale handtekeningen onder de top-level domeinen (TLD's) in de root zone niet meer gevalideerd worden. In dat geval zouden alle internet-domeinen voor de gebruikers van de betreffende resolver onbereikbaar worden.
RFC 5011 maakt het mogelijk de nieuwe (publieke) sleutel automatisch als trust anchor te laten installeren. De ontwikkelaars van de meest gebruikte validerende resolvers — PowerDNS, BIND named, Unbound en OpenDNSSEC — geven aan dat hun software dit protocol ondersteunt. De sterk verouderde appliances van Infoblox ondersteunen RFC 5011 niet, waarmee ze hun klanten met een nieuw probleem opzadelen.
Eerste roll-over
Dit is de eerste roll-over van de root key sinds het genereren, installeren en publiceren van de allereerste root key in 2010. De roll-over is op dit moment in volle gang. Dat we daar zo weinig van merken of horen komt doordat dit een stringent gecontroleerd en langzaam verlopend proces is.
Het operationele gedeelte van de roll-over is afgelopen najaar daadwerkelijk van start gegaan met het genereren van een nieuw KSK sleutelpaar. Het hele proces zal nog duren tot maart 2018, wanneer de oude sleutel uit de root zone verwijderd wordt. De echte, administratieve doorlooptijd van dit project is echter veel langer: deze begon met de eerste publieke consultatie in 2013, en eindigt met de vernietiging van het oude sleutelpaar nu gepland voor augustus 2018.
Planning
De operationele planning ziet er op dit moment als volgt uit:
- 27 oktober 2016: een nieuw sleutelpaar gegenereerd
- februari 2017: de nieuwe (publieke) sleutel gepubliceerd op de IANA site
- 11 juli 2017: de nieuwe (publieke) sleutel gepubliceerd als DNSKEY-record in de root zone
- 11 oktober 2017: de root zone ondertekend met nieuwe sleutel (daadwerkelijke roll-over)
- 11 januari 2018: de oude (publieke) sleutel ingetrokken (digitale handtekeningen gebaseerd op het oude sleutelpaar zijn niet meer geldig)
- 22 maart 2018: de oude (publieke) sleutel verwijderd uit de root zone
- augustus 2018: de laatste kopie van het oude sleutelpaar vernietigd
Nieuw sleutelpaar
Hoewel het nieuwe sleutelpaar inmiddels wel al is gegenereerd, is deze (dat wil zeggen de publieke sleutel daarvan) nog niet beschikbaar gemaakt. Op dit moment worden de sleutels eerst intern getest en geaudit, waarna ze naar de tweede "digitale kluis" (HSM) van ICANN worden gekopieerd. Pas daarna zal de publieke sleutel eerst op de website van IANA worden gepubliceerd, later als DNSKEY-record in de root zone.
Voor de beheerders van validerende resolvers is het dus nog even wachten op de daadwerkelijke publicatie van de nieuwe (publieke) sleutel. Vanaf dat moment kunnen zij die sleutel opnemen als trust anchor in de eigen systemen. Dat moet uiterlijk 11 oktober 2017 voor elkaar zijn, wanneer het oude sleutelpaar niet langer gebruikt wordt om te ondertekenen. Wordt dit nagelaten, dan kunnen de digitale handtekeningen onder de top-level domeinen (TLD's) in de root zone niet meer gevalideerd worden. In dat geval zouden alle internet-domeinen voor de gebruikers van de betreffende resolver onbereikbaar worden.
Voor beheerders is het dus van belang om nu al een proces voor deze change in te richten — al was het alleen maar in de vorm van een dwingende reminder — met name omdat het hier om een "eenmalige" gebeurtenis gaat.
Updates
Er zijn drie manieren om de nieuwe publieke sleutel als trust anchor in een validerende resolver op te (laten) nemen. De eerste is met de hand: daarvoor kan de sleutel — vanaf volgende maand dus — worden binnengehaald van de IANA website en in de configuratie van de resolver worden opgenomen. Later kan de oude sleutel met de hand verwijderd of uitgeschakeld worden.
In sommige gevallen — bijvoorbeeld voor verschillende Linux-distributies — zullen deze updates automatisch plaatsvinden met de reguliere systeem-updates. Eerst wordt het nieuwe trust anchor als onderdeel van een package update geïnstalleerd, later wordt het oude trust anchor op dezelfde manier verwijderd. Vanzelfsprekend gaat dit alleen goed als het update-proces voor de betreffende systemen inderdaad regelmatig wordt uitgevoerd.
RFC 5011
Daarnaast is er een protocol ontwikkeld om een validerende resolver zelf een nieuwe (publieke) sleutel binnen te laten halen en deze als trust anchor te laten installeren. RFC 5011 beschrijft hoe een resolver op die manier de roll-over van een trust anchor volledig geautomatiseerd kan uitvoeren.
Daartoe wordt eerst de nieuwe (publieke) sleutel in de vorm van een DNSKEY record opgehaald van een authoritatieve server voor de root zone. Omdat dit record is voorzien van een digitale handtekening gebaseerd op het oude, al vertrouwde sleutelpaar, kan de authenticiteit ervan gewoon met behulp van de bestaande DNSSEC-functionaliteit gevalideerd worden. Door het zetten van een nieuw vlaggetje in het DNSKEY-record — het SEP-bit (Secure Entry Point) — weet de resolver dat deze sleutel aan de trust anchors toegevoegd kan worden.
Later kan door het zetten van de REVOKE-flag van het DNSKEY-record de oude (publieke) sleutel op zijn beurt uit de lijst van trust anchors worden gehaald. Deze al bestaande optie wordt nu dus niet alleen meer gebruikt voor het ongeldig verklaren van gekraakte sleutelparen maar ook voor het opruimen van verlopen sleutelparen.
De RFC beschrijft verder in detail de verschillende scenario's met hun afhandeling en timing-voorwaarden om een en ander zo betrouwbaar mogelijk te laten verlopen.
Omdat deze methode geheel en al rust op de aanwezigheid van een vertrouwde (publieke) sleutel aan resolver zijde, werkt deze alleen voor systemen die al een trust anchor geïnstalleerd hebben.
Ondersteuning
Er zijn op dit moment diverse validerende resolvers waarvan de ontwikkelaars aangeven dat die RFC 5011 ondersteunen, waaronder BIND named, Unbound en OpenDNSSEC.
De appliances van Infoblox ondersteunen dit protocol helaas niet. We schreven al eerder over hun sterk verouderde DNSSEC-implementatie, waar nu weer een nieuw probleem aan toegevoegd is. Deze appliances worden met name gebruikt door grote organisaties zoals overheden en banken, die verwachtten daarmee een turn-key oplossing in huis te hebben gehaald.
Aanbevelingen
Ook voor validerende resolvers waarvoor is aangegeven dat de software RFC 5011 wel ondersteunt lijkt het ons niet raadzaam om daar zomaar op te vertrouwen. Gezien de risico's voor eindgebruikers en omdat dit de eerste keer is, raden wij de beheerders van deze servers aan de (automatische) installatie van de nieuwe (publieke) sleutel als trust anchor nauwlettend te volgen en te controleren. Dit kan vanaf 11 juli, wanneer de nieuwe sleutel in de vorm van een DNSKEY-record in de root zone wordt gepubliceerd.
De handmatige installatie van het nieuwe trust anchor kan vanaf volgende maand al. Dan wordt de nieuwe (publieke) sleutel voor het eerst gepubliceerd op de site van IANA.
Vanaf 11 januari 2018 kan het oude trust anchor tenslotte verwijderd worden. Uiterlijk 22 maart 2018 moet dat ook daadwerkelijk gebeurd zijn.
