요약

  • RFC 6376에서l=는 정규화 이후 본문의 접두부로 해시 범위를 선택적으로 제한합니다. 서명이 통과하더라도 그 이후에 정규화된 모든 바이트는 DKIM 검증 대상에서 벗어납니다.
  • 헤더 범위는 별개입니다.h=는 정해진 순서대로 서명된 헤더 인스턴스를 지정합니다. 본문이 전부 커버되어도 Subject, Content-Type 등의 필드가 자동으로 인증되는 것은 아닙니다.
  • 유용한 수신 기록은 선택된 서명, 정규화 방식, 접두부와 꼬리의 길이 및 해시, 관측된 DNS 키, 검증자, Authentication-Results의 신뢰 경계를 유지해야 합니다.

완전성이 결여된 성공

인시던트 표에서dkim=pass한 줄은 완결된 결과처럼 보입니다. 그 옆에 또 하나의 데이터가 그 범위를 바꿉니다: 정규화된 본문 18,600바이트,l=14,000. 서명은 처음 14,000바이트에서 통과했습니다. 나머지 4,600바이트는 실패한 것이 아닙니다. 검증에 아예 참여하지 않았을 뿐입니다.

이 구분은 근본적입니다. 암호학적 오류라면 커버된 본문을 무효화했을 것입니다. 범위 밖의 꼬리는 어떤 약속도 하지 않습니다. 그 꼬리는 메일링 리스트가 탈퇴 안내를 덧붙였을 수도, 아카이빙 게이트웨이일 수도, MIME 수정일 수도, 적대적 추가일 수도 있습니다. "pass"라는 한 비트만으로는 어느 이야기가 맞는지 고를 수 없습니다.

RFC 6376은 이 메커니즘을 정확히 정의합니다.l=가 없으면 정규화된 본문 전체가 포함됩니다. 이 태그가 있으면 서명자는 정규화된 본문의 시작부터 몇 바이트를 취할지 선언합니다. 값은 실제 길이를 초과할 수 없습니다.l=0은 이 논리를 극한으로 밀어붙입니다: 본문의 어떤 바이트도 서명되지 않습니다.

검증자는 더 엄격한 정책을 적용할 권리를 유지합니다. 부분적으로만 커버된 본문을 거부하거나 추가 내용을 표시할 수 있습니다. 이는 계산 범위를 바꾸지 않습니다. 따라서 "자기 범위 안에서 수학적으로 유효한 서명"과 "로컬 정책이 수용한 메시지"를 분리해야 합니다.

Murray Kucherawy는 여기서 정확한 문서로 참여합니다. RFC 6376은 Dave Crocker, Tony Hansen과 함께 그를 저자로 명시합니다. DKIM을 한 사람의 업적으로 돌리는 것은 틀렸습니다. Authentication-Results를 다룬 RFC 8601은 그를 저자로 인용합니다. 그의 IETF 프로필 표는 2026년 9월 2일 기준 34건의 RFC를 표시했지만, 같은 페이지의 자서전 텍스트는 여전히 33건이라고 적고 있었습니다. 이 작은 불일치는 공식 출처조차 시계 없는 진실이 아니라 날짜가 붙은 필드의 집합임을 상기시킵니다.

길이는 정규화 이후부터 셉니다

메일 파일의 원시 크기에서l=를 빼는 방식은 흔히 잘못된 계산을 낳습니다. 이 태그는c=에 선언된 본문 정규화 결과를 셉니다.simple과relaxed모드는 공백, 줄 끝, 마지막 빈 줄을 서로 다르게 처리합니다. 따라서 원본 파일에서 보이는 경계가 암호학적 경계와 반드시 일치하지는 않습니다.

규율 있는 재현은 알고리즘을 따릅니다: 원본 메시지를 보관하고;DKIM-Signature의 정확한 인스턴스를 하나 선택하며;c=를 읽고; 본문을 정규화하고; 그 바이트 스트림의 길이를 측정하며; 태그가 있으면l=로 자르고; 해시를 계산해bh=와 비교합니다. 이후 헤더 서명은d=와s=로 얻은 키로 검증합니다.

수신 기록은 계산을 검증 가능하게 만들어야 합니다. 전체 정규화된 본문 길이, 커버된 접두부의 길이, 커버되지 않은 꼬리의 길이를 기록하고, 정규화된 본문 전체에 대한 해시, 접두부 해시, 꼬리 해시를 각각 계산합니다. 양수의 꼬리는 범위의 차이를 나타내며, 악의를 나타내지 않습니다.

키에도 관측 시점이 있습니다. DNS는 로테이션, 폐기, 셀렉터 교체로 바뀔 수 있습니다. 몇 주 뒤에s=._domainkey.d=를 다시 읽는다고 해서 사용된 키를 복원할 수 있는 것은 아닙니다. 관측된 응답, 시각, 오류, 그리고 DNSSEC 상태도 실제로 측정되었을 때만 함께 보존해야 합니다.

같은 공간이 리스트와 공격자 모두에 쓰입니다

l=는 실제 문제를 위해 설계되었습니다. 메일링 리스트는 푸터 서명이나 관리 링크를 자주 추가합니다. 본문 전체를 서명하면 깨질 것입니다. 해시를 초기 콘텐츠로 제한하면 서명자가 검증자가 변형 후에도 그 접두부를 인식하도록 합니다.

그러나 이 관용은 기대된 운영자와 적대적 중간자를 구분하지 못합니다. RFC 6376의 보안 절은 추가 내용이 공격자에게 유리할 수 있으며, 수정된 MIME 구조, 관대한 HTML 파서, 우회된 중복 제거 메커니즘을 통해 수신자가 보는 것을 지배할 수 있다고 경고합니다.

피해야 할 대칭적 오류가 두 가지 있습니다. 첫째는 어떤 추가 꼬리든 공격으로 규정하는 것입니다. 둘째는 접두부 서명을 그 꼬리까지 확장하는 것입니다. 올바른 분석은 중간자를 식별하고, 그 변형을 선언된 규칙과 비교하고, MIME 트리를 재구성하고, 실제 렌더링된 부분을 관찰합니다.

표준은 바이트를 정의합니다. 실행되는 코드는 검증자가 무엇을 계산했는지, 클라이언트가 무엇을 보여주었는지 드러냅니다. 이 접점을 지워버리는 보안 아이콘은 기술적 성공을, 어느 구성 요소도 하지 않은 편집상의 약속으로 바꿉니다.

h=는 다른 윤곽을 그립니다

본문은 DKIM의 절반일 뿐입니다.h=태그는 커버되는 헤더 이름의 순서 목록입니다. 이름이 여러 번 나타나면 목록의 인스턴스는 메시지 아래쪽부터 매겨집니다. "From과 Subject가 서명됨"이라는 단순 집합만 저장하면 이 순서 정보가 파괴됩니다.

From은 반드시 서명되어야 합니다. RFC는 Date, Subject, Reply-To, Sender, 그리고 표시나 처리에 영향을 줄 수 있는 MIME 필드를 강하게 권고합니다.l=가 있으면 Content-Type이 결정적으로 중요해집니다: 커버되지 않은 값은 같은 바이트 접두부의 해석을 바꿀 수 있습니다.

각 서명에 대해 저널은 모든 원시 헤더를 순서대로 표시하고, 실제 선택된 인스턴스를 표시하며, 범위 밖에 남겨진 중요 필드를 알려야 합니다. 같은 메시지의 여러 서명을 절대 하나로 합쳐서는 안 됩니다: 원래 도메인, 리스트, 게이트웨이가 서로 다른 표면에 서명할 수 있습니다.

도메인이 서명한다; 그러나 모든 이야기를 보증하지는 않는다

DKIM 성공은 특정 서명이 어떤 도메인과 셀렉터 아래 공개된 키와, 그 서명이 선택한 본문에 대해 일치함을 의미합니다. 특정 인물이 글을 썼다는 것, 키가 내부 승인대로 사용되었다는 것, 주장이 사실이라는 것, 첨부 파일이 안전하다는 것, 메시지가 전송될 것이라는 것을 증명하지 않습니다.

RFC 5585는 그 속성을 메시지 또는 서명 부분의 무결성으로 한정합니다. RFC 5863은 평가자가 범위 안에 있는 것만 인증된 것으로 보라고 요구하며, 그l=예는 명시적입니다. RFC 8301은 알고리즘과 키 크기를 현대화합니다. 수용 가능한 키는 필요 조건이지만 짧은 접두부를 늘려주지는 않습니다.

DMARC는 다른 질문, 즉 SPF 또는 DKIM 신원과 From의 표시 도메인 사이의 정렬에 답하고, 그다음 정책 신호를 제공합니다. DKIM 범위에 바이트를 하나도 추가하지 않습니다. "정렬됨", "암호학적으로 유효", "전부 커버됨", "신뢰할 만함", "수용됨"은 서로 다른 열로 유지되어야 합니다.

전달되는 결과는 신뢰할 수 있는 생산자가 있어야 합니다

RFC 8601은 검증자가 하류 소비자를 위해 Authentication-Results를 작성할 수 있게 합니다. 이 필드는 일반적으로 자체 인증되지 않습니다. 그 가치는 행정 경계에 달려 있습니다: 소비자는authserv-id를 인식하고, 외부에서 온 위조 필드가 로컬 결과 삽입 전에 제거된다는 것을 알아야 합니다.

발신자는dkim=pass라는 문자를 쓸 수 있습니다. 그것이 수신자 측의 측정이 되지는 않습니다. 수신 기록은 원본 필드, 위치, 생산자, 신뢰 규칙, 그것이 서술하는 정확한 서명을 보존합니다. 게이트웨이가 식별자 없이 세 개의 서명을 하나의 pass로 줄인다면 이후의 모든 검증이 불가능해집니다.

방법 결과와 처분은 분리된 상태로 유지됩니다. 한 검증자는 암호학을 확인하면서l=를 거부할 수 있습니다. 다른 검증자는 경고와 함께 전송할 수 있습니다. 저널은 각각의 이유를 유지해야 하며, 한 단어로 인과관계를 만들어서는 안 됩니다.

최소한의 범위 대장

대장은 해시로 주소 지정되는 원본 메시지로 시작하고, 각 DKIM-Signature 필드를 원래 순서대로 둡니다. 각각에 대해:d=,s=, 존재하면i=,a=,c=,h=,l=,bh=, 서명, 선택적 시각들. 이어서 관측된 DNS 키, 해석된 헤더 인스턴스, 세 영역의 길이와 해시, 검증 소프트웨어, 그 결과와 이유가 옵니다.

대장은 Authentication-Results의 출처와 그 소비를 승인하는 경계를 추가합니다. 마지막으로 렌더링에 대한 비례적 관찰을 유지합니다: MIME 트리, 선택된 파트, 클라이언트 버전, 보이는 영역이l=이후의 바이트에서 온 것인지 여부.

Lu Heng의 행위성 원칙은 권한들을 분리된 채로 유지합니다. 표준 저자들은 문법을 정의합니다. 키 보유자는 범위를 고릅니다. 중간자는 변형합니다. 검증자는 계산합니다. 행정 도메인은 자신의 결과 채널을 보장합니다. 클라이언트는 렌더링합니다. 어떤 행위자도 자신의 권한을 이후의 모든 단계에 빌려줄 수 없습니다.

증명 가능한 결론은 이렇게 됩니다: 이 서명 인스턴스는 이 정렬된 헤더들과 이 정규화된 접두부를 이 관측된 키로 검증했다; 이 꼬리는 검증 밖에 남았다; 이 신뢰 생산자가 결과를 전달했다; 클라이언트는 이런 부분을 렌더링했다; 인간 저자, 보안, 의도는 다른 요소를 필요로 한다.

출처