--- 1/draft-ietf-uta-smtp-tlsrpt-03.txt 2017-04-05 08:13:13.658274585 -0700 +++ 2/draft-ietf-uta-smtp-tlsrpt-04.txt 2017-04-05 08:13:13.694275438 -0700 @@ -1,55 +1,55 @@ Using TLS in Applications D. Margolis Internet-Draft Google, Inc Intended status: Standards Track A. Brotman -Expires: August 19, 2017 Comcast, Inc +Expires: October 5, 2017 Comcast, Inc B. Ramakrishnan Yahoo!, Inc J. Jones Microsoft, Inc M. Risher Google, Inc - February 15, 2017 + April 3, 2017 SMTP TLS Reporting - draft-ietf-uta-smtp-tlsrpt-03 + draft-ietf-uta-smtp-tlsrpt-04 Abstract A number of protocols exist for establishing encrypted channels between SMTP Mail Transfer Agents, including STARTTLS [RFC3207], DANE - [RFC6698], and SMTP MTA STS (TODO: Add ref). These protocols can - fail due to misconfiguration or active attack, leading to undelivered - messages or delivery over unencrypted or unauthenticated channels. - This document describes a reporting mechanism and format by which - sending systems can share statistics and specific information about - potential failures with recipient domains. Recipient domains can - then use this information to both detect potential attackers and - diagnose unintentional misconfigurations. + [RFC6698], and MTA-STS (TODO: Add ref). These protocols can fail due + to misconfiguration or active attack, leading to undelivered messages + or delivery over unencrypted or unauthenticated channels. This + document describes a reporting mechanism and format by which sending + systems can share statistics and specific information about potential + failures with recipient domains. Recipient domains can then use this + information to both detect potential attackers and diagnose + unintentional misconfigurations. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. 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." - This Internet-Draft will expire on August 19, 2017. + This Internet-Draft will expire on October 5, 2017. Copyright Notice Copyright (c) 2017 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 (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -61,61 +61,60 @@ Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 2. Related Technologies . . . . . . . . . . . . . . . . . . . . 4 3. Reporting Policy . . . . . . . . . . . . . . . . . . . . . . 4 3.1. Example Reporting Policy . . . . . . . . . . . . . . . . 5 3.1.1. Report using MAILTO . . . . . . . . . . . . . . . . . 5 3.1.2. Report using HTTPS . . . . . . . . . . . . . . . . . 5 - 4. Reporting Schema . . . . . . . . . . . . . . . . . . . . . . 6 + 4. Reporting Schema . . . . . . . . . . . . . . . . . . . . . . 5 4.1. Report Time-frame . . . . . . . . . . . . . . . . . . . . 6 - 4.2. Delivery Summary . . . . . . . . . . . . . . . . . . . . 7 - 4.2.1. Success Count . . . . . . . . . . . . . . . . . . . . 7 + 4.2. Delivery Summary . . . . . . . . . . . . . . . . . . . . 6 + 4.2.1. Success Count . . . . . . . . . . . . . . . . . . . . 6 4.2.2. Failure Count . . . . . . . . . . . . . . . . . . . . 7 4.3. Result Types . . . . . . . . . . . . . . . . . . . . . . 7 - 4.3.1. Routing Failures . . . . . . . . . . . . . . . . . . 7 - 4.3.2. Negotiation Failures . . . . . . . . . . . . . . . . 7 - 4.3.3. Policy Failures . . . . . . . . . . . . . . . . . . . 8 - 4.3.4. General Failures . . . . . . . . . . . . . . . . . . 8 - 4.3.5. Transient Failures . . . . . . . . . . . . . . . . . 8 + 4.3.1. Negotiation Failures . . . . . . . . . . . . . . . . 7 + 4.3.2. Policy Failures . . . . . . . . . . . . . . . . . . . 7 + 4.3.3. General Failures . . . . . . . . . . . . . . . . . . 8 + 4.3.4. Transient Failures . . . . . . . . . . . . . . . . . 8 5. Report Delivery . . . . . . . . . . . . . . . . . . . . . . . 8 - 5.1. Report Filename . . . . . . . . . . . . . . . . . . . . . 9 + 5.1. Report Filename . . . . . . . . . . . . . . . . . . . . . 8 5.2. Compression . . . . . . . . . . . . . . . . . . . . . . . 9 - 5.3. Email Transport . . . . . . . . . . . . . . . . . . . . . 10 + 5.3. Email Transport . . . . . . . . . . . . . . . . . . . . . 9 5.4. HTTPS Transport . . . . . . . . . . . . . . . . . . . . . 10 - 5.5. Delivery Retry . . . . . . . . . . . . . . . . . . . . . 11 + 5.5. Delivery Retry . . . . . . . . . . . . . . . . . . . . . 10 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 7. Security Considerations . . . . . . . . . . . . . . . . . . . 11 - 8. Appendix 1: Example Reporting Policy . . . . . . . . . . . . 12 - 8.1. Report using MAILTO . . . . . . . . . . . . . . . . . . . 12 + 8. Appendix 1: Example Reporting Policy . . . . . . . . . . . . 11 + 8.1. Report using MAILTO . . . . . . . . . . . . . . . . . . . 11 8.2. Report using HTTPS . . . . . . . . . . . . . . . . . . . 12 9. Appendix 2: JSON Report Schema . . . . . . . . . . . . . . . 12 - 10. Appendix 3: Example JSON Report . . . . . . . . . . . . . . . 15 + 10. Appendix 3: Example JSON Report . . . . . . . . . . . . . . . 14 11. Normative References . . . . . . . . . . . . . . . . . . . . 16 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 1. Introduction The STARTTLS extension to SMTP [RFC3207] allows SMTP clients and hosts to establish secure SMTP sessions over TLS. The protocol design is based on "Opportunistic Security" (OS) [RFC7435], which - provides interoperability for clients that do not support STARTTLS + maintains interoperability with clients that do not support STARTTLS but means that any attacker who can delete parts of the SMTP session (such as the "250 STARTTLS" response) or redirect the entire SMTP session (perhaps by overwriting the resolved MX record of the delivery domain) can perform a downgrade or interception attack. Because such "downgrade attacks" are not necessarily apparent to the receiving MTA, this document defines a mechanism for sending domains - to report on failures at multiple parts of the MTA-to-MTA + to report on failures at multiple stages of the MTA-to-MTA conversation. Recipient domains may also use the mechanisms defined by MTA-STS (TODO: Add ref) or DANE [RFC6698] to publish additional encryption and authentication requirements; this document defines a mechanism for sending domains that are compatible with MTA-STS or DANE to share success and failure statistics with recipient domains. Specifically, this document defines a reporting schema that covers failures in routing, STARTTLS negotiation, and both DANE [RFC6698] @@ -127,34 +126,34 @@ SMTP MTA Strict Transport Security (MTA-STS, TODO: Add ref). 1.1. Terminology The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this document, are to be interpreted as described in [RFC2119]. We also define the following terms for further use in this document: - o STS Policy: A definition of the expected TLS availability, + o MTA-STS Policy: A definition of the expected TLS availability, behavior, and desired actions for a given domain when a sending - MTA encounters problems in negotiating a secure channel. STS is - defined in [TODO] + MTA encounters problems in negotiating a secure channel. MTA-STS + is defined in [TODO] - o DANE Policy: A mechanism for enabling the administrators of domain - names to specify the keys used in that domain's TLS servers. DANE - is defined in [RFC6698] + o DANE Policy: A mechanism by which administrators can supply a + record that can be used to validate the certificate presented by + an MTA. DANE is defined in [RFC6698]. o TLSRPT Policy: A policy specifying the endpoint to which sending MTAs should deliver reports. - o Policy Domain: The domain against which an STS or DANE Policy is - defined. + o Policy Domain: The domain against which an MTA-STS or DANE Policy + is defined. o Sending MTA: The MTA initiating the delivery of an email message. 2. Related Technologies o This document is intended as a companion to the specification for SMTP MTA Strict Transport Security (MTA-STS, TODO: Add ref). o The Public Key Pinning Extension for HTTP [RFC7469] contains a JSON-based definition for reporting individual pin validation @@ -162,79 +161,73 @@ o The Domain-based Message Authentication, Reporting, and Conformance (DMARC) [RFC7489] contains an XML-based reporting format for aggregate and detailed email delivery errors. 3. Reporting Policy A domain publishes a record to its DNS indicating that it wishes to receive reports. These SMTP TLSRPT policies are distributed via DNS from the Policy Domain's zone, as TXT records (similar to DMARC - policies) under the name "smtp-tlsrpt". For example, for the Policy + policies) under the name "_smtp-tlsrpt". For example, for the Policy Domain "example.com", the recipient's TLSRPT policy can be retrieved - from "smtp-tlsrpt.example.com". + from "_smtp-tlsrpt.example.com". Policies consist of the following directives: o "v": This value MUST be equal to "TLSRPTv1". o "rua": A URI specifying the endpoint to which aggregate information about policy failures should be sent (see the section _Reporting_ _Schema_ for more information). Two URI schemes are supported: "mailto" and "https". * In the case of "https", reports should be submitted via POST ([RFC2818]) to the specified URI. * In the case of "mailto", reports should be submitted to the specified email address. When sending failure reports via - SMTP, sending MTAs MUST NOT honor SMTP STS or DANE TLSA - failures. - - o "ruf": Future use. (There may also be a need for enabling more - detailed "forensic" reporting during initial stages of a - deployment. To address this, the authors consider the possibility - of an optional additional "forensic reporting mode" in which more - details--such as certificate chains and MTA banners--may be - reported.) + SMTP, sending MTAs MUST deliver reports despite any TLS-related + failures. This may mean that the reports are delivered in the + clear. - The formal definition of the "smtp-tlsrpt" TXT record, defined using + The formal definition of the "_smtp-tlsrpt" TXT record, defined using [RFC5234], is as follows: tlsrpt-record = tlsrpt-version *WSP %x3B tlsrpt-rua tlsrpt-version = "v" *WSP "=" *WSP %x54 %x4C %x53 %x52 %x50 %x54 %x76 %x31 tlsrpt-rua = "rua" *WSP "=" *WSP tlsrpt-uri tlsrpt-uri = URI ; "URI" is imported from [@!RFC3986]; commas (ASCII ; 0x2C) and exclamation points (ASCII 0x21) ; MUST be encoded; the numeric portion MUST fit ; within an unsigned 64-bit integer - If multiple TXT records for "smtp-tlsrpt" are returned by the + If multiple TXT records for "_smtp-tlsrpt" are returned by the resolver, records which do not begin with "v=TLSRPTv1;" are discarded. If the number of resulting records is not one, senders MUST assume the recipient domain does not implement TLSRPT. 3.1. Example Reporting Policy 3.1.1. Report using MAILTO - smtp-tlsrpt.example.com. IN TXT \ + _smtp-tlsrpt.example.com. IN TXT \ "v=TLSRPTv1;rua=mailto:reports@example.com" 3.1.2. Report using HTTPS - smtp-tlsrpt.example.com. IN TXT \ + _smtp-tlsrpt.example.com. IN TXT \ "v=TLSRPTv1; \ rua=https://reporting.example.com/v1/tlsrpt" 4. Reporting Schema The report is composed as a plain text file encoded in the JSON format ([RFC7159]). Aggregate reports contain the following fields: @@ -234,34 +227,34 @@ 4. Reporting Schema The report is composed as a plain text file encoded in the JSON format ([RFC7159]). Aggregate reports contain the following fields: o Report metadata: * The organization responsible for the report - * Contact information for one or more responsible parties for the contents of the report * A unique identifier for the report * The reporting date range for the report o Policy, consisting of: - * One of the following policy types: (1) The SMTP MTA STS policy + * One of the following policy types: (1) The MTA-STS policy applied (as a string) (2) The DANE TLSA record applied (as a - string) (3) The literal string "no-policy-found", if neither a - TLSA nor MTA-STS policy could be found. + string, with each RR entry of the RRset listed and separated by + a semicolon) (3) The literal string "no-policy-found", if + neither a TLSA nor MTA-STS policy could be found. * The domain for which the policy is applied * The MX host * An identifier for the policy (where applicable) o Aggregate counts, comprising result type, sending MTA IP, receiving MTA hostname, session count, and an optional additional information field containing a URI for recipients to review @@ -294,82 +287,78 @@ The "Result Types" section will elaborate on the failed negotiation attempts. This field contains an aggregate count of failed connections. 4.3. Result Types The list of result types will start with the minimal set below, and is expected to grow over time based on real-world experience. The initial set is: -4.3.1. Routing Failures - - o "mx-mismatch": This indicates that the MX resolved for the - recipient domain did not match the MX constraint specified in the - policy. - -4.3.2. Negotiation Failures +4.3.1. Negotiation Failures o "starttls-not-supported": This indicates that the recipient MX did not support STARTTLS. o "certificate-host-mismatch": This indicates that the certificate - presented did not adhere to the constraints specified in the STS - or DANE policy, e.g. if the CN field did not match the hostname - of the MX. + presented did not adhere to the constraints specified in the MTA- + STS or DANE policy, e.g. if the MX does not match any identities + listed in the Subject Alternate Name (SAN) [RFC5280]. o "certificate-expired": This indicates that the certificate has expired. o "certificate-not-trusted": This a label that covers multiple certificate related failures that include, but not limited to - errors such as untrusted/unknown CAs, certificate name contraints, - certificate chain errors etc. When using this declaration, the - reporting MTA SHOULD utilize the "failure-reason" to provide more - information to the receiving entity. + errors such as untrusted/unknown CAs, certificate name + constraints, certificate chain errors etc. When using this + declaration, the reporting MTA SHOULD utilize the "failure-reason" + to provide more information to the receiving entity. o "validation-failure": This indicates a general failure for a reason not matching a category above. When using this declaration, the reporting MTA SHOULD utilize the "failure-reason" to provide more information to the receiving entity. -4.3.3. Policy Failures +4.3.2. Policy Failures -4.3.3.1. DANE-specific Policy Failures +4.3.2.1. DANE-specific Policy Failures o "tlsa-invalid": This indicates a validation error in the TLSA - record associated with a DANE policy. + record associated with a DANE policy. None of the records in the + RRset were found to be valid. - o "dnssec-invalid": This indicates a failure to authenticate DNS - records for a Policy Domain with a published TLSA record. + o "dnssec-invalid": This would indicate that no valid records were + returned from the recursive resolver. The request returned with + SERVFAIL for the requested TLSA record. -4.3.3.2. STS-specific Policy Failures +4.3.2.2. MTA-STS-specific Policy Failures o "sts-invalid": This indicates a validation error for the overall MTA-STS policy. o "webpki-invalid": This indicates that the MTA-STS policy could not be authenticated using PKIX validation. -4.3.4. General Failures +4.3.3. General Failures When a negotiation failure can not be categorized into one of the "Negotiation Failures" stated above, the reporter SHOULD use the "validation-failure" category. As TLS grows and becomes more complex, new mechanisms may not be easily categorized. This allows for a generic feedback category. When this category is used, the reporter SHOULD also use the "failure-reason-code" to give some feedback to the receiving entity. This is intended to be a short text field, and the contents of the field should be an error code or error text, such as "X509_V_ERR_UNHANDLED_CRITICAL_CRL_EXTENSION". -4.3.5. Transient Failures +4.3.4. Transient Failures Transient errors due to too-busy network, TCP timeouts, etc. are not required to be reported. 5. Report Delivery Reports can be delivered either as an email message via SMTP or via HTTP POST. 5.1. Report Filename @@ -447,21 +436,21 @@ For instance, this is a possible Subject field for a report to the Policy Domain "example.net" from the Sending MTA "mail.sender.example.com". It is line-wrapped as allowed by [RFC5322]: Subject: Report Domain: example.net Submitter: mail.sender.example.com Report-ID: <735ff.e317+bf22029@mailexample.net> Note that, when sending failure reports via SMTP, sending MTAs MUST - NOT honor SMTP STS or DANE TLSA failures. + NOT honor MTA-STS or DANE TLSA failures. 5.4. HTTPS Transport The report MAY be delivered by POST to HTTPS. If compressed, the report should use the media type "application/gzip" (see [RFC6713]), and "text/json" otherwise. 5.5. Delivery Retry In the event of a delivery failure, regardless of the delivery @@ -509,33 +498,34 @@ DMARC [RFC7489] defines an elegant solution for verifying delegation; however, since the attacker had less ability to generate large reports than with DMARC failures, and since the reports are generated by the sending MTA, such a delegation mechanism is left for a future version of this specification. 8. Appendix 1: Example Reporting Policy 8.1. Report using MAILTO - smtp-tlsrpt.mail.example.com. IN TXT \ + _smtp-tlsrpt.mail.example.com. IN TXT \ "v=TLSRPTv1;rua=mailto:reports@example.com" 8.2. Report using HTTPS - smtp-tlsrpt.mail.example.com. IN TXT \ + _smtp-tlsrpt.mail.example.com. IN TXT \ "v=TLSRPTv1; \ rua=https://reporting.example.com/v1/tlsrpt" 9. Appendix 2: JSON Report Schema The JSON schema is derived from the HPKP JSON schema [RFC7469] (cf. Section 3) + { "organization-name": organization-name, "date-range": { "start-datetime": date-time, "end-datetime": date-time }, "contact-info": email-address, "report-id": report-id, "policy": { "policy-type": policy-type, @@ -577,22 +567,22 @@ o "report-id": A unique identifier for the report. Report authors may use whatever scheme they prefer to generate a unique identifier. It is provided as a string. o "policy-type": The type of policy that was applied by the sending domain. Presently, the only three valid choices are "tlsa", "sts", and the literal string "no-policy-found". It is provided as a string. o "policy-string": The string serialization of the policy, whether - TLSA record or STS policy. Any linefeeds from the original policy - MUST be replaced with [SP]. TODO: Help with specifics. + TLSA record or MTA-STS policy. Any linefeeds from the original + policy MUST be replaced with [SP]. TODO: Help with specifics. o "domain": The Policy Domain upon which the policy was applied. For messages sent to "user@example.com" this field would contain "example.com". It is provided as a string. o "mx-host-pattern": The pattern of MX hostnames from the applied policy. It is provided as a string, and is interpreted in the same manner as the "Checking of Wildcard Certificates" rules in Section 6.4.3 of [RFC6125].