요약

  • STARTTLS는 개별 SMTP 연결을 암호화할 수 있었지만, 저장 후 전달(store-and-forward) 체계는 여전히 암호화가 불가능할 때 전달을 우선하는 것이 통상이었다. RFC 8689는 개별 메시지에 이동 가능한 지시를 부여했다. 다음 홉마다 인증을 요구하고, 요건을 이후로 함께 전달하며, 평문으로 후퇴하지 말라는 것이다.
  • 요건을 충족하는 MX를 찾지 못한 릴레이는 메시지를 안전하지 않게 전송하는 대신 보호된 미전달 통지를 반환해야 한다. REQUIRETLS는 종단 간 암호화를 만들지 않았다. 대신 신뢰된 메일 릴레이 사슬 안에서 실패를 명시적인 보안 결정으로 만들었다.

두 통을 하나의 발신 큐에 놓아 보자. 같은 수신 도메인, 같은 MX 서버들, 같은 일시적 인증서 문제를 공유한다. 첫 번째 통은 평범한 메일을 담는다. 릴레이는 TLS를 시도할 수 있고, 정책에 따라 암호화를 성립하지 못하더라도 여전히 전달을 우선할 수 있다. 두 번째 통에는 작은 내부 표식이 붙어 있다. 이 메시지에 대해서는 같은 후퇴가 금지된다.

차이는 더 강한 암호가 아니다. 저장된 하나의 메시지에 붙은 권한이다.

SMTP는 불연속적인 관계 속에서 메일을 운반하도록 설계되었다. 클라이언트가 서버에 메시지를 넘기면, 그 서버는 큐에 넣고 다음 홉을 선택하고 나중에 재시도하거나 다른 릴레이로 넘길 수 있다. 메시지가 남아 있는 동안 연결은 끊어진다. TLS 세션 안에만 존재하는 규칙은 따라서 너무 일찍 만료된다. 수신 시스템이 그 규칙을 지속적인 메시지 상태로 전환하지 않는 한 다음 연결을 지배할 수 없다.

RFC 8689의REQUIRETLS확장은 바로 그 일을 했다. 보안 선호가 SMTP 세션 사이의 간격을 넘어 살아남게 하고, 보호되지 않은 홉보다 미전달을 선호하게 만든 것이다.

STARTTLS는 연결을 보호했지 메시지의 여정을 보호하지 않았다

1999년의RFC 2487은 SMTP용 STARTTLS를 도입했다. 호환성 문제는 심각했다. 공개 메일 교환은 상대편에 TLS가 없다는 이유만으로 쉽게 중단할 수 없었다. 메일은 오랫동안 '언젠가 도착하는 것'을 핵심 의무로 다루어 왔으므로, 이 확장은 보안을 사용할 수 없을 때 계속 진행할 여지를 남겨 두었다.

RFC 3207은 2002년 이 메커니즘을 개정했다. 서버가 STARTTLS를 광고하고 클라이언트가 요청하며, 양쪽은220응답 이후 TLS를 시작한다. 핸드셰이크가 끝나면 평문에서 얻은 지식은 폐기되고 클라이언트는EHLO를 다시 보낸다. 이 규칙은 공격자가 조작할 수 있는 첫 인사말이 보호된 단계를 은밀히 지배하는 것을 막는다.

그러나 깨끗한 전환이 여전히 답하는 것은 연결에 관한 질문이다. 지금 이 두 SMTP 피어가 무엇을 할 수 있는가? 한 피어가 메시지를 수락한 뒤 큐에 저장된 메시지에 지시를 붙이지는 않는다. 나중의 릴레이가 상호운용성 대신 평문을 거절할 것을 보장하지도 않는다.

이후 수신 도메인들은 외부 정책을 갖추게 되었다.RFC 7672는 SMTP DANE을 위해 DNSSEC으로 인증된 TLSA 레코드를 사용한다.RFC 8461은 도메인이 허용 가능한 MX 호스트를 지정하고 인증서 검증과 함께 TLS를 요구하는 MTA-STS 정책을 게시하게 한다. 이 메커니즘들은 수신 도메인이 기대하는 바를 말한다. 그 자체로는, 평범한 메일 사이의 이례적으로 민감한 한 메시지에 대해 발신자가 받을 별도의 답을 제공하지 않는다.

지시는 봉투를 통해 들어왔다

2019년에 발표된RFC 8689는REQUIRETLS라는 이름의 EHLO 기능을 등록했다. 새 SMTP 동사를 추가하지 않았다. 대신 기존 봉투 명령에 값을 갖지 않는 매개변수를 추가했다.

MAIL FROM:<sender@example> REQUIRETLS

위치가 중요하다. 메시지 헤더는 메시지와 함께 전달되는 내용이고, SMTP 봉투는 현재 전송을 제어한다. 발신 릴레이는 TLS를 성립시키고 목적지를 검증하고 보호된 채널 안의 두 번째 EHLO에서 REQUIRETLS가 광고되는 것을 확인한 후에만 이 매개변수를 사용할 수 있다. 서버가 확장을 지원한다는 평문 상의 주장은 충분하지 않다.

수신 서버는 수락한 메시지에 REQUIRETLS 처리용 표식을 달아야 한다. 표준은 데이터베이스 열, 큐 파일 비트 또는 메타데이터 형식을 의도적으로 규정하지 않는다. 의무를 규정한다. 로컬 별칭 처리로 메시지가 여러 수신자 인스턴스로 나뉘면, 모든 인스턴스가 같은 표식을 유지해야 한다.

이것이 세션 사이의 다리이다. 회선상의 매개변수가 저장된 정책이 된다. 그 서버가 나중에 다음 릴레이를 향해 클라이언트로 동작할 때, 보안 조건을 재구성하고 다음MAIL FROM에서REQUIRETLS를 반복해야 한다.

네 가지 증명이 다음 전송에 앞선다

바운스가 아닌 일반 메시지에 대해, 적합한 발신자는 "TLS를 사용했다"는 사실만으로 충분하다고 볼 수 없다. REQUIRETLS 메시지를 다음으로 넘기기 전에 증거의 사슬을 세워야 한다.

첫째,RFC 5321의 라우팅 규칙에 따라 수신자의 SMTP 목적지를 해석한다. 목적지가 DNSSEC으로 인증되지 않은 MX 레코드에서 나왔다면, MTA-STS가 허용된 서버 이름을 검증해야 한다. 둘째, 연결 자체가 TLS로 보호되어야 한다. 셋째, 제시된 인증서는 인정된 신뢰 사슬 또는 DANE을 통과해 검증되어야 한다. 넷째, 서버가 STARTTLS 이후, 새로 보호된 EHLO 응답에서 REQUIRETLS를 광고해야 한다.

이 검사들은 서로 다른 질문에 답한다. TLS는 채널 암호화를 제공한다. 인증서 또는 DANE 검증은 채널을 의도된 다음 홉에 연결한다. DNSSEC 또는 MTA-STS는 어떤 MX 신원이 의도된 것으로 간주되는지 제약한다. TLS 이후의 기능 광고는 다음 릴레이가 메시지 수준의 규칙을 보존하겠다고 약속함을 증명한다.

이들을 "encrypted=yes" 같은 하나의 로그 필드로 합치면 결정이 지워진다. 대체된 MX로의 암호화된 연결은 요구된 결과가 아니다. 다음 릴레이가 메시지를 수락하면서 표식을 잊는다면, 유효한 인증서도 요구를 충족하지 못한다.

실패가 집행 수단이 되었다

선호하는 MX가 TLS 이후 REQUIRETLS를 광고하지 않는다면, 발신자는 그 시도를 중단하고 다음 MX를 시도한다. 같은 서버가 큐에서 평범한 메시지는 계속 받을 수 있다. 제한은 목적지에 대한 영구 분류가 아니라 표식이 붙은 메시지에 속한다.

요건을 충족하는 MX가 없으면 전송이 멈춘다. RFC 8689는 서버가 REQUIRETLS 지원이 없을 때 강화 상태5.7.30을, 암호화된 세션을 성립할 수 없을 때5.7.10을 권고한다. 발신자는 원래의 역방향 경로로 미전달 통지를 생성한다.

이것이 이 프로토콜 역사상 가장 날카로운 변화다. 기회적 전달 아래에서는 보안 협상의 실패가 더 덜 보호된 시도를 승인할 수 있었다. REQUIRETLS 아래에서는 같은 실패가 전송 권한 자체를 제거한다. 신뢰성은 더 이상 바이트가 도착했는지로만 측정되지 않는다. 제약을 충족할 수 없었다는 증거를 돌려보내는 것이 더 충실한 결과다.

이 선택에는 비용이 따른다. 일시적 인증서 오류, 정책 발견 실패 또는 누락된 기능이, 원래는 도착했을 메시지를 지연시키거나 막을 수 있다. REQUIRETLS는 이 트레이드오프를 숨기지 않는다. 결정을 발신자에게 돌리고 그 실패를 관찰 가능하게 만든다.

바운스마저 비밀을 물려받았다

미전달 통지에는 종종 실패한 메시지의 헤더가 담긴다. 발신자, 수신자, 제목 줄 또는 라우팅 단서를 드러낼 수 있다. 원본을 보호된 홉으로만 보내고 그 진단을 평문으로 돌려보낸다면, 결정의 일부가 무력화된다.

그래서 RFC 8689는 REQUIRETLS 메시지로 인해 발생한 바운스가, 원래 실패가 TLS와 무관하더라도 REQUIRETLS를 실어야 한다고 요구한다. 또 인용되는 자료를 좁힌다. 바운스는 DSNRET=HDRS가 요청된 것처럼 동작하고, 충돌하는RET=FULL요청은 무시된다.

반환 경로에는 재귀 문제가 생긴다. SMTP 바운스는 빈 역방향 경로를 사용해 실패한 바운스가 또 다른 바운스를 무한히 만들지 않도록 한다. 보호된 복귀 경로는 갈 때의 경로와 다를 수도 있다. 그래서 표준은 보호된 진단이 소실될 수 있음을 경고하고, 다음 홉이 REQUIRETLS를 갖지 않을 때 빈 역방향 경로 메시지에 대한 예외를 둔다.

따라서 침묵은 모호하다. 발신자는 원본이 목적지로 전송되지 않았음을 알 수 있으면서도, 보호된 설명은 영원히 받지 못할 수 있다. 바운스의 부재는 전달의 증거가 아니다.

놀라운 헤더는 "No"라고 말했다

RFC 8689는TLS-Required: No도 정의했다. 이름이 봉투 매개변수의 반대처럼 보이는 이유는 실제로 그렇기 때문이다. 그 목적은 발신자가 수신 측 DANE 또는 MTA-STS 정책이 전달을 막지 않도록 요청하게 하는 것이다. 예컨대 관리자에게 목적지의 인증서가 망가졌음을 알리기 위해서다.

릴레이는 여전히 STARTTLS를 시도해야 한다. 이 헤더는 평문을 명령하지 않는다. TLS 또는 정책 검증이 실패했을 때 무엇이 일어나는지를 바꾼다. 수신 서버 자체가 암호화되지 않은 SMTP를 거절한다면 그 결정이 여전히 우선한다. 발신자 정책이 피어에게 연결을 수락하도록 강제할 수는 없다.

보호된 봉투 매개변수와 이 헤더가 동시에 존재하면, 봉투 지시가 우선하고 헤더는 처리 시 무시된다. 이런 헤더는 메시지에 하나만 있을 수 있다. 이 우선순위는 REQUIRETLS 전송 내부의 신뢰할 수 없는 내용이 봉투에서 협상된 의무를 약화시키는 것을 막는다.

중계는 재발신보다 쉬웠다

정상적인 릴레이는 표식을 하나의 봉투에서 다음 봉투로 옮길 수 있다. 메일링 리스트, 전달 서비스, Sieve 프로그램 또는 부재중 응답기는 대신 새 메시지를 만들 수 있다. 원래의 SMTP 트랜잭션은 끝났고, 헤더는 다시 쓰이고 수신자는 늘어나며 소유권이 이동한다.

RFC 8689는 이런 중개자들에게 새로 발신되는 메시지에 수신한 선택을 가능한 범위에서 적용하도록 요청한다. 경계를 사라지게 할 수는 없다. 수백 명의 수신자로 확장된 리스트는 일부 경로만 REQUIRETLS를 지원함을 발견할 수 있다. 사용자 측 필터는 SMTP 봉투 표식을 아예 보지 못할 수도 있다.

여기서 이동 가능한 지시가 제도적 현실과 부딪힌다. 프로토콜은 적합한 릴레이가 명령을 어떻게 보존하는지 정의할 수 있다. 모든 중개자가 새 저자가 아니라 릴레이임을, 또는 모든 신뢰된 MTA가 정직하게 행동할 것임을 증명할 수는 없다.

전송 보호는 여전히 운반자를 신뢰했다

REQUIRETLS는 종단 간 암호화가 아니다. 참여하는 각 MTA는 TLS를 종단하며 다음 보호 연결을 시작하기 전에 메시지를 읽을 수 있다. 악의적인 릴레이는 지원을 광고하고 표식이 붙은 메시지를 수락한 뒤 표식을 떼어버릴 수 있다. RFC 8689는 그런 릴레이를 위협 모델 밖에 둔다. 이미 평문을 보유하고 있기 때문이다.

이 확장은 수동 관측, STARTTLS 제거, 대체된 MX 경로, 적합 시스템 사이의 우발적 후퇴에는 유용하다. 인간 저자를 인증하지 않고, 저장된 큐를 암호화하지 않고, 릴레이로부터 내용을 감추지 않으며, 다음 인수 이후의 최종 결과를 증명하지도 않는다.

IANA SMTP 레지스트리는 REQUIRETLS 토큰과 그 참조를 기록한다. 그 한 줄은 표준화된 할당을 증명한다. 배포량, 메시지 규모 또는 운영 적합성을 측정하지는 않는다.

지속되는 아이디어는 더 작고 더 정밀하다. 저장 후 전달 네트워크에는 결정이 자신의 연결보다 오래 살아남는 방법이 필요했다. REQUIRETLS는 "암호화를 사용해 주십시오"를 "이 조건을 보존할 수 없다면 눈에 띄게 실패하고 전송하지 마십시오"로 바꾸었다. 메시지는 단순히 더 안전한 길을 요청한 것이 아니라, 어떤 목적지 결과가 여전히 정당한지를 정의했다.