요약

  • RFC 9905는 2025년 11월 발행된 IETF 표준 트랙 문서로, RFC 4034와 RFC 5155를 갱신합니다.
  • RSASHA1 및 RSASHA1-NSEC3-SHA1로 DS, DNSKEY, RRSIG 레코드를 만들어서는 안 됩니다(MUST NOT). 다른 수용 가능한 DS 경로가 없는 상태에서 영향을 받는 DS 전용 위임은 insecure로 처리됩니다.
  • 검증기 구현은 이 알고리즘으로 검증을 계속 구현해야 합니다(MUST). 이 의무는 서명 금지 및 insecure 위임 처리 결과와 별개입니다.

이 메커니즘은 레지스트리 항목에서 드러납니다. 생산은 MUST NOT으로 표시되고, 검증 구현은 연속성을 위해 요구사항으로 남습니다. 따라서 RFC 9905는 모든 검증기가 지금 SHA-1 검증을 제거해도 된다는 뜻이 아닙니다. 운영자는 IANA 레지스트리가 권고하는 더 강한 알고리즘으로 영역을 이전해야 하며, 소비 측은 전환 기간 동안 아직 남아 있는 자료를 검증할 수 있는 능력을 유지합니다. 이미 SHA-1 검증을 제거한 소프트웨어는 이 구현 의무를 충족하기 위해 수동 빌드가 필요할 수 있습니다.

운영 절차에는 세 개의 서로 다른 점검 지점이 있습니다. 첫째, 권한 있는 서명자는 RSASHA1 및 RSASHA1-NSEC3-SHA1 DNSKEY와 RRSIG 레코드 생성을 중단해야 합니다. 둘째, 위임 소유자는 해당 알고리즘으로 DS 레코드 생성을 중단하고, 이전 경로를 철수하기 전에 수용 가능한 더 강한 DS 경로를 게시해야 합니다. 셋째, 재귀 검증 인프라는 구현 지원을 유지하고 남아 있는 레거시 자료를 검증할 수 있는 능력을 시험해야 합니다. 새 서명 구성만으로는 위임이나 재귀 플릿이 이전을 완료했다는 증거가 되지 않습니다.

통제된 변경은 겹침(overlap)을 사용합니다. 더 강한 DNSKEY와 RRSIG 자료를 게시하고 검증하고, 더 강한 DS를 게시한 뒤, 이전 경로가 전환용 잔존물로만 남아 있는 동안 재귀 검증이 성공하는지 관찰합니다. 권한 응답, DS 세트, DNSKEY와 RRSIG 검색, 검증 결과, 캐시를 고려한 타이밍을 기록하십시오. 롤백 근거도 마찬가지로 구체적입니다. 이전 영역과 키 구성을 보존하고, 마지막으로 정상이었던 DS 상태를 문서화하며, 새 SHA-1 자료를 만들지 않고 이전 수용 구성을 복원하는 방법을 정의하십시오. 롤백을 금지된 생산을 재개할 수 있는 허가와 혼동해서는 안 됩니다.

구체적 점검 사항:

  1. 서명자 구성과 생성된 영역에서 RSASHA1 및 RSASHA1-NSEC3-SHA1 DNSKEY 또는 RRSIG 출력을 검색하십시오. 새 생산에 대해서는 결과가 0이어야 합니다.
  2. 부모 DS 게시를 별도로 점검하십시오. 의도한 더 강한 알고리즘이 존재하고, SHA-1 전용 위임이 secure로 처리되고 있지 않은지 확인하십시오.
  3. 재귀 검증기를 남아 있는 레거시 픽스처와 더 강한 알고리즘 영역에 대해 시험하십시오. 검증 결과와 구현 버전 또는 빌드 옵션을 기록하십시오.
  4. 배포된 소프트웨어가 SHA-1 검증을 제거했는지 확인하십시오. 그렇다면 지속되는 검증 요구사항을 충족하는 수동 빌드나 다른 구현 경로를 계획하십시오.

이것은 암호학적 문제인 동시에 소프트웨어 수명 주기와 락인 문제이기도 합니다. 조기 제거 결정은 설치 기반이 필요로 하는 호환성을 없앨 수 있고, 변경되지 않은 서명자는 새 생산 규칙을 위반할 수 있습니다. 고정된 출처로는 현재 채택 현황, 벤더, 인시던트, 성능 또는 향후 레지스트리 변경 데이터가 제공되지 않으므로, 이러한 질문에는 별도의 근거가 필요합니다.

출처