Network Working Group G. Nitzsche Internet-Draft Private Contributor Intended status: Informational 19 April 2025 Expires: 18 October 2025 Enforcing DNSSEC via HTTPS: Combining DANE and MTA-STS draft-frickl-mta-sts-dnssec-policy-02 This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. This Internet-Draft is a work in progress and is not an IETF standard. It is intended for discussion and informational purposes. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at https://www.ietf.org/1id-abstracts.html The list of current Internet-Drafts can also be accessed at https://datatracker.ietf.org/drafts/current/. The list of Internet-Draft Shadow Directories can be accessed at https://www.ietf.org/shadow.html. Conventions Used in This Document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. Title: Enforcing DNSSEC via HTTPS: Combining DANE and MTA-STS Abstract This document proposes a minimal, backward-compatible extension to the SMTP MTA-STS policy format by adding an optional field "dnssec:" to indicate whether the recipient domain operator expects DNSSEC validation to be active. This allows sending MTAs to detect silent DNSSEC stripping attacks and apply more secure delivery behavior accordingly. The mechanism leverages the existing HTTPS-secured delivery channel of MTA-STS and does not require changes to the DNS infrastructure or SMTP protocol. Table of Contents 1. Introduction ............................................. 2 2. Policy Semantics ......................................... 2 3. Sender MTA Behavior ...................................... 3 4. Example Policy File ...................................... 3 5. Deployment Considerations ................................ 3 6. Security Considerations .................................. 4 7. IANA Considerations ...................................... 5 8. References ............................................... 5 1. Introduction SMTP MTA Strict Transport Security (MTA-STS) [RFC8461] provides a secure channel for recipient domains to signal their TLS policy over HTTPS. However, it was explicitly designed without relying on DNSSEC [RFC4033], and does not provide a way to declare DNSSEC expectations. On the other hand, DANE [RFC7672] clients rely on DNSSEC to activate validation. If DNSSEC data is suppressed via MITM attacks on the resolver path, DANE is not used at all. The result is not a failed DANE validation, but rather its absence--leaving the sender to fall back to opportunistic delivery. This document proposes a simple extension to the MTA-STS policy file format to include a "dnssec: yes" directive, enabling recipient domains to declare their DNSSEC deployment status explicitly. Sending MTAs can use this signal to enforce DNSSEC validation and abort or defer delivery in the absence of signatures. 2. Policy Semantics The semantics of the `dnssec:` field are as follows: - "yes": The domain operator expects DNSSEC signatures to be available. - Other values are undefined and MUST be ignored. Note that when `dnssec: yes` is present, clients MAY still evaluate the TLS-related fields in the policy (e.g., `mode`, `mx`, etc.), depending on local policy or implementation logic. This allows for mixed-mode policies that signal DNSSEC expectations while retaining compatibility with traditional MTA-STS behavior. Clients SHOULD also respect `max_age` and associated caching behavior as defined in the MTA-STS specification. 3. Sender MTA Behavior Sending MTAs that support this HTTPS-based DNSSEC policy signaling (e.g., "dnssec: yes") MUST perform DNSSEC validation when retrieving delivery-related DNS records. In that case, if DNSSEC data is missing, they MUST treat the DNS data as potentially tampered and MUST: - defer delivery (e.g., treating as a 450 temporary failure), - or report a permanent failure. They MUST NOT attempt fallback delivery using opportunistic TLS or plaintext. This is to prevent downgrade attacks and preserve the intent of the recipient domain. This mechanism is intentionally isolated from traditional MTA-STS semantics and acts as an extension to DANE-style validation by providing an authenticated hint via HTTPS that DNSSEC enforcement is expected. Implementations MAY refer to this mechanism as "DANE-STS" or another suitable designation when referencing this policy layer. 4. Example Policy File A typical MTA-STS policy file with the extended DNSSEC directive might look like this: version: STSv1 mode: enforce mx: mail.example.com max_age: 86400 dnssec: yes This example shows the introduction of the new `dnssec` field in the context of a valid and complete MTA-STS policy. The field is interpreted only by clients that support this specification. All others will ignore it. 5. Deployment Considerations While it is theoretically possible to publish DNSSEC enforcement expectations directly within the DNS zone (e.g., via custom TXT records or DNSSEC-based flags), this method cannot provide equivalent security to the HTTPS-based signaling described in this document. Due to the nature of DNS over UDP and its susceptibility to spoofing, race conditions, and cache poisoning, any DNS-only flag remains vulnerable to manipulation--especially in scenarios where the attacker has visibility into or control over authoritative DNS traffic--which is precisely the kind of MITM threat that DANE aims to eliminate. HTTPS over TCP provides a significantly more robust and authenticated channel for delivering such policy hints, making it the preferred mechanism in this context. Encrypted DNS protocols such as DNS-over-HTTPS (DoH) or DNS-over-TLS (DoT) can protect the client-to-resolver path, but offer no protection between the resolver and the authoritative name servers. Therefore, an attacker with access to authoritative DNS traffic--or any point on the resolution chain beyond the client--can still suppress or strip DNSSEC records. This underscores the value of HTTPS-based signaling to ensure policy integrity. This attack scenario also applies to setups described in [DNSCurve], where a passive observer of upstream DNS traffic can forge unsigned responses that arrive before the legitimate DNSSEC-signed ones. Without a signal like the one proposed here, such attacks remain undetected. While it would be technically possible to introduce a separate well- known HTTPS endpoint (e.g., `https://dane-sts.example.com/.well-known/ dane-sts.txt`) for DNSSEC-related policy signaling, this specification deliberately reuses the existing MTA-STS infrastructure. The MTA-STS mechanism is already widely deployed, benefits from mature tooling and operational experience, and provides an authenticated HTTPS channel suited for policy distribution. Leveraging this existing framework reduces complexity, avoids redundant infrastructure, and allows operators to manage transport-related policies in a unified location-- even if traditional MTA-STS and DANE are generally intended as mutually exclusive strategies. 6. Security Considerations The HTTPS-based delivery of the MTA-STS policy protects this metadata from DNS manipulation. This makes the "dnssec:" field resistant to MITM attacks that affect DNS-only channels. However, this mechanism does not protect against forged or misconfigured HTTPS certificates on the policy endpoint. This proposal mitigates the risk of DNSSEC downgrading by forged DNS reply packets, which could otherwise remain undetected by SMTP senders. 7. IANA Considerations This document does not require any IANA actions. 8. References 8.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997. [RFC8461] Margolis, D., et al., "SMTP MTA Strict Transport Security (MTA-STS)", RFC 8461, DOI 10.17487/RFC8461, September 2018. [RFC7672] Dukhovni, V., "SMTP Security via Opportunistic DANE TLS", RFC 7672, DOI 10.17487/RFC7672, October 2015. 8.2. Informative References [RFC4033] Arends, R., et al., "DNS Security Introduction and Requirements", RFC 4033, DOI 10.17487/RFC4033, March 2005. [DNSCurve] Bernstein, D. J., "Forged DNS Responses", https://dnscurve.org/forgery.html Author's Address: Gunther Nitzsche Private Contributor Email: gn@frickl.de NOTE: This draft is intended for discussion and feedback within the DANE and DNSOP communities. Feedback is highly welcome before potential submission as -02 or for adoption. Expires: 18 October 2025 [Page 5]