| Network Working Group | M. Laber |
| Internet-Draft | 1&1 |
| Intended status: Experimental | September 8, 2014 |
| Expires: March 12, 2015 |
Inter Mail Provider Trust (IMPT): Mandatory use of Transport Layer Security (TLS) with Simple Mail Transfer Protocol (SMTP)
draft-laber-smtp-impt-00
This memo describes the protocol called Inter Mail Provider Trust (IMPT) which ensures that a cryptographically secured communication channel is always established with Transport Layer Security (TLS) when delivering messages via Simple Mail Transfer Protocol (SMTP) between Mail Transfer Agents (MTAs) of pre-registered participants. Mainly the participants exchange SMTP routing information about their MTA infrastructure for this purpose.
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 March 12, 2015.
Copyright (c) 2014 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 carefully, as they describe your rights and restrictions with respect to this document.
Most times Transport Layer Security (TLS) is used with Simple Mail Transfer Protocol (SMTP) in a opportunistic manner which is subject to possible down-grade attacks as described in [RFC3207], section 6.
This memo describes an approach to strictly mandate that an Mail Transfer Agent (MTA) of a IMPT participant must use the SMTP extension STARTTLS [RFC3207] to establish an encrypted connection channel with TLS 1.2 [RFC5246] when transferring a message via SMTP to another participant's MTA.
In opposite to other approaches IMPT also ensures that the receiving MTA knows whether the sender must use TLS or not.
Out-of-band information is exchanged between pre-registered participants for that purpose which is provided in the form of optionally digitally signed JSON-based lists via HTTP over TLS (HTTPS) (see Section 3).
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].
The terms Internet Mail, Recipient, Message Transfer Agent (MTA) are to be interpreted as described in [RFC5598].
Furthermore the following terms are used in this document:
This document is not an Internet Standards Track specification; it is published for examination, experimental implementation, and evaluation.
When transferring an Internet Mail message an outbound MTA MUST use STARTTLS [RFC3207] to establish an encrypted TLS connection if the MX hostname appears as name of an MTA object in at least one participant MX infrastructure list (see Section 3.2).
The outbound MTA (TLS client) MUST authenticate itself to the inbound MTA (TLS server) with a TLS client certificate ([RFC5246], section-7.4.6) published in its MTA object with <role> "outbound" Section 3.2, Paragraph 5.
Furthermore, in case of an error occuring while establishing the TLS connection, the outbound MTA MUST NOT fall back to clear-text transport. Rather, TLS connection failure MUST be treated like an temporary SMTP failure and message SHOULD be queued for retrying transfer later ([RFC5321], section 4.5.4).
The outbound MTA (TLS client) MUST implement the TLS hostname check as detailed in [RFC6125]. The outbound MTA MUST accept at least the MX hostname As server identity. It MAY additionally accept the recipient domain as server identity.
The inbound/receiving MTA (TLS server) MUST check whether the sender's IP address is found in an MTA object. If the IP address is found in an MTA object the sender MUST refuse to accept clear-text (non-TLS) connections from this IP address. Futhermore the inbound/receiving MTA MUST check whether the client certificate used by the outbound/sending MTA matches one of the certificates referenced by value <cert_ref> in the MTA object (Section 3.2, Paragraph 5).
There are three sorts of JSON lists all of which MUST be made publicly accessible:
The lists are provided for public download via HTTP over TLS (HTTPS) [RFC2818] in JSON format with character encoding UTF-8 and the web service MUST send MIME type application/json [RFC7159].
Each participant MUST publish its own participant MX infrastructure list with path name "mxinfra.json" and an aggregated MX infrastructure list with path name "mxinfra-all.json". The complete HTTPS URL for downloading these MX infrastructure lists is composed by appending the path name to the value <base_url> in the participant object (Section 3.1, Paragraph 5).
Applications MUST accept object names and values in arrays in arbitrary order. If an implementation sees any parsing failure or any data within a JSON list is considered invalid or incomplete the whole list MUST be considered invalid and MUST NOT be used at all.
The top-level value <format_version> is present in all lists indicating the version of the list syntax. For now <format_version> is always set to the JSON number 1.
The top-level value <timestamp> is present in all lists indicating the creation time of either the whole list file or a nested object as detailed in Section 3.3.3.
The following sections describe the JSON format of the list files in detail starting with some general implementation considerations.
This section describes the format of the central participants list.
While downloadable from a central location the participants list is considered rather a-priori configuration.
Each participant is registered with a so-called IMPT base domain which MUST be a valid DNS domain registered for the participant.
The IMPT base domain is used in the object <domains> as name for a single JSON participant object following the rules in Section 3.3.1.
The values in a JSON participant object are as follows:
This section describes the format and usage of the MX infrastructure list which describes the inbound and outbound MTAs of a participant.
Participants MUST re-new their local copy of all loaded MX infrastructure lists at least every 15 minutes.
The IMPT base domain names of the participant who generated the list SHALL be used in the object <domains> as name for a single JSON MX infrastructure object following the rules in Section 3.3.1. If <domains> contains a domain name which is not registered in the participant list the whole MX infrastructure list MUST be rejected as invalid.
The values in a JSON MX infrastructure object are as follows:
The MTA object's name is the MX hostname of the MTA. The values in a JSON MTA object are as follows:
This section details some syntax rules which conforming implementations MUST follow when generating values in the JSON lists.
All domains names MUST be stored only with US-ASCII characters [ANSI.X3-4.1986] without a trailing dot and normalized to lower-case characters.
Hence internationalized domain names MUST be stored using the A-label form as defined in [RFC5890].
The JSON lists contain IPv4 and/or IPv6 addresses to be compared to connection information. For secure comparison of those addresses address literals have to be stored with a uniquely comparable string representation.
To avoid any misinterpretation the following stricter string representations MUST be used when generating the JSON lists:
All IPv4 addresses MUST be stored in strict IPv4 dotted-decimal form
ddd.ddd.ddd.ddd
where <ddd> is a one to three digit decimal number between 0 and 255 without non-significant leading zero digits.
All IPv6 addresses MUST be stored in a normalized text representation as defined in [RFC5952].
All timestamps MUST be stored in format YYYYMMDDhhmmssZ. This format is formally specified as LDAP syntax "Generalized Time" in [RFC4517], section 3.3.13.
The time zone is always coordinated universal time (UTC), equivalent to Greenwich Mean Time (GMT) as indicated by the trailing capital letter "Z". IMPT implementations MUST only use the "Z" form of <g-time-zone> excluding fractions of seconds.
The object member <timestamp> in a JSON list MUST contain the timestamp of the last update to that list.
A participant list or a participant MX infrastructure list SHOULD only be generated if the list content actually has been changed.
Consumers of these lists MUST NOT solely rely on a more recent timestamp value to detect whether there have been changes made to a list or not. They SHOULD always compare the read JSON with a prior locally stored version.
The JSON lists SHOULD be digitally signed. In this case a detached signature CMS [RFC5652] MUST be used and stored in a separate file. The signature file name is constructed from the list file name by appending the suffix ".p7s".
Text normalization, e.g. for line-endings or white-spaces, MUST NOT be used when generating or validating the signature. Instead implementations MUST treat JSON lists as single octet strings when generating or validating the signature.
Proper handling of different line-endings and white-spacing is left to the JSON parser implementations. Therefore digital signature verification MUST be performed before parsing the JSON file.
There are no identifiers defined herein to be reserved by IANA.
Typically a message is submitted by an e-mail sender to a mail relay and the message is transmitted over several hops. But the mechanism described herein only assures that an encrypted connection is established between two IMPT-conforming MTAs. Therefore the use of secure transport channels cannot guaranteed for the whole transmission of the message. So the e-mail user is encouraged to use other end-to-end encryption mechanisms as well.
Implementors SHOULD carefully consider the best practices for using TLS as described in [I-D.ietf-uta-tls-bcp].
For all TLS connections the TLS client MUST perform the TLS hostname check as described in [RFC6125]. In particular when downloading the JSON lists the HTTPS client has to verify the server identity as described in [RFC2818], section 3.1.
All implementations MUST correctly perform:
Participants SHOULD carefully monitor the MX infrastructure lists by comparing whether all own MTA objects correctly and timely appear in the aggregated MX infrastructure lists mirroring all the MTA objects. Abnormal deviations SHOULD be properly alerted.
Implementations MAY use certificate pinning for off-loading revocation checks to an external process.
Implementations SHOULD be aware of all the subtle issues when comparing string representations of various identifiers such as hostnames or addresses for security related decisions, specifically when creating and interpreting the JSON lists defined herein. See [RFC6943] for a more detailed problem description.
| [I-D.ietf-uta-tls-bcp] | Sheffer, Y., Holz, R. and P. Saint-Andre, "Recommendations for Secure Use of TLS and DTLS", Internet-Draft draft-ietf-uta-tls-bcp-01, June 2014. |
| [RFC3849] | Huston, G., Lord, A. and P. Smith, "IPv6 Address Prefix Reserved for Documentation", RFC 3849, July 2004. |
| [RFC5378] | Bradner, S. and J. Contreras, "Rights Contributors Provide to the IETF Trust", BCP 78, RFC 5378, November 2008. |
| [RFC5598] | Crocker, D., "Internet Mail Architecture", RFC 5598, July 2009. |
| [RFC5737] | Arkko, J., Cotton, M. and L. Vegoda, "IPv4 Address Blocks Reserved for Documentation", RFC 5737, January 2010. |
| [RFC6761] | Cheshire, S. and M. Krochmal, "Special-Use Domain Names", RFC 6761, February 2013. |
| [RFC6943] | Thaler, D., "Issues in Identifier Comparison for Security Purposes", RFC 6943, May 2013. |
This section contains example JSON lists. Domain names and IPv4/IPv6 addresses are taken from reserved documentation name/address space as detailed in [RFC6761] [RFC3849] [RFC5737].
This is a example participants list containing two base domains example.com and example.net:
{
"format_version": 1,
"timestamp": "20140305151906Z"
"domains": {
"example.com": {
"contract_date": "2013-08-09",
"contract_org": "ACME Org.",
"base_url": "https://impt.example.com/impt/",
"contact_phone": "+49 6151 672637623",
"contact_email": "impt@example.com",
"not_before": "20130809000000Z"
},
"example.net": {
"contract_date": "2014-02-11",
"contract_org": "ACME Agency",
"base_url": "https://foo.example.net/bar/",
"contact_phone": "+1 673 78274872224",
"contact_email": "impt-admins@example.net",
"not_before": "20140221000000Z"
"not_after": "20160809000000Z",
},
},
}
This example shows an MX infrastructure list of a single participant with two base domains "example.com" and "example.net".
Note that all <timestamp> values are equal in this case. For simplicity certificate values are shortened.
{
"format_version": 1,
"timestamp": "20140305134955Z"
"domains": {
"example.com": {
"timestamp": "20140305134955Z"
"cert_list" : {
"mx00" : ["MII..","MII..",],
"mx01" : ["MII..","MII..",]
},
"mx": [
{
"hostname": "mx00.foo.example.com",
"ip_addrs": [ "128.66.134.8" ],
"cert_ref": "mx00",
"role": "inbound"
},
{
"hostname": "mx01.bar.example.com",
"ip_addrs": [ "128.66.134.72", "2001:DB8:20a:42:2323::1" ],
"cert_ref": "mx01",
"role": "inbound"
},
}
"example.net": {
"timestamp": "20140305134955Z"
"cert_list" : {
"foo" : ["MII..","MII..",],
"bar" : ["MII..","MII..",]
},
"mx": [
{
"hostname": "foo23.example.net",
"ip_addrs": [ "42.23.134.8", "2001:db8::2:1" ],
"cert_ref": "foo",
"role": "inbound"
},
{
"hostname": "bar42.example.net",
"ip_addrs": [ "42.23.134.72", "2001:db8::2:2" ],
"cert_ref": "bar",
"role": "inbound"
},
}
},
}
This example shows an aggregated MX infrastructure list of with two base domains "example.com" and "example.net" of different participants.
Note that in this case all <timestamp> values are different because the inner values were copied from the source participant MX infrastructure list. For simplicity certificate values are shortened.
{
"format_version": 1,
"timestamp": "20140305134955Z"
"domains": {
"example.com": {
"timestamp": "20140303112227Z"
"cert_list" : {
"mx00" : ["MII..","MII..",],
"mx01" : ["MII..","MII..",]
},
"mx": [
{
"hostname": "mx00.foo.example.com",
"ip_addrs": [ "149.53.134.8" ],
"cert_ref": "mx00",
"role": "inbound"
},
{
"hostname": "mx01.bar.example.com",
"ip_addrs": [ "128.66.134.72", "2001:DB8:20a:42:2323::1" ],
"cert_ref": "mx01",
"role": "inbound"
},
}
"example.net": {
"timestamp": "20140301124257Z"
"cert_list" : {
"foo" : ["MII..","MII..",],
"bar" : ["MII..","MII..",]
},
"mx": [
{
"hostname": "foo23.example.net",
"ip_addrs": [ "42.23.134.8", "2001:db8::2:1" ],
"cert_ref": "foo",
"role": "inbound"
},
{
"hostname": "bar42.example.net",
"ip_addrs": [ "42.23.134.72", "2001:db8::2:2" ],
"cert_ref": "bar",
"role": "inbound"
},
}
},
}