DANE 그리고 MTA-STS 둘 다 지원 전송 시스템이 인증된 SMTP 전송을 시행하도록 합니다. 이들의 신뢰 종속성은 다르며 이러한 차이점은 첫 번째 메시지 이전, DNS 문제 발생 중 및 인증서 변경 시 중요합니다. 둘 중 하나를 선택하려면 성공적인 TLS 핸드셰이크뿐만 아니라 수신 운영자와 공급자가 유지할 수 있는 항목에 대한 목록이 필요합니다.
하나의 수신 경로를 따르십시오.
참고자료: RFC 7672 §2, RFC 8461 §3, RFC 8461 §4.
TCP 포트 25에서 MX mx1.example.net 과 함께 example.com 사용하십시오. SMTP DANE 에서 발신자에게는 적절한 DNSSEC 검증 라우팅이 필요하며 TLSA 발견 과정. 이 단순 비별칭 호스트의 경우 TLSA 소유자는 _25._tcp.mx1.example.net 입니다. 사용 가능한 보안 TLSA 연결은 지원 발신자에게 TLS 서비스를 인증하는 방법을 알려줍니다. 에이 TXT 레코드 수신자 도메인에서는 대체되지 않습니다. RFC 7672 섹션 2 및 3.
MTA-STS 에서 수신자 도메인은 _mta-sts.example.com 에서 검색을 게시하고 mta-sts.example.com 에서 인증된 HTTPS를 통해 정책을 제공합니다. 정책은 의도된 MX 이름과 소모품 모드 및 수명을 승인합니다. STS 인증의 경우 SMTP 서버는 RFC 8461 §4.2에 따라 일치하는 SAN DNS-ID를 포함하여 적용 가능한 공개 키 인프라 인증서 검사를 충족해야 합니다. 일반 TLS 호스트 이름 프로브만으로는 전체 프로필을 설정하지 않습니다. 정책 호스트 인증서와 메일 서버 인증서는 서로 다른 서비스를 보호합니다. RFC 8461 섹션 3 및 4.
첫 번째 접촉 및 실패 상태 비교
참고자료: RFC 7672 §2.1, RFC 8461 §2, RFC 8461 §3.3, RFC 8461 §10.2.
DANE 다음을 통해 정책 검색을 인증할 수 있습니다. DNSSEC 검증 체인이 안전하고 사용 가능한 기록이 존재할 때 첫 번째 접촉 시. 이는 재귀 확인자가 반환한 답변을 신뢰하는 것과는 다릅니다. 가짜 검증 결과는 유효한 안전하지 않은 위임과 동일하지 않습니다. 확인자 신뢰 관계와 각 관련 답변의 유효성 검사 상태를 기록합니다.
MTA-STS 에는 부트스트랩 제한이 있습니다. 즉, 사용 가능한 캐시 정책이 없는 발신자는 정책을 얻지 못할 수 있습니다. 만료되지 않은 시행 정책을 보유하고 있는 발신자는 새로운 정책을 얻을 수 없을 때 이를 계속 적용해야 합니다. 따라서 빈 캐시와 웜 캐시 사례를 별도로 비교하십시오. 하나의 모니터링 호스트에서 성공적인 HTTPS는 모든 발신자가 정책을 학습했음을 증명하지 않습니다.
명시적으로 가상적인 네 가지 상태를 고려해보세요. 첫 번째 접촉 시 안전하게 사용 가능한 DANE 검색을 통해 MTA-STS 획득이 억제된 경우에도 지원 발신자가 서비스를 인증할 수 있습니다. 만료되지 않은 시행 MTA-STS 정책이 캐시된 경우 검색에 실패해도 해당 정책은 삭제되지 않습니다. A에서 B로의 키 변경은 새 인증서가 PKIX를 충족하더라도 이전 전용 TLSA 연결에 실패할 수 있습니다. 중첩은 두 키를 모두 덮을 수 있습니다. 적용 가능한 캐시된 STS 정책에 의해 제외된 MX 로 이동하면 호환 정책이 학습될 때까지 MX 확인이 실패할 수 있습니다. 이는 준수된 DNSSEC , 캐시 또는 전송 테스트가 아닌 표준 기반 예입니다.
메커니즘은 일반적으로 두 가지 모두를 통과하도록 요구하는 방식으로 결합되지 않습니다. RFC 8461 §2는 특정 비간섭 요구 사항을 설정합니다. 성공적인 MTA-STS 검증은 실패한 DANE 검증을 무시해서는 안 됩니다. 둘 다 통과해야 한다고 주장하는 일반 비교 모델은 규범적인 발신자 알고리즘이 아닙니다.
동일한 롤오버를 두 번 계획합니다.
참고자료: RFC 7672 §4, RFC 8461 §8.
DANE-EE 사용법 3은 보안 연결을 통해 인증합니다. RFC 7672 §3.1.1은 STS에서 사용하는 PKIX ID 또는 인증서 만료 확인을 요구하지 않습니다. 모든 TLSA 사용에 무차별적으로 해당 예외를 적용하지 마십시오. DANE-EE의 경우 선택자 SPKI 및 SHA-256에서 공개 키를 변경하면 연결 다이제스트가 변경됩니다. 새 키를 배포하기 전에 기존 및 새 연결을 게시하고, 기존 DNS 캐시 및 관련 서명 레코드가 만료되도록 허용하고, 모든 활성 엔드포인트에 대한 적용 범위를 유지하세요. 동일한 키로 인증서를 재발급하는 것은 키를 순환하는 것과 다릅니다. RFC 7672 섹션 4.
MTA-STS 의 경우 유효한 MX ID와 신뢰를 유지하는 일반 인증서 갱신 자체에는 정책 MX 패턴을 변경할 필요가 없습니다. MX 마이그레이션은 이전 및 새 수신 호스트를 모두 포함하는 정책을 준비하고 이전 정책을 유지하는 발신자에 대한 계정을 제공합니다. 두 모델 모두 다른 검사기가 녹색으로 보고한다는 이유만으로 끊어진 경로를 무시하는 것을 허용하지 않습니다.
운영 소유권으로 결정
참고자료: RFC 8461 §2.
수신자 DNS , MX 호스트 DNS , DNSSEC 서명, SMTP 인증서 배포 및 HTTPS 정책 호스팅을 제어하는 팀을 나열합니다. 호스팅 공급자는 도메인 소유자가 직접 변경할 수 없는 종속성을 제어할 수 있습니다. 고객에게 제어권을 약속하기 전에 지원되는 프로세스를 확립하십시오. 두 메커니즘이 모두 배포되는 경우 성공적인 MTA-STS 검증은 실패한 DANE 검증을 재정의해서는 안 됩니다. 이 가이드에서는 라이브 DNSSEC 체인 또는 SMTP 전달이 실행되지 않았습니다. 비교는 표준 기반이며 로컬 예제는 명시적으로 합성됩니다.