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

Abstract

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.

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 March 12, 2015.

Copyright Notice

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.


Table of Contents

1. Introduction

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).

1.1. Terminology

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:

Recipient domain:

Domain part of the [RFC5321] RCPT TO command forward path.
MX record:

DNS resource record which is used to locate the MTA for a recipient domain as described in [RFC1035], section 3.3.9.
MX hostname:

DNS hostname of the inbound MTA for a recipient domain determined by rules defined in [RFC5321], section 5.
MX address:

The IP address of the MX hostname determined by looking up the associated A or AAAA resource records in DNS.
IMPT participant (or only participant):

Organization or individual which is running mail services for own use or on behalf of others (hosting provider) which are compliant to the protocol described herein.
JSON object:

JSON object consisting of name/value pairs (or members) as defined in [RFC7159], section 4.
JSON array:

JSON array as defined in [RFC7159], section 5.
JSON lists:

Different types of JSON formatted lists are defined in Section 3.

1.2. Status

This document is not an Internet Standards Track specification; it is published for examination, experimental implementation, and evaluation.

2. Transfer messages

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).

3. List formats

There are three sorts of JSON lists all of which MUST be made publicly accessible:

Participant list:

Holds contact information and a reference link to MX infrastructure list of each trusted participant. This list MAY be stored in a central location but each participant provides a copy of this list for download which SHOULD be considered local configuration. The format is specified in Section 3.1.
Participant MX infrastructure list:

Describes own MX infrastructure of a single participant including all incoming and out-going MTAs for which use of transport security with TLS is mandatory. It contains host names, IP addresses and X.509 client and server certificates actually used (see Section 3.2).
Aggregated MX infrastructure list:

An MX infrastructure list (Section 3.2) containing the mirrored JSON MX infrastructure objects of all participants.

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.

3.1. Participants list

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:

contract_date

This value contains the date of the registration contract in format YYYY-MM-DD as defined in
[ISO.8601.1988].
contract_org

Legally bound name of the participant's organization.
base_url

Base URL (HTTPS) with trailing slash "/" for forming URL to download the MX infrastructure lists from the participant's HTTPS server.
contact_phone

Public phone number for support requests, abuse notices or similar in international phone number format as specified in [E.123].
contact_email

Public e-mail address for support requests, abuse notices or similar in format specified in [RFC5322].
not_before

Timestamp after which this participant is active and implements all the provisions made in this document. Especially if <not_before> lies in the future MX infrastructure lists from this participant are still considered invalid and MUST NOT be used. The format is specified in Section 3.3.3.
not_after

Timestamp after which this participant is not active anymore. Especially if <not_after> lies in the past MX infrastructure lists from this participant are all considered invalid and MUST NOT be used anymore. The format is specified in Section 3.3.3.

3.2. MX infrastructure list

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:

timestamp

Contains a timestamp as described in
Section 3.3.3.
Within the participant MX infrastructure list this is the same timestamp like in outer value <timestamp>.
Within an aggregated MX infrastructure list this is a copy of the value <timestamp> in the original participant MX infrastructure.
cert_list

This JSON object contains one or more arrays of certificate data. The name can be randomly chosen by the generator of the list but has to be unique with <cert_list> object. The binary X.509 certificates are stored as base64-encoded strings [RFC4648].
mx

This object MUST contain MTA objects for all inbound and outbound MTAs of the participant, possibly used for different recipient domains, referenced by the publicly visible MX hostname as object name. This object MAY contain MTA objects with names not yet listed in the MX RR of a domain. This allows to announce new MTAs in the MX infrastructure list before actually using them.

The MTA object's name is the MX hostname of the MTA. The values in a JSON MTA object are as follows:

hostname

MX hostname of MTA as fully-qualified domain name (FQDN) following the rules in
Section 3.3.1. An MX hostname MUST NOT be used more than once for <role> "inbound".
ip_addrs

Array of IPv4 and/or IPv6 addresses as string representations following the rules in Section 3.3.2.
cert_ref

Names of values in JSON object <cert_list>. Since the same X.509 certificate may be used by more than one MTA the same reference name MAY be used more than once. Implementations reading a MX infrastructure list MUST check whether the MTA object's name, equal to the MX hostname, matches the certificate by implementing the hostname check described in [RFC6125].

role

Role of MTA, either "inbound" or "outbound".
Role "inbound" means that this MTA accepts connections from other MTAs. Regarding TLS this is a TLS server and the used certificates SHALL be treated as TLS server certificates.
Role "outbound" means that this MTA opens connections to other MTAs. Regarding this is a TLS client and the used certificates SHALL be treated as TLS client certificates.

3.3. Value Syntaxes

This section details some syntax rules which conforming implementations MUST follow when generating values in the JSON lists.

3.3.1. Domain Names

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].

3.3.2. IP Address Literals

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].

3.3.3. Timestamps

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.

3.3.4. Digital signatures

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.

4. IANA Considerations

There are no identifiers defined herein to be reserved by IANA.

5. Security Considerations

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.

6. References

6.1. Normative References

[ANSI.X3-4.1986] American National Standards Institute, "Coded Character Set - 7-bit American Standard Code for Information Interchange", ANSI X3.4, 1986.
[E.123] International Telecommunication Union (ITU), "ITU-T Rec. E.123: Notation for national and international telephone numbers", November 1988.
[ISO.8601.1988] International Organization for Standardization, "Data elements and interchange formats - Information interchange - Representation of dates and times", ISO Standard 8601, June 1988.
[RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
[RFC3207] Hoffman, P., "SMTP Service Extension for Secure SMTP over Transport Layer Security", RFC 3207, February 2002.
[RFC4517] Legg, S., "Lightweight Directory Access Protocol (LDAP): Syntaxes and Matching Rules", RFC 4517, June 2006.
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, October 2006.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R. and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, May 2008.
[RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, October 2008.
[RFC5322] Resnick, P., "Internet Message Format", RFC 5322, October 2008.
[RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, RFC 5652, September 2009.
[RFC5890] Klensin, J., "Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework", RFC 5890, August 2010.
[RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6 Address Text Representation", RFC 5952, August 2010.
[RFC6125] Saint-Andre, P. and J. Hodges, "Representation and Verification of Domain-Based Application Service Identity within Internet Public Key Infrastructure Using X.509 (PKIX) Certificates in the Context of Transport Layer Security (TLS)", RFC 6125, March 2011.
[RFC7159] Bray, T., "The JavaScript Object Notation (JSON) Data Interchange Format", RFC 7159, March 2014.

6.2. Informative References

[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.

Appendix A. Examples

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].

A.1. Participants list

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",
        },
    },
}

A.2. MX infrastructure list single participant

This example shows an MX infrastructure list of a single participant with two base domains "example.com" and "example.net".

Example download URL:

https://impt.example.com/impt/mxinfra.json
Example signature URL:

https://impt.example.com/impt/mxinfra.json.p7s

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"
        },
    }
  },
}

A.3. Aggregated MX infrastructure list

This example shows an aggregated MX infrastructure list of with two base domains "example.com" and "example.net" of different participants.

Example download URL:

https://impt.example.com/impt/mxinfra-all.json
Example signature URL:

https://impt.example.com/impt/mxinfra-all.json.p7s

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"
        },
    }
  },
}

Author's Address

Markus Laber 1&1 Internet AG Brauerstr. 48 Karlsruhe, 76137 DE EMail: markus.laber@1und1.de URI: http://www.1und1.de