NIST faseert de 'SHA-1'-hash-functie volledig uit
Controleer of je met je ondertekende domeinen nog moet overstappen naar een modern DNSSEC-algoritme
Het Amerikaanse standaardisatie- en technologie-instituut NIST heeft de volledige uitfasering van de SHA-1 hash-functie in gang gezet. 10 jaar geleden deed het instituut SHA-1 al in de ban voor de toepassing in digitale handtekeningen (waarin de hash als (cryptografisch-statistisch) unieke samenvatting fungeert). En nu dus ook voor alle andere toepassingen, waaronder HMAC (authenticatie van berichten op basis van een gedeelde sleutel), het genereren van random getallen en het hashen van wachtwoorden.
Voor DNSSEC is het afscheid van SHA-1 op 2 punten relevant: Als eerste maakt het DNSSEC-algoritme gebruik van een hash-functie als onderdeel van het genereren van de digitale handtekeningen (gepubliceerd in de RRSIG-records). Daarnaast worden de publieke sleutels van een ondertekende domeinnaam (gepubliceerd in de DNSKEY-records) geauthenticeerd door de hashes daarvan in de bovenliggende zone te publiceren (als ondertekende DS-records).
Hoewel SHA-1 al langer niet meer toegepast moest worden in digitale handtekeningen, is deze aankondiging voor ons aanleiding om bij domeinnaamhouders en DNS-operators nog eens aan te dringen op het gebruik van moderne algoritmen.
Definitief afscheid van SHA-1
NIST geeft (Amerikaanse) gebruikers en leveranciers ruim de tijd voor het uitfaseren van SHA-1. Eind 2030 moet dit algoritme overal vervangen zijn door andere hash-functies: SHA-2 (samen met SHA-1 gespecificeerd in FIPS 180-4) en SHA-3 [1, 2] (gespecificeerd in FIPS 202). Die laatste specificatie bevat ook de SHAKE-variant die gebruikt wordt in het EdDSA-gebaseerde DNSSEC-algoritme nummer 16.
Hoewel 2030 nog bijna 8 jaar weg is, raadt NIST aan SHA-1 zo snel mogelijk uit je infrastructuur te verwijderen. Tegen die tijd zal het instituut ook FIPS 180-5 publiceren, waarin SHA-1 niet langer opgenomen zal zijn.
SHA-1 en DNSSEC
Wat betreft DNSSEC is de uitfasering van SHA-1 – ondanks dat het hier om het gebruik in digitale handtekeningen gaat – nog niet al te lang geleden in gang gezet. RFC 8624 (gepubliceerd in juni 2019) geeft voor de ondertekening met de algoritmen nummer 5 (RSASHA1) en nummer 7 (RSASHA1-NSEC3-SHA1) de negatieve aanbeveling 'NOT RECOMMENDED' (en 'MUST NOT' voor de andere 'SHA-1'-gebaseerde algoritmen).
RFC 6944 (de voorganger van RFC 8624) gaf voor nummer 5 en 7 nog de aanbevelingen 'Must Implement' en 'Recommended to Implement', ondanks dat deze RFC is gepubliceerd in 2013, nota bene door iemand van NIST zelf. Daarbij gaf hij wel de kanttekening dat de implementatie van RSASHA1 een verplicht onderdeel was van de DNSSEC-standaard (zoals gespecificeerd in RFC 4034).
SHA-1 onder het .nl-domein
Kijken we naar het .nl-domein, dan zien we dat nog maar 1,5 promille van de ondertekende domeinnamen gebruikmaakt van een 'SHA-1'-gebaseerd DNSSEC-algoritme (en dan vooral nummer 7: RSASHA1 met ondersteuning voor NSEC3).
In dezelfde grafiek kun je ook zien dat het gebruik van algoritme nummer 7 twee jaar geleden nog op 17 procent zat en daarna razendsnel omlaagging. In het voorjaar van 2021 zijn we actief gaan sturen op de uitfasering van de oude DNSSEC-algoritmen (alles onder nummer 8) en hebben we de incentive-regeling voor DNSSEC daarop aangepast. Grote DNS-operators zoals TransIP hebben daar gelijk op gereageerd door hun crypto-algoritme naar een nieuwer algoritme te rollen.
Overstappen naar nummer 13
We raden ook de laatste houders van een domeinnaam ondertekend met een DNSSEC-algoritme kleiner dan nummer 8 dringend aan om over te stappen naar een nieuwer algoritme. Op dit moment is algoritme nummer 13 (ECDSA Curve P-256 with SHA-256) de beste keuze.
Hetzelfde geldt voor gebruikers van DNSSEC-algoritme nummer 8 (RSA/SHA-256) – op dit moment goed voor 43 procent van de ondertekende domeinnamen in de .nl-zone. Ook zij kunnen het beste overgaan op nummer 13, zij het dat die overstap minder haast heeft.
Voor het .nl-topleveldomein zelf gebruiken we op dit moment (februari 2023) ook nog algoritme nummer 8. Het is de bedoeling om later dit jaar over te schakelen naar algoritme nummer 13.
DS- en CDS-records
Zoals in de inleiding al aangegeven, worden hashes ook gebruikt om de publieke sleutels van een ondertekende domeinnaam (gepubliceerd in de DNSKEY-records) te laten authentiseren door het bovenliggende domein (door de hash-waarden van die publieke sleutels te publiceren in een ondertekend DS-record).
Voor de hash-functie gebruikt voor de DS-records geldt hetzelfde als voor de hash-functie gebruikt bij het zetten van de digitale handtekeningen (gepubliceerd in de RRSIG-records). De hashes in de DS-records hebben immers dezelfde functie als de hashes die onderdeel zijn van de digitale handtekeningen: het leveren van een unieke samenvatting (in dit geval van de publieke sleutels).
RFC 8624 adviseert voor de DS- en CDS-records alleen nog hash-algoritme nummer 2 (SHA-256) te gebruiken, terwijl het gebruik van algoritme nummer 1 (SHA-1) wordt afgeraden. Eventueel is nog algoritme nummer 4 beschikbaar, gebaseerd op de wat sterkere 'SHA-384'-hash-functie, maar de meerwaarde daarvan is op dit moment beperkt.
Let op dat het hier om andere algoritmenummers gaat dan de tot nu toe besproken DNSSEC-algoritmen.
DS-records in de .nl-zone
Houders van .nl-domeinnamen is de keuze van het hash-algoritme voor de DS/CDS-records uit handen genomen. Wij vragen registrars niet om de DS-records maar om de originele DNSKEY-records aan te leveren. Uit die laatste genereren wij vervolgens zelf de bijbehorende DS-records (gebaseerd op hash-algoritme nummer 2) voor publicatie in de .nl-zone.
We raden iedereen wel aan om te controleren of hun domeinnamen onder andere top-levels misschien nog DS-records gebaseerd op hash-algoritme nummer 1 bevatten, en dan zo snel mogelijk over te schakelen naar algoritme nummer 2.